Archivar por febrero, 2011

Nuevo Record de Apple: 4 Productos de Apple en 30 segundos

Después de disfrutar de una agradable comida me disponía a ver el último episodio de la serie cómica “The Big Bang Theory”, episodio 4×14. Pues bien, ya sabemos el dineral que gasta Apple en publicidad en series, películas… pero esto me ha parecido ya aberrante.

Comienza el episodio y lo primero que tenemos es una panorámica de un aula universitaria con al menos 2 MAC, manzanas completamente visibles y en primer plano.

La escena cambia, y aquí durante 30 segundos aparecerán 4 dispositivos más. Primero es Leonard con un iPhone haciendo el que lee Twitter. La cámara cambia rapidamente a Howard, pero antes se puede ver perfectamente como Koothrappali esta buscando algo en su MACbook. Lo gracioso es que la imagen se fija en Howard quien de nuevo con un iPhone está leyendo en Twitter (3 dispositivos en 10 segundos). La cámara vuelve a Koothrappali que no habla de Twitter, sino de unas fotos subidas a Flickr. Cuando creemos que todo ha terminado, entra en ese momento por la puerta Penny, y que tiene en la mano??? Otro iPHone!!!! preguntando si han cambiado la contraseña WIFI.

Es decir, que Apple quiere dejar bien claro que sus dispositivos sirven para tener acceso a todas las redes sociales de forma sencilla? Por dios, en 30 segundos han metido 4 dispositivos claramente visibles y claramente aludiendo a ellos, quitando los dos macbook que salieron al principio, lo que hace u ntotal de 6 en 1 minuto y medio que lleva el episodio.

Es normal que muchos no sean capaz de decir mas que beeeeeeee. Es lo mismo que hacen las discográficas con la música comercial. Te la ponen por el dia, por la noche, en todas las cadenas que existen, en la radio, en la tele… al final por narices sabes de que cancion se trata y muchos correrán a comprarla porque es la supuesta canción de moda, aunque sea una porquería.

Del mismo modo, muchos querrán sentirse identificados con los actores, o simplemente diran ei!! eso es lo q yo quiero.

Sinceramente, para este tipo de publicidad casi que prefiero la de Motorola con su Xoom. Por qué no hace Apple márketing de otro tipo? porque no le funcionaría, Apple no puede competir con razones, cuando lo ha intentado siempre ha fracaso, lo qeu le queda es meterlo por los ojos. En serio… llega a ser molesto.

Android: Algo de Ingeniería inversa para parchear una aplicación, firmarla y volver a colocarla

Como en alguna ocasión he dicho, prácticamente todos los países del mundo es completamente legal la ingeniería inversa de un programa. ¿En que consiste? Bueno, los programadores escriben su código, este luego se compila y enlaza y esto origina el programa resultante, en conjunto por supuesto del resto de los recursos que use. El resultado es un archivo o una serie de archivos que la plataforma para el cual fue compilado pueda ejecutarlo. La ingeniería inversa es simplemente intentar darle la vuelta a este esquema, que a partir de un programa compilado se pueda obtener un código que manipular, es decir, decompilar.

Cuando se habla de parquear todos ya piensan en piratear o saltarse medidas de seguridad pero esto no es para nada una norma. Es más, dentro de Android se usa más estos procesos (al menos parte de ellos) para modificar el aspecto visual de las aplicaciones, los iconos de estas, los colores, música, textos… lo que podríamos llamar los “recursos” de esta. Para hacer este tipo de cosas es necesario poder acceder a los recursos de la aplicación, editarlos y dejarlo todo tal y como estaba… o al menos dejarlo de forma que podamos usarlo después. Pero las dotes de Photoshop prefiero dejarlas a manos de buenos amigos que son realmente unos genios en el diseño gráfico (envidia sana desde luego), y yo prefiero encargarme de los bajos fondos. Por cierto, un saludo para ellos desde aquí, tanto amigos como desconocidos. En este caso por tanto no será cambiar una skin o cambiar el aspecto de una aplicación, sino que sí… en este caso si vamos a ver como saltarnos una restricción que nos imponen.

El material que vamos a usar será el siguiente:

  • Windows 7 (Se puede usa otro OS)
  • El SDK de Android instalado, conjuntamente con el JDK (SDK) de Java
  • Un editor Hexadecimal
  • Un dispositivo Android con acceso a la carpeta /System, ya sea porque está rooteado o por medio de un recovery y usar ADB pull
  • La aplicación APKtool para decompilar/compilar (parte 1, parte 2)

Bien, dado que hablamos de Android hay que conocer un poco cual es el modelo de programación que existe, y a la par que es potente es simple. Ya he dicho que Android usa un sistema de programación JAVA (que no significa que el código generado para Android pueda ejecutarse por una VM JAVA). Básicamente, todo el código compilado para Android se empaqueta en un archivo apk (que no es más que un archivo zip) que contiene por un lado los recursos de la aplicación (imágenes, sonidos, archivos binarios…), por otro lado lo que podría verse como la interfaz de dicha aplicación, la firma y certificado de la aplicación y por último las librerías y el código principal de la misma, generalmente en formato DEX. DEX es por así decirlo el código compilado puro y duro de Android, la compilación para la máquina virtual Dalvik, digamos por así decirlo que es el “ejecutable” de las aplicaciones. Las firmwares de algunos fabricantes usan un sistema híbrido que permiten a las aplicaciones por así decirlo compartir código y otras cuestiones y se las conoce como ODEX. En la práctica lo que supone es que cada aplicación apk posee externa a ella otro archivo que la acompaña en formato ODEX, que contendrá tanto el propio código que contenía el archivo DEX como el código necesario para enlazar a esta el código que no se encuentra ni en el apk ni en el propio archivo ODEX, por ejemplo código compartido por muchas aplicaciones y que se reutiliza (lo que serían algo así como librerías dinámicas).

Es importante conocer si estamos ante el escenario DEX o el escenario ODEX, puesto que es diferente. Si estamos ante una aplicación DEX, tan solo tendríamos que realizar una decompilación, modificación, compilación firma y alineamiento. Pero en el caso de una aplicación ODEX antes de decompilar tendríamos que asegurarnos que podemos suministrar al decompilador la ubicación de esas “librerías externas” que requiere dicha aplicación, para que así al modificarlo y volver a compilarlo tengamos como resultado una sola aplicación DEX completamente independiente de otras librerías (por eso es necesario tener las librerías de “apoyo” de esta aplicación, código que será incluido en el propio DEX cuando compilemos de nuevo, y así poder prescindir del archivo ODEX e incluir el archivo DEX dentro de la aplicació). Al final de la conversión básicamente lo que tendremos será una aplicación DEX.

Vale, ya sabemos como se estructura una aplicación, y parece evidente los procesos de decompilar y volver a compilar (luego vemos como). Pero hay dos procesos que hay que realizar de igual forma, el firmado y el alineamiento. El firmado es obligatorio el alineamiento opcional (aunque recomendable).Cada uno será explicado a la par que vamos a usarlos. Empecemos, para no aburrir, con lo que tenemos entre manos.

El mini proyecto a realizar será parchear la aplicación gratuita del Market “SSHDroid”. Esta aplicación no es más que un servidor SSH para nuestro dispositivo, para poder tener acceso por SSH (Putty) o SCP (WinSCP) para poder copiar, borrar, mover… archivos de forma fácil. Es compatible (no de obligado uso) con teléfonos rooteados, lo que permite entonces un acceso total al sistema por los medios mencionados. Pues bien, esta aplicación se encuentra en dos versiones, la versión gratuita con publicidad y la versión de pago sin ella. Pues bien, iba a instalar la aplicación en el Market cuando leo en la descripción que la aplicación automáticamente no se arrancará si detecta que se ha usado algún sistema para bloquear la publicidad. Aquello la verdad es que me mosqueó, no porque me parezca bien o mal el uso de la publicidad, sino porque de igual forma ninguna aplicación tiene que decirme que tengo o no tengo que hacer. Así que después de que efectivamente comprobase que la aplicación se cerraba nada más abrirla me puse manos a la obra.

 

Al ser una aplicación del Store, es DEX, con lo cual es mucho más sencillo todo. Pero bueno, lo primero es evidentemente extraer la aplicación del dispositivo. Si este está rooteado, tan solo hay que acceder a la carpeta /data/app/ y copiar desde ahí el archivo “berserker.android.apps.sshdroid-1.apk” a la SD y de la SD al PC. O hacerlo si se prefiere por SSH o por ADB. El como extraerlo es indiferente, y pegarla en cualquier sitio que podamos manejarla de forma simple. Yo por comodidad tengo todas las utilidades que voy a usar en el Path de Windows, con lo que puedo invocarlas desde cualquier ubicación, lo que me permite no tener que estar usando las rutas completas mientras trabajo de forma sencilla desde mi directorio de trabajo.

Lo primero es suponer que sistema usa la aplicación para cerrarse, lo cual no es que sea muy complicado adivinarlo. Primero porque el sistema de bloquear la publicidad que uso es puramente un archivo Hosts, lo cual ya me dice que realiza la aplicación para detectarlo. Segundo porque esta aplicación y posiblemente muchas otras usan la plataforma de anuncios admob, la cual ya conozco bien por iPhone OS, y no es la primera ni será la última que parchee  (aunque el sistema para iPhone OS difiere al de Android). Básicamente la aplicación verifica si en el archivo hosts existe alguna entrada “admob”. Si existe la aplicación se cierra. Pues bien. hay una y mil manera para sortear esto, desde la más típica que consiste en continuar la ejecución exista lo que exista en el archivo hosts (sería cambiar básicamente un True por un false o un 1 por un cero) hasta la que voy a usar en esta ocasión, que se basa simplemente en engañar a la aplicación Básicamente con este sistema la aplicación si realiza una comprobación… pero no verificará el archivo /etc/hosts, sino un archivo que no existe, por ejemplo /etc/hostt (cambiando la s última por una t)

Si la suposición es correcta, en algún lugar del código de la aplicación quedará tipificado perfectamente el archivo “/etc/hosts”. Este sistema tiene la ventaja en que localizar el punto exacto es simple, solo tengo que buscar en el código por “/etc/hosts”. Claro que si el código está compilado, dicha cadena de texto no tiene porqué siquiera aparecer. Lo  interesante de este sistema es que tanto en iPhone OS como en Android esta cadena es visible sin necesidad siquiera de decompilar!! En el caso de iPhone es tan simple como editar hexadecimalmente el binario de la aplicación, buscar dicha cadena, modificarla y revalidad la firma. Además, dado que tan solo sustituyo un carácter por otro no corro el riesgo de tener que aumentar o disminuir el tamaño del archivo. Otra ventaja es que ni iPhone OS ni Android poseen sistema de verificación de hash dentro de los propios binarios, lo cual significa que puedo sin temor alguno cambiar una ‘s’ por una ‘t’ y quedarme tan pancho. Eso sí!! al realizar esto la firma en cualquiera de los dos casos se destruye!! No poseen verificación dentro del propio archivo (lo cual sería un “problema” porque habría que reconstruir el hash afectado) pero os recuerdo que todas las aplicaciones tienen que tener una firma válida, y como vimos en el artículo de firma digital cuando se modifica algo que esté bajo una firma digital, esta se destruye y se invalida, lo cual nos obliga a realizar una nueva firma. En Android podemos hacerlo porque Android nos permite firmar nosotros mismos lo que queramos, con iPhone OS podemso hacerlo porque el JB valida también las firmas que realizamos nosotros, no solo las de Apple.

Volviendo al asunto en cuestión, tendríamos dos opciones. La opción rápida sería descomprimir el contenido del apk, eliminar la firma anterior eliminando la carpeta “META-INF”, editar hexadecimalmente el archivo “classes.dex”, buscar la cadena citada y modificarla, guardar el archivo y volver a empaquetarlo en el apk (comprimirlo). Pero esto es posible por el truco explicado de la cadena de texto, que evidentemente es un caso excepcional y generalmente no puede hacerse así. Así que vamos a detallar el proceso ligeramente más largo (tampoco tiene mayor complejidad) q pasa por decompilar antes la aplicación.

Una vez tengamos la aplicación a mano, usaremos APKTool para decompilar toda la aplicación. APKTool decompilará el código para Dalvik y nos lo mostrará en digamos lo que podría ser el ensamblador de este (evidentemente no nos devuelve el código fuente .java):

E:\Android\Apps>apktool d berserker.android.apps.sshdroid-1.apk carpeta-decompilada
I: Baksmaling…
I: Loading resource table…
I: Decoding resources…
I: Loading resource table from file: C:\Users\Theliel\apktool\framework\1.apk
I: Copying assets and libs…

Como sabemos que tenemos que buscar exactamente, ni siquiera vamos a perder el tiempo cotilleando cada archivo decompilado. Para ello tenemos al buen amigo “grep”:

#grep -r hosts ./carpeta-decompilada

Lo cual nos devuelve casi de forma automática que el archivo implicado es “./carpeta-decompilada/smali/berserker/android/corelib/e.smali”. Por tanto podemos automáticamente ir a dicha ruta, abrir el archivo con un editor de texto cualquiera, buscar “hosts” y encontraremos rápidamente lo que buscábamos, la cadena “/etc/hosts”. Tan solo tendríamos que modificarla a “/etc/hostt” por ejemplo, y guardar el archivo. A partir de aquí es muy simple, ya que la misma aplicación apktool va a hacer todo el trabajo por nosotros:

E:\Android\Apps>apktool b carpeta-decompilada apk_sinfirmar_sinalineal.apk
I: Checking whether sources has changed…
I: Checking whether resources has changed…
I: Building apk file…

Llegado a este momento tendremos la aplicación correctamente compilada en un archivo apk completamente funcional, el problema es que antes de que podamos usarlo tendremos que firmarlo previamente y opcionalmente firmarlo.

Si recordamos, el iPhone OS tan solo puede ejecutar aplicaciones o contenido que ha sido firmado expresamente por Apple y por nadie más. Esto evidentemente impedía que cualquier usuario pudiese ejecutar alguna aplicación casera si así lo desease, y de ahí (entre otras muchas razones) el motivo por el cual se realiza el JB al iPhone OS. Pero Google no es Apple, afortunadamente. Google sí permite la ejecución de cualquier aplicación aunque no haya sido firmada por ellos. Es más, la única firma que se verifica es la del autor de la aplicación, la cual si es obligatoria claro. ¿Por qué? Bueno, básicamente es la garantía de que dicha aplicación no ha sido alterada por ningún intermediario, a la vez que la legitimiza. Pero cualquiera puede crear una aplicación para Android, compilarlar, firmarla e instalarla en su dispositivo!! y para ello no hace falta absolutamente nada, ni que el dispositivo esté rooteado ni nada.

Para firmarlo usaremos las herramientas estándares de JAVA: keytool para la generación del almacén de claves y nuestras claves y jarsigner para firmar la aplicación. Vamos a suponer que el usuario no tiene aun claves para firmar la aplicación:

E:\Android\Apps>keytool -genkey -v -keystore almacen-android -alias Theliel -keyalg RSA -keysize 2048 -validity 3650

Dicho comando nos creará en la carpeta actual un almacen de claves llamado almacen-android, el alias de dicha clave en dicho almacen, el tipo de key (RSA-2048) y la validad de la clave (10 años). Tendremos que introducir una serie de parámetros, como nuestro nombre, contraseña para el almacén y para nuestra clave… etc. El caso es que cuando terminemos tendremos lista el par de claves necesarias. Ya solo queda firmar la aplicación:

E:\Android\Apps>jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore ./almacen-android ./apk_sinfirmar_sinalineal.apk Theliel
Enter Passphrase for keystore:
Enter key password for Theliel:
adding: META-INF/MANIFEST.MF
adding: META-INF/THELIEL.SF
adding: META-INF/THELIEL.RSA
signing: assets/dropbear/dropbear

Una vez terminado el proceso, podemos renombrar dicho archivo a apk_sinalineal.apk, puesto que en ese momento ya estaría firmado.

 

Por otro lado el alineamiento se realiza por una cuestión de mejora de rendimiento. Por diseño, Dalvik es super eficiente a la hora de gestionar el consumo de recursos, intentando en la medida de lo posible usar la mínima RAM posible (entre otras cosas). El alineamiento lo que realiza es asegurarse de que todo el contenido (que no esté comprimido) dentro del APK comience en un offset (un desplazamiento) concreto, particularmente se desea que el comienzo de cada archivo en el APK comience en un bloque de 4 Bytes (32 bits). El alineamiento es indiferente al contenido comprimido dado que antes de poder acceder a este debe de ser extraído del paquete apk, pero el contenido en el apk no comprimido puede ser accedido directamente sin necesidad de extraerse siquiera. Se podría pensar que todo el contenido dentro del apk (que básicamente es un archivo zip… por así decirlo) estará comprimido, pero la mayoría de compresores ignoran ciertos archivos cuando estos son claramente no compresibles (o mínimamente) como por ejemplo imágenes, audio, video… Esto dicho así es complicado de entender, pero es mucho más fácil si se muestra con un ejemplo.

Las dos siguientes imágenes muestran la ubicación interna de la imagen key.png dentro del apk abierto por un editor hexadecimal, el mismo apk, uno antes de alinearse y el otro alineado. Como se puede apreciar, aunque el contenido es exactamente igual, uno parece estar desplazado 6 Bytes hacia la derecha:

APK No Alineado

 

APK Alineado

Una imagen PNG comienza exactamente con los bytes hexadecimales “89 50 4E 47”. Si vemos las imágenes anteriores, en el APK no alineado la imagen comienza en el offset 2E1E6. mientras que el alineado en el offset 2E1EC. Básicamente todo lo que comenté antes, es que para que el APK esté alineado, todo los contenidos que no estén comprimidos dentro del APK (como esta imagen) deben de poseer un offset múltiplo de 4 bytes), es decir, el último valor hexadecimal de su offset global deberá ser 0, 4 8 o C. El primero efectivamente comienza en el offset relativo 6, que no pertenece a un inicio de bloque de 4 Bytes y por tanto no está alineado. Una vez que se alinea el APK, este pasa a estar en un offset relativo C, el cual es el comienzo de un bloque de 4 Bytes y por ende está alineado.

Esta alineación permite al sistema Android acceder directamente a la posición en la que se encuentran dichos datos, minimizando el uso de RAM (de lo contrario, posiblemente haría falta extraer el APK completo, no solo los archivos comprimidos, sino que para acceder a los archivos descomprimidos habría que extraerlos también del APK, mientras que de este modo los elementos no comprimidos pueden ser accedidos directamente desde el APK).

Por algún sitio en la web he leído que la alineación hay que hacerla antes de la firma. No!! La firma va dentro del propio APK, con lo que si se firma después de alinear, la firma destruirá el alineamiento, haciendo la aplicación menos eficiente. No significa que Android no funcione con aplicaciones no alineadas, ojo, significa que usará sensiblemente más RAM. La pregunta que todos se harán en este momento es si realmente las aplicaciones que descargamos del Market o no están correctamente alineadas… o no. Invito a cada cual que investigue, pero de ya le digo que muchas están sin alinear.

¿Como se alinea? Con la aplicación zipalign, especificando el offset relativo que se desea dar a la alineación. En este caso deseamos bloques de 4 Bytes, por tanto el valor a especificar será de 4. Tenemos dos comandos igualmente útiles, uno para alinear y otro para comprobar el alineamiento (como he dicho útil para ver como de despistados son los programadores, y eso que cuando se configura bien el IDE para programar en Android el proceso debería de ser completamente transparente para el programador… curioso como las malas prácticas en la programación se extienden aun cuando es algo simple de realizar y que nos otorga un buen pellizco de RAM extra)_

E:\Android\App>zipalign -v 4  apk_sinalineal.apk apk_alineada.apk
Verifying alignment of apk_sinalineal.apk (4)…
50 META-INF/MANIFEST.MF (OK – compressed)
906 META-INF/THELIEL.SF (OK – compressed)
1819 META-INF/THELIEL.RSA (OK – compressed)

Si quisiésemos simplemente verificar el alineamiento lo realizaríamos con la linea “zipalign -c -v 4 apk_paraverificar.apk. Los archivos comprimidos se mostrarán como OK – Compressed, los archivos alineados como OK y los archivos no alineados como (BAD – X) siendo X el número de desplazamientos necesarios para su alineamiento… es decir, que no se ha alineado la aplicación.

A este paso ya podemos renombrar nuestra aplicación modificada a su nombre de origen por ejemplo: berserker.android.apps.sshdroid-1.apk

Si queremos estar completamente seguro de nuestro éxito, lo mejor será primero desinstalar primero la aplicación que ya tenemos en nuestro dispositivo. Una vez realizado, podemos proceder a instalar nuestra aplicación modificada con ADB: “adb install berserker.android.apps.sshdroid-1.apk”, y ya solo nos quedará verificar si la aplicación se abre o no se abre:

 

Como ya he dicho, ni que decir tiene que esto no es sino un ejemplo de como se podría realizar ingeniería inversa a cualquier aplicación que deseemos. Recordar, que esto es una práctica completamente legal (al menos aquí en España), y que esto nos abre la oportunidad no solo de realizar como hemos visto aqui un pequeño “parche” para poder abrir la aplicación sin tener que renunciar a nuestros anti-publicidad, sino que imaginar que hubiésemos aprovechado para cambiar el color de la interfaz, o el icono de la aplicación, o los textos de esta o… cuestiones que bien conocen los que les gusta el modding,que no el parching. Por ejemplo, mi Market no es verde, es Lavanda

Theliel.

Beeeeeeeeeee… dicen las ovejas

Lo siento, pero después de reírme un rato lo tenía que publicar. Este anuncio es el que Motorola usará durante la SuperBowl por lo visto, quieren sacar los colores (nunca mejor dicho) a alguien…

Conste que cachondeo a parte, estoy completamente en desacuerdo con la publicación de este tipo de spots, que lo único que hacen es criticar en vez de preocuparse por los productos de uno mismo… pero tengo que reconocer que se lo han currado tela.

Android: Nuevo Market online

Que la web del Market de Google era un poco porquería no era un secreto. A ver, personalmente pienso que iTunes es el programa más puerco que existe, pero al menos te permitía más o menos explorar las aplicaciones y descargarlas si así se deseaba en iPhone OS. Los usuarios de Android hasta la fecha estaban “condenados” a hacerlo todo por El Market instalado en sus dispositivo, ya que la web del Market era bastante limitada… como digo era un desastre.

De echo, era raro que Google no hubiese cuidado un poquito más dicha web… y ya le ha puesto solución. La gran mayoría que está acostumbrado a hacerlo todo desde su dispositivo pensará que no aporta nada nuevo… pero nada más lejos, en realidad lo hace, y en mucho. Veamos, la ventaja de iTunes para comprar aplicaciones o descargarlas era que usas un PC, es infinitamente más rapido, más intuitivo hacerlo todo en el monitor que en el dispositivo. Pero claro, iTunes no solo es un programa basura, sino que además al final siempre tenías que terminar conectando para actualizar o instalar aplicaciones y esas cosillas. Google ha superado con creces este modelo con la nueva web del Market:

Pero… ¿que tiene de especial? Imaginar la sección de AppStore de iTunes pero en vez de en un programa, en una web super fluida que funciona en cualquier lugar, y no hace falta instalar. Pues es exactamente eso. No solo nos permite buscar cualquier aplicación, sino que como se ve en la imagen, si hemos iniciado sesión en nuestra cuenta de Google, nos mostrará las aplicaciones que ya tenemos instaladas, o por supuesto nos da la opción de instalarla cualquiera que deseemos… y no, evidentemente no hace falta ningún cable, la descarga será añadida de forma automática a nuestro market en nuestro dispositivo!! y sin hacer absolutamente nada en nuestro dispositivo esta se descargará y se instalará en él.

No solo eso, podemos acceder a nuestra cuenta de Market cuando deseemos y tendremos un registro con todas las aplicaciones que tenemos instaladas, así como algunas opciones más. Ahora, si estamos trasteando y queremos ver que aplicaciones instalar, creo que la gran mayoría agradecerá este bonito gesto por parte de Google.

¿Es mejorable? Si. Personalmente creo que Google tendría que habilitar ya la posibilidad de pago por Paypal. Es cierto que Google lo evita para fomentar su Google Checkout, pero creo que se ganarían algunos puntos extra soportando también el sistema de pago mayoritario en Internet (Evidentemente quitando los pagos directos con tarjeta). Para mi era como digo uno de los puntos flacos de Google, y tengo que decir que al menos para mi se agradece, y supera con creces al AppStore a través de iTunes (ya sea PC o dispositivo), que como digo peor programa no se ha creado en los anales del tiempo.

Android: Streaming PC -> Android

Antes que nada para quien ande despistado, Streaming PC -> Android, básicamente es poder reproducir en nuestro dispositivo audio o música que no están físicamente en él, estando generalmente en nuestro PC. El objetivo va a ser simple, tener TODA nuestra música y vídeos en el dispositivo, o al menos parecer que lo tenemos. En mi caso, si abro por ejemplo la aplicación Winamp o Música (la que trae por defecto) tengo acceso a más de 150GB de música y más de 500GB de vídeos)

Estaba visitando algún que otro foro cuando me llamó la atención que más de un forero preguntaban cual era la mejor opción para realizar Streaming desde un PC a un dispositivo Android. Lo gracioso es que el 90% de todas las respuestas eran siempre las mismas: Que si las mismas aplicaciones que lo hacen posible en iPhone, que el programa y aplicación Orb, que si Subsonic, que si…

Todas las soluciones que se daban pasaban por instalar un programa en el PC y otro en el dispositivo. Además, en la mayoría de los casos si se deseaba usar la función para poder hacer Streaming via WAN (no dentro de la propia red local) hacía falta tener uan cuenta dada de alta en los servicios de estos programas, con lo que pueda implicar en ello la privacidad de nuestros datos (a saber que estadísticas o datos guardan de nosotros esos sites).

Lo bonito de la informática y de los estándares es que cuando se hacen las cosas bien generalmente te ahorras dinero y tiempo/trabajo, a la vez que ganas en seguridad, facilidad y en este caso también rapidez. Estas aplicaciones te obligan a instalar programas absurdos en el PC, programas con publicidad, recopilación de datos… y todo ello puede hacerse simplemente con instalar en este caso una “aplicación” y media en Android, sin instalar absolutamente nada en nuestro PC. Y digo “aplicación”, porque en realidad si nuestro dispositivo lo soporta, la “aplicación” no es más que una interfaz gráfica de utilidades linux que ya están presentes en el dispositivo.

Esto no es ninguna magia. Como todos saben (y quien no lo sepa hoy ya lo va a saber) todos los sistemas Windows, Linux y MAC OS incluso permiten el uso del protocolo SMB de Microsoft (Service Message Block… el nombre no es que sea muy intuitivo). Básicamente SMB es el protocolo para compartir carpetas/archivos en red de forma mayoritaria. En Linux o MAC OS se suele leer o suena más como SAMBA, que no es más que una implementación de este protocolo. En otros lugares también se le conoce como CIFS (Common Internet File System). Dejando a un lado el nombre, básicamente este protocolo es el que nos permite en Windows hacer clic derecho en una carpeta y compartirla para que cualquier otro dispositivo tenga acceso a ella. Tan fácil como eso. ¿Y sinceramente… por qué no usar esto para Android? Vamos a ver lo que tendríamos que hacer. El objetivo final es que cuando yo acceda a mi biblioteca de música dentro cualquier aplicación Android de reproducción de medios (Aplicación Música, Vídeos, Winamp…) no solo aparezca la música que poseo sino toda la música disponible en mi red:

  • Compartir los recursos de la red en los equipos donde dicha música se encuentre
  • Tener un dispositivo Android compatible con CIFS
  • Instalar un gestor CIFS (por comodidad) y montar la carpeta de red
  • Hacer que Android reconozca la carpeta
  • Forzar la actualización de medios en nuestro dispositivo
  • Opcional -> Permitir el acceso remoto (desde WAN) a nuestros recursos

Aunque parezcan muchos puntos, en realidad todo ello se realiza en un par de minutos máximo, no se requieren conocimientos de nada, y es bastante simple.

 

  1. ¿Como se comparten recursos de red?

    Bueno, esto no es que sea el tema principal. Depende de si usamos por ejemplo Windows Vista/7 o XP. El proceso es similar de todos modos. Primero nuestro equipo tendrá que reconocer nuestra red como red privada o de trabajo para que la detección de red esté activada por defecto. También recomiendo no usar las funciones de compartición en el hogar, soy de los que prefiere el sistema tradicional. Visto esto, tan solo hay que coger por ejemplo nuestra carpeta donde se encuentra toda nuestra música, en mi caso por ejemplo todo el contenido audio/visual se encuentra en dos sitios: Un HDD externo conectado al router y una unidad en mi propio equipo. En el caso de mi equipo tan solo tengo que realizar un botón derecho compartir, uso compartido avanzado… establecer un nombre al recurso de la red (anotar que nombre se le pone, importante) y por defecto debería de ser suficiente. En el caso del router es similar, salvo que toda la gestión se hace a través de este. Con ello, todos los equipos de la red serían capaces de detectar el nuevo recursos de la red, con lo que podrán reproducir cualquier contenido de este. Ojo!! Dependiendo de la seguridad de nuestro equipo y como se halla configurado la compartición, es posible que dichos recursos estén a disposición de todos o solo a aquellos que tengan un usuario y contraseña concretos

     

  2. ¿Como puedo tener un dispositivo Android compatible con CIFS?

    En la actualidad existen de serie dispositivos que poseen los módulos en el kernel para CIFS, pero en el caso de que no se tenga, prácticamente todos los dispositivos Android tienen a sus disposición Kernels con soporte para CIFS, y aun cuando no lo sean, siempre pueden descargar el módulo pertinentel, copiarlo en la carpeta de sistema por una de las muchas formas que se pueden hacer, generalmente en el Path “/system/lib/modules”  y problema resuelto. El archivo que pongo a continuación son dos módulos, el primero es para CIFS, el segundo es un agregado que como veremos más adelante nos evita problemas con los caracteres españoles:

    Módulos para CIFS

    Estos módulos deberían de ser compatibles con la gran mayoría de todos los Kernels. Por supuesto como he dicho, siempre y cuando ya de por sí no tengamos un Kernel con soporte para CIFS.

     

  3. ¿Como instalar y configurar un gestor CIFS y montar la carpeta? ¿Como hacer que nuestro dispositivo la reconozca?

    San Google no tiene restricciones absurdas en el Market como Apple en su AppStore. Cualquier dispositivo Android puede acceder al Market e instalar de forma gratuita la aplicación CIFS Manager. Dependiendo del soporte que tenga nuestro dispositivo en el Kernel, será necesario (o no) tener nuestro dispositivo rooteado. Aquí vamos a interpretar que sí lo tenemos. Tan solo se trata de configurar el cliente CIFS con los ajustes que previamente configuramos en nuestro Windows.

    En primer lugar la dirección IP (o dominio) del recurso compartido, así como su nombre. Si esta en el equipo 192.168.100.200 y el recurso se llama perico, habría que poner “192.168.100.200/perico”. Por supuesto el usuario y la contraseña que tienen permiso para acceder a dicho recurso, y para acabar el punto de montaje, que vamos a dejarlo de momento por defecto, que creo que era /mnt/cifs. Lo que hace el punto de montaje es especificar la ruta en nuestro dispositivo donde se montará el recurso compartido…. es decir que si accediésemos con un gestor de archivos a dicha ruta, al entrar en dicha carpeta estaríamos entrando al recurso compartido. Por último, se pueden especificar o no otras opciones, pero eso lo veremos más adelante. Simplemente con esto, si usásemos cualquier gestor de archivos ya podríamos acceder al contenido de nuestro recurso compartido, y si lo abriésemos desde el explorador de archivos el txt, el audio, el video… que exista en él, lo abriría nuestro dispositivo con la aplicación asociada.

     

  4. ¿Como hacer que Android reconozca la carpeta montada para que realmente parezca como si toda la música/video estuviesen en nuestro dispositivo?

    Bueno, esto es una cuestión meramente de lógica. Por regla general, cuando nuestro dispositivo arranca se ejecuta un servicio de Android que escanea nuestra SD en busca de nuevos contenidos multimedias. Recordar que Android no es como iPhone que tienes que pasar obligatoriamente por iTunes para añadir audio, vídeos o imágenes por ejemplo, en Android copias cualquier contenido que desees en la SD y este aparecerá en su respectiva aplicación, así de simple!! En iPhone OS no solo lo tienes que hacer a través de iTunes, sino que tan solo puedes tenerlo sincronizado con tu PC, en nuestro caso, el caso de los Androides, con montar la tarjeta SD en el equipo que sea podemos copiarnos del PC que sea el contenido que deseemos y listo, cuando abramos nuestro reproductor de vídeo, de audio o nuestro visor de fotos aparecerá todo.

    Visto esto, es simple. Si en vez de montar nuestro recurso compartido en la carpeta de sistema /mnt/cifs (que es la que viene por defecto) la montamos en “/sdcard/Medios” (por ejemplo), estaremos montando el recurso dentro de la propia SD (casi todos los Androides montan la SD en dicha ruta). Eso quiere decir que una vez montada la unidad (si tenemos conexión a la red claro) el sistema escanea de nuevo los medios en busca de nuevo contenido multimedia, escaneará también y tendrá en cuenta TODO el contenido de nuestro recurso compartido

    Ahora bien. Aquí aparece un pequeño problema que si no se sabe reconocer a más de uno le puede dar problemas y dolor de cabeza, así que mejor explicarlo. En España tenemos acentos, eñes y otros caracteres que en muchos países no existen. ¿Que sucede? Windows usa el estandar UTF-16  para la codificación de caracteres en el sistema de archivos, pero CIFS no tiene por qué haber sido compilado para tal. Si CIFS no soporta al menos UTF-8, todos los recursos de red que contengan por ejemplo acentos o caracteres latinos, no serán leídos correctamente, y además producirán un fallo que impedirá el correcto escaneo de los medios. Esto tampoco tiene mayor problema, tan solo hay que tener en cuenta que hay que cargar el módulo nls_utf8.ko en el sistema y especificar en las opciones de CIFS que se use la codificaicón UTF8. Lo primero se hace dentro de los ajustes generales de CIFS, donde pone: “Path to cifs.ko”. De echo, cuando configuramos CIFS con CIFS manager, si tenemso el módulo CIFS.ko en otra ubicación lo tendremos que especificar ahí. Tan solo hay que añadir el módulo especificado, por ejemplo: “/system/lib/modules/cifs.ko:/system/lib/modules/nls_utf8.ko” y de este modo se cargarán ambos módulos. Una vez esto se realiza, en las opciones de nuestra carpeta montada (en CIFS manager) nos vamos a “Options”, especificamos que se use UTF8: “iocharset=utf8”

     

  5. ¿Como forzar la actualización de contenido multimedia?

    Es posible que el contenido no aparezca poco a poco en nuestra “biblioteca”, puesto que sería absurdo que nuestro dispositivo estuviese constantemente actualizándola. La mejor forma de forzarla sería con la aplicación SDrescan (en Market). Tan solo hay que abrirla y esperar que escanee. Evidentemente si hemos compartido un recurso de red con miles de canciones, tardará más en realizar la actualización completa. También si lo deseamos, podemos deshabilitar la actualización automática de medios con la aplicación “rescan media” y usar SDrescan solo cuando nosotros lo deseamos. Para gustos los colores. Si hacemos esto, ahora si comenzarán a ir apareciendo poco a poco todo lo que tengamos en la carpeta/unidad de nuestro recurso compartido.

     

  6. ¿Se puede reproducir la música o los vídeos o ver las fotos aunque estemos en la otra parte del mundo?

    Por supuesto, aunque para ello si tendremos que tener preparados antes una pequeña infraestructura. Personalmente recomiendo siempre cualquier tecnología o protocolo que no haya que instalar, si ya tenemos las herramientas para que vamos a buscar otras que cuestan incluso dinero, son más lentas y son peores. La respuesta más simple es VPN.

    Los accesos VPN nos permiten acceder a nuestros recursos de red local aun cuando estamos en la otra parte del planeta. El único pero es que tenemos que disponer de un router o programa o… que tenga creado un servidor VPN. Muchos routers actuales permiten servidores VPN de forma sencilla como por ejemplo PPTP, aunque muchos otros nos permiten escoger desde PPTP, L2TP, IPSec, OpenVPN, Cisco VPN… para poder tener una infraestructura así que funcione bien también haría falta tener una IP estática o un servicio de DDNS en el router, que nos permita conocer siempre y en cada momento la dirección de nuestra red. Con estas dos herramientas, tan solo tendríamos que crear en nuestro Android la conexión VPN especificando el tipo de protocolo, usuario, contraseña… y ya está. Una vez todo preparado, bastaría tan solo con activar cuando fuese deseado la conexión VPN, montar en ese momento el recurso compartido y a disfrutar. Al conectarnos por VPN, tendremos acceso a los recursos de nuestra red, incluido por tanto las carpetas/unidades compartidos por nuestros equipos o directamente por el router/switch.

    Parece que no explico paso a paso como hacerlo, pero es que cada router es diferente, y configurar la conexión VPN en Android es tan sencillo como ir a conexiones inalámbricas, conexionese VPN y crear la que deseemos con los datos requeridos, no tiene pérdida. (La llave que aparece en la siguiente imagen significa que se está conectado a una red por VPN)

 

Ni que decir tiene, que con las conexiones WIFI actuales es posible no solo hacer en Streaming música, sino vídeos hasta a un buen y considerable bitrate, más que suficiente para ver lo que sea en nuestro dispositivo

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.