En primer lugar, gracias a los que tuvieron a bien menear la noticia anterior. Hizo portada en meneame y aprendimos por las malas lo duro que puede ser eso. Ahora alguien tiene en el ToDo asegurarse de que el blog aguanta mas 🙂

En cuanto al bicho del telefono, tras inputs de varias personas(fundamentalmente @timstrazz @michalmalik  @MalwareMustDie y los propios comentarios de la entrada anterior), hemos hecho entre todos algunos avances..

El binario guarda su configuración en el archivo /system/bin/unint8int, que aunque esta en el path y con permisos de ejecucion en realidad es una base de datos SQLite.

Por otro lado, estuvimos buscando como vendria eso vinculado a algun apk. en teoría parece que debiera haber algo así como un android.debugs.bin, pero no aparecio en el sistema. (Buscado a traves del comando pm list packages -f)

La gente de @MalwareMustDie hico un poco de ingenieria inversa del binario y lo colgo en un Pastebin. Ahi se referencia a otra base de datos, que pudiera indicar un apk vinculado al malware. “/data/data/com.mediatek.mobileaudioconnction/databases/audio.db” . El formato de esta BD es la misma es igual que la anterior, pero con menos datos almacenados (al menos en este momento, pero desde luego, el IMEI del telefono que aparece en ese archivo no parece tener mucho que ver con nada de audio)

En este caso si que existe un apk, MTKAudioAssistant.apk que parece estar vinculado con ello. Un decompilado rapido nos muestra que esas clasess estas presentes com.mediatek.mobileaudioconnction (siempre me va a llamar la atencion que sea connction .. sin la e)

Dentro del DebugBinBroadcast (aqui os lo dejo en otro pastebin http://pastebin.com/0sgVqU6K) puede verse como el programa va adquiriendo informacion del dispositivo y la almacena en su SQLite

.

Tengo que acabar de leermelo con calma, porque desde luego tengo curiosidad por ver que mas esta haciendo, pero cuanto mas miro, mas cosas raras encuentro en el telefono 🙂