Profesor de ciencias de la computación en Carnegie Mellon University quien ha destacado por ser un pionero en el Crowdsourcing. De origen guatemalteco, reside en Estados Unidos y es reconocido como un investigador influyente en el ámbito científico y tecnológico con premios como el MacArthur otorgado a personas destacadas en sus áreas. Además, es el creador de Captcha y reCaptcha test diseñado para el ojo humano que impide el spam y que a través de las palabras escritas por los humanos en el test se esta contribuyendo a la digitalización de millones de libros, este proyecto fue adquirido por la empresa Google. Su proyecto más reciente se denomina Duolingo que tiene como objetivo que millones de personas aprendan otros idiomas de forma gratuita y al mismo tiempo ayudan a traducir el contenido de Internet a otros idiomas. XD

Duolingo | Learn Spanish, French, German, Portuguese, Italian and English for free

Richard Stallman  no creo que se callaria ese problema.

estas son distros libres revisado por varias personas podrian ser seguras.

http://www.gnu.org/distros/free-distros.html

mi duda es gento tiene algo privativo 

http://www.gnu.org/distros/free-distros.html

me parece que el nivel de complejida en el  entendimiento son parecidas los idiomas del humano y el lenguaje de programaciòn de computacion llevan algo en comun "las reglas"  

http://es.wikipedia.org/wiki/Idioma

http://es.wikipedia.org/wiki/Lenguaje_de_programacion

 para mi personalmente  se me dificulta  mucho entender los algoritmos de lenguaje de programacion , al ser nativo español creo que es por mi idioma si hubiese sido nativo del ingles habria entendido mejor la sintaxis y reglas, siempre estuvo el ingles desde niño me costo entender el funcionamiento.

interesante paginas me gustan 

 Duolingo
 Codecademy
 Programando.la

en idiomas agregaria estas paginas donde me corrigen mi ortografia

inicio > Todas las categorías > Sociedad y cultura > Idiomas

http://es.answers.yahoo.com

http://www.busuu.com/es/

aqui hablo con nativos el ingles. 

http://tinychat.com/

yo  creo en el dinero que lo mueve todo    , las religiones en general son inventos del hombre en el mundo.

en delphi  para el juego solitario de windows vi una "inyeccion" 

 

De hecho Richard Stallman ya emitio su opinion al respecto. Apunto con el dedo acusador a nada mas y nada menos que a Mark Suttleworth, CEO de Canonical (Ubuntu) por incluir spyware en su distro ( y esto es oficial, Suttleworth a reganadientes lo reconocio..."pero lo usamos para cosas buenas"....je). Esa es la razon por la que ahora existen las "opciones de privacidad" en Ubuntu. En la comunidad de Linux Mint tambien se tiene cierto malestar por la decisionde de mantener Zeitgeist (una aplicacion que hace seguimiento de todas tus actividades en la pc) a pesar de las continuas peticiones por removerlo. Clemennt Lefevre ha tenido que salir al frente mas de una vez para desmintir tales acusaciones. Yo, la verdad , mientras exitsa algo en mi PC haciendo seguimiento de todo lo que haga, lo voy a considera spyware.

Linux Debian & Fedora siempre se ha mantenido fiel a su precepto de "Libre" y es el que uso por cierto.   

Pero ahí otras distribuciones que si son totalmente libres, Trisquel, Parabola, gNewSesnse, etc que son las que promueve el FSF, estás tienen todo el kernel libre y aplicativos libres. No contienen ningún driver privativo.


Código de la NSA en Android y Linux, seguridad que impone muchas dudas
 


El descubrimiento del programa PRISM cuenta entre sus muchos detalles con la teórica colaboración de los gigantes de la tecnología en esa gigante red de espionaje y monitorización. Varios de esos gigantes, como Google, han tratado de negar que haya acceso a sus servidores, pero ahora han aparecido nuevos y singulares datos que en este caso afectan a Android.

Programadores de la NSA han añadido cierto código al sistema operativo Android que teóricamente aumenta la seguridad de esta plataforma móvil. Las sospechas que eso genera han tenido que ser explicadas, pero la portavoz de Google Gina Scigliano simplemente ha indicado que “todo el código de Android y sus contribuyentes está públicamente disponible para su revisión en source.android.com“.

Y sin embargo, la sospecha permanece. Google accedió a incluir ese código, llamado Security Enhacenments for Android (“Mejoras de seguridad para Android”) en 2011. Según la NSA dicha código aisla las aplicaciones para evitar que hackers y otros usuarios ganen acceso a datos personales o corporativos almacenados en un dispositivo.

“Nuestro objetivo“, afirmaba Stephen Smalley, investigador de la NSA que trabaja en dicho desarrollo, “es aumentar el nivel de la seguridad en dispositivos móviles comunes“. La publicación Bloomberg Businessweek que ha tenido acceso a la presentación de dicha característica indica que en ella se deja claro que este programa “es invisible a los usuarios“, además de indicarse que en esa presentación el objetivo final es “mejorar nuestra comprensión de la seguridad en Android“.

¿Seguridad o escuchas para PRISM?
Vanee’ Vines, portavoz de la NSA, no dejó claro si ese desarrollo también ayuda a esa monitorización que se sabe que los dispositivos móviles han sufrido como parte del programa Prism. “El código fuente está disponible públicamente para que cualquiera pueda revisarlo, y eso incluye la capacidad de analizarlo línea por línea“.



Esas “mejoras de seguridad” están presentes en terminales como el Sony Xperia Z, HTC One o Samsung Galaxy S4, y aunque no están activadas por defecto según la documentación, sí lo estarán en futuras versiones de Android.

En Apple precisamente han indicado que no aceptan código fuente de ninguna agencia gubernamental para sus sistemas operativos y otros productos, pero no se sabe si otros sistemas operativos incluyen ese código, aunque hay indicios de que una plataforma teóricamente a salvo de estos temas podría también incluir ese código: Linux.

¿También en Linux, y por tanto, en los servidores de Google, Amazon o Facebook?
Según Bloomberg, la plataforma Security Enhacements for Android se derivó de un ya veterano proyecto de la NSA llamado Security Enhanced Linux (SELinux). El SELinux es uno de los componentes claves del Red Hat Enterprise Linux (RHEL) y sus clones, el código es 100% auditable tanto para plataforma PC como para Android



Aquel código se integró hace una década en el núcleo de este sistema operativo, y se desconoce si en dicho código también hay partes orientadas a monitorizar y espiar comunicaciones de los usuarios.

De ser así, tendríamos al menos parte de la explicación de cómo accede la NSA a los servidores de gigantes como Google o Facebook: en todos ellos se hace uso de Linux. Jim Zemlin, director ejecutivo de la Linux Foundation, ha indicado que “el código fue revisado de forma independiente por un montón de gente“, y asegura que no hay en él nada que indique que está orientado a esas escuchas y monitorización de las comunicaciones.


Fuente

estas son sus caracteristicas podria correr?  
 

 

Ingeniería inversa en aplicaciones de Android I


Formatos de archivo .DEX y .JAR

Como sabemos la mayoría de aplicaciones para Android están programadas en Java, los ejecutables de este sistema operativo tienen una extensión de tipo .APK, hasta aquí todo bien, pero debemos saber que esta extensión no es más que una variación de la extensión .JAR, por lo que si alguna vez hemos programado en Java sabemos que los .JAR funcionan como una especie de contenedor con varios archivos adentro, por lo que con cualquier compresor podemos extraer su contenido y ver una serie de archivos que son los que componen la aplicación.

Por lo tanto, si a una aplicación Android  (.APK) le extraemos los ficheros con un compresor cualquiera podremos ver todos los ficheros que componen la aplicación:


Uno de estos archivos es classes.dex que será uno de los más importantes pues este es el que contiene las clases y todo el código en general de la aplicación.
Herramientas necesarias

Como mencionábamos más arriba, en Windows para poder ver el código en ensamblador de un archivo con extensión .exe usábamos el OllyDB, en esta ocasión haremos uso de una serie de herramientas que harán lo mismo y con esto podremos ver el código Java.

El proceso será sencillo, pasaremos el archivo .dex a .jar y luego descompilaremos este último. Para esto necesitaremos:

JD-GUI: Es una aplicación con interfaz gráfica muy intuitiva con la que podremos ver el código fuente de los archivos .class (básicamente .jar de Java). Con  esta herramienta podremos ver clases, métodos y otros componentes del programa. Web oficial: http://java.decompiler.free.fr/?q=jdgui

Dex2Jar: Como su nombre nos lo dice, permite pasar de .dex a .jar, podemos usarlo individualmente o en conjunto con las herramientas que nombraremos aquí. Web oficial: http://code.google.com/p/dex2jar/

Eclipse: Es un IDE de desarrollo para varias plataformas y que funciona con java. Web oficial: http://www.eclipse.org/downloads/

Configurar .Dex2Jar en Eclipse

Lo primero será configurar un nuevo proyecto, por lo que vamos a File > New > Java Proyect, le ponemos un nombre al proyecto y damos a finalizar.


Seleccionamos nuestro proyecto en explorador de paquetes, luego estando seleccionado vamos al menú Project > Properties > Java Build Path. Allí en la pestaña “Libraries” damos click en “Add external Jars”, allí en la ventana que sale ubicamos la carpeta de Dex2Jar y añadimos todos los .Jar de la carpeta a nuestro proyecto y seleccionamos Ok.


Ahora añadimos nuestro fichero .APK al proyecto, es decir, lo arrastramos hasta el explorador de  paquetes.


Ahora hacemos click derecho en la carpeta de nuestro proyecto, seleccionamos Run As > Run Configurations y hacemos doble click en “Java application”, por lo que se añadirá una especie de página en la cual podemos pasar argumentos.

Aquí en la pestaña “Main“añadimos el nombre de la clase Main de Dex2Jar, la cual es posible encontrarla haciendo click en el botón “search” de la misma pestaña, en mi caso tiene una estructura así: com.googlecode.dex2jar.v3.Main


Luego vamos a la pestaña arguments y en la primera caja de texto colocamos el nombre de nuestro fichero APK con la extensión:


Damos click en Aplicar (Apply) y luego en “Run”, para ver un resultado de este tipo:


Ahora actualizamos nuestro explorador de proyectos (Click derecho y luego le damos “Refresh”) y veremos un nuevo fichero con extensión .Jar, es el que necesitábamos.


Descompilar archivos .JAR

Con el proceso anterior obtuvimos un .JAR limpio, ahora debemos “decompilarlo” para así poder ver su código fuente, por lo que abrimos el JD-GUI y allí abrimos nuestro .JAR generado, lo primero que observo son los métodos y en especial uno que dice button1_click(), ya que de seguro allí habrá algo.

 

Pero bueno, ya a partir de aquí podemos seguir e investigar todo el código, obviamente los conocimientos de programación nunca están demás para entender los algoritmos implicados en la aplicación.

Crackme

http://www.mediafire.com/download/tbdy9228c2reclg/crackmetest.apk

Fuente
 

Ingeniería inversa en aplicaciones de Android II


se puede definir que el código generado para las aplicaciones Android no es exactamente “Java Bytecode”, por eso los ejecutables para Android no contienen ficheros .class si no .dex que significa Dalvik Executable. De igual forma estos ficheros .dex se pueden “decompilar” y lo que veremos posteriormente será un lenguaje de bajo nivel (Dalvik Bytecode).

Aunque como tal con algunas aplicaciones específicas podemos ver en un lenguaje de alto nivel estos códigos (aplicaciones como Dex2Jar posteriormente decompilando con JD-GUI). Algunos enlaces interesantes sobre Dalvik y los OPCodes:

http://www.dalvikvm.com/
http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html
http://developer.android.com/reference/dalvik/bytecode/Opcodes.html

Herramientas a utilizar y preparación del entorno

Para la preparación del entorno tendremos en cuenta todo lo necesario para empezar casi “desde cero”, los requisitos como siempre son saber la lógica de un lenguaje de programación (mejor si es Java) y bueno, lo demás se explicará poco a poco.

 Como trabajaremos con Android necesitaremos usar la plataforma Java, ojo, no basta con el entorno de ejecución (JRE) necesitaremos todas las herramientas para desarrolladores (JDK – Java Development Kit) y un IDE cualquiera, puede ser Eclipse. http://www.oracle.com/technetwork/java/javase/downloads/index.html
   
También necesitaremos las herramientas de desarrollo de Android o SDK, en el portal oficial hay una guía de instalación http://developer.android.com/sdk/installing.html también debemos configurar un emulador o el AVD, que nos permitirá ejecutar una “máquina virtual” de Android en nuestros ordenadores (ver aquí http://developer.android.com/sdk/adding-components.html).

Smali/Baksmali: se trata de un ensamblador/desemsamblador de ficheros apk que nos servirá para generar los fuentes en lenguaje de bajo nivel (aunque como tal no lo usaremos en esta guía). Se puede descargar de aquí: http://code.google.com/p/smali/

APKTool: Esta herramienta sustituirá el Smali/Baksmali ya que los integra dentro de su paquete. Como su nombre lo indica es un kit de herramientas para trabajar con ficheros APK. http://code.google.com/p/android-apktool/ con el generaremos el código de bajo nivel y luego recompilaremos.

Testsign.jar: Es una herramienta de terceros desarrollada para “firmar” o generar certificados aleatorios para indicarle al sistema que el fichero que hemos modificado se trata de una aplicación Android. Se descarga de aquí http://code.google.com/p/zen-droid/downloads/list (buscar el fichero testsign.jar).

zipalign: se trata de una herramienta que viene incluida en el SDK (PATH\android-sdk-windows\tools\zipalign.exe), que está hecha para preparar nuestro apk para el sistema Android, es decir, para que su rendimiento sea tal cual para dicho sistema ya que si no está “comprimida” con esta herramienta podría afectar el rendimiento de la misma en el dispositivo.

Instalar aplicaciones APK en el emulador de Android

El AVD Manager Tool es la herramienta que nos permite gestionar distintas “máquinas virtuales” de un sistema Android configuradas para un api específica (es decir, para distintas versiones del sistema operativo Android). Supondré que ya tienen instalado el Android SDK que viene con el SDK Manager pero aún falta configurar dicho “emulador” o máquina virtual. Por lo que aquí explicaré como crear una. Lo que necesitaremos es ir al directorio en donde hemos instalado el Android SDK, allí veremos el ícono del logo o mascota de Android llamado SDK Manager, desde allí podremos instalar diversas apis y claro, configurar nuestra nueva máquina virtual.

Allí hacemos clic en la opción “Virtual Devices” y si es la primera vez que lo usamos de seguro no habrá ninguna máquina virtual configurada, por lo que hacemos clic en el botón de la derecha que dice “New…”.


Luego tendremos que configurarla. Los parámetros son:

Name: El nombre de la máquina virtual. Esta no puede contener espacios.

Target: Es el api que utilizaremos para ejecutar la máquina virtual es decir, como si fuera la versión de Android. Recomiendo de momento la “API Level 8″ o Android 2.2 que es lo mismo

Lo demás ya se configura una vez hemos seleccionado el api, pero si queremos parámetros adicionales podemos explorar la herramienta. Por último le damos a Create AVD.


Listo ahora la seccionamos en el listado y en la parte derecha le damos “Start” y “Launch”. Se empezará a cargar la nueva unidad virtual lo que puede tardar varios minutos así que debemos ser pacientes en este paso. Cuando arranque veremos una pantalla como si fuese un móvil Android, con el sistema operativo completamente funcional. Pero como lo que vamos a hacer es un proceso de ingeniería inversa necesitaremos probar la aplicación, por lo que surge la necesidad de instalar aplicaciones APK en esta nueva unidad virtual.

Lo base para esto será saber que las aplicaciones Android se deben copiar a la carpeta “platform-tools” por ejemplo, la mía está en C:\Android SDK\android-sdk-windows\platform-tools, esto porque allí hay una herramienta llamada ADB (Android Debug Bridge) la cual es una herramienta que funciona por línea de comandos y que también sirve de conexión de nuestro móvil al ordenador y realizar tareas desde allí

En esta ocasión la utilizaremos para instalar APKs, por lo que una vez copiado el APK al directorio “Platform-tools” debemos ejecutar (con el emulador abierto):

adb install fichero.apk o para desinstalar adb uninstall fichero


Ahora si todo ha salido bien veremos la aplicación instalada en el emulador. Por cierto, algo importante a tener en cuenta es que el emulador o unidad virtual debe estar ejecutándose al momento de realizar este proceso de instalación del APK.

Instalar y usar ApkTool

Con el proceso anterior aprendimos a probar los APK. Bien, olvidemos por un rato eso y ahora iniciemos con el proceso de “ingeniería inversa” como tal. En esta ocasión usaremos APKTool, que básicamente sirve para cambiar algunas cosas de las aplicaciones Android pero además de ensamblar y desensamblarlas, que es nuestro uso principal en esta ocasión.

Para instalar APKTool deberemos bajar tanto el fichero apktool.jar (el principal) y si estamos en Windows debemos bajar las dependencias, veamos el proceso paso a paso mejor:

    Descargar APKTool y dependencias (apktool1.4.1.tar.bz2 y apktool-install-windows-r04-brut1.tar.bz2).
    Descomprimir todo en una sola carpeta.
    Copiar estos ficheros al directorio principal de Windows, es decir, C:\Windows.

Listo ahora podemos ejecutar desde la consola de Windows el APKTool (Tecla Windows + R > cmd > Tecleamos apktool para ver todos sus parámetros). Para continuar con dicho proceso deberemos generar nuestro bytecode o fuentes en código de bajo nivel. Para “decompilar” nos ubicamos en la carpeta del APK y tecleamos en la consola:

apktool d fichero.apk nombre_nuevo_sin_extension

En la consola sería algo como esto:


Ya “desensamblamos” todo por lo que si revisamos la carpeta de nuestro APK hay un nuevo directorio el cual tiene el mismo nombre que le especificamos en la línea de comandos hace un momento. Lo que contiene son los ficheros fuente, el AndroidManifest.xml, entre otros recursos Lo que nos interesa es la carpeta smali, donde están los fuentes.

Si revisamos dicha carpeta y los ficheros generados, veremos unos archivos con extensión .smali, y lo primero que noto es un archivo llamado “main.smali“, pues sí, el código en lenguaje de bajo nivel.

En el tomo nº 1 de esta guía básica compartí un “crackme” o una aplicación Android que pedia un usuario y contraseña, no era más que una comparación de strings. Supongamos ahora que estamos revisando dicha aplicación y nos ponemos a buscar el mensaje de error que muestra cuando el usuario y contraseña son incorrectos.


Usaré ahora un editor de textos, de forma intuitiva uso el buscador para encontrar este mensaje y revisando un poco el código encuentro una comparación de strings, que no representan más que dicha comparación de usuario y contraseña. Pero estos string están declarados en un OPCode llamado const-string, por lo que ya sabemos la importancia de reconocerlos y que para buscar cadenas está el OPCode const-string.

Ahora, esto quiere decir que si cambio el const-string y la cadena encontrada en la comparación podré modificar los datos de acceso a la aplicación, si pongo por ejemplo “123” como contraseña podremos ver que pasa (sabiendo que la contraseña actual es “2014″ y el nombre de usuario como se puede ver es “ricadmin”):


Una vez modificado el siguiente paso será empaquetar nuevamente nuestro fichero APK, por lo que abrimos una consola de comandos, nos ubicamos en la carpeta donde estábamos trabajando y tecleamos:

apktool b carpeta_de_trabajo ficherocompilado.apk

Nótese que anteriormente yo había “desensamblado” y le llamé a mi carpeta “debug-crackmetest”. Tengan muy en cuenta los espacios que hay entre colocar el nombre de la carpeta y el del nuevo fichero compilado.

Y listo, con eso habremos generado un nuevo fichero APK con el nombre que le hemos acabado de poner (aparece en la misma carpeta de trabajo).


Firmando la aplicación o “generando certificados”

Es importante decirle a Android que nuestro APK en realidad si se trata de una aplicación para Android, pues estos tienen ciertas características que el sistema lee antes de su ejecución como tal.

Para esta tarea usaremos el “testsign.jar” una utilidad escrita para dicha finalidad y que podemos bajar en para empezar a usarla debemos colocarla en la misma carpeta de nuestro APK recién compilado y en la consola escribimos:

java -classpath testsign.jar testsign compilado-firmado.apk

Tener en cuenta que esto se le aplica a nuestro APK recién compilado. Si todo sale bien no saldrá nada por pantalla:


Generar un APK apto para Android

Listo, con el paso anterior “firmamos” la aplicación, ahora debemos optimizar el nuevo APK con una herramienta llamada “zipalign” que se encuentra en la carpeta “tools” de donde tenemos instalado el Android SDK.

El siguiente paso será copiar nuestro APK recién firmado a la carpeta “tools” que es donde se encuentra la aplicación “zipalign”, abrimos una consola, nos ubicamos en el directorio donde está la aplicación y nuestro fichero recién copiado y tecleamos:

zipalign -f 4 fichero-compilado.apk fichero-final.pak


Si todo sale bien tampoco saldrá nada. Ahora solo nos queda probar la aplicación y que los cambios se hayan realizado funcionen. Por lo que nuestro “fichero-final.apk” lo copiamos a “platform-tools” para instalarlo en nuestra unidad virtual que debe estar ejecutándose (por lo que en la consola escribimos “adb install fichero-final.apk”). Y el resultado es:


Fuente