Esta publicación fue editada por última vez por Summer el 14-10-2025 a las 22:59
Una versión de la cámara virtual que el autor ya había hackeado anteriormente ha publicado un vídeo sobre Bilibili
La versión anterior que rompí también estaba rota
Enlace:El inicio de sesión del hipervínculo es visible.
Recientemente, un cliente me pidió que descifrara otra versión de la cámara virtual del mismo autor y simplemente la estudiara
Comprueba primero la carcasa, refuerzo sin Bangbang, relativamente sencillo, solo una detección sencilla de Frida, el enlace anterior ha hecho un análisis muy detallado del refuerzo y detección de la versión sin Bangbang, usando varias herramientas como ebpf
Primero con frida, hay señales de crash, puede ser que el paso se inyecte demasiado pronto, o que la dirección sea inaccesible cuando el gancho está listo, corrigiendo el código del gancho del script a frida
En general, el tiempo de inyección se retrasó un poco, lo que resolvió el problema de los fallos de inyección
Hook El proceso de su activación recibe los datos devueltos por la activación, y necesita pedir al servidor que verifique que obtuvo la marca de tiempo de activación
Al usuario se le asigna tiempo calculando la diferencia de tiempo.
Esta cámara virtual también solicita permisos root, de lo contrario no hay comunicación entre procesos de versiones,
En total, esta cámara tiene tres procesos iniciados
Uno es el proceso principal de la aplicación de cámara, que es la comunicación entre procesos entre la capa Java y la capa C++
El segundo es que el proceso principal ejecuta el parámetro binario ejecutable vcmplay en la línea de comandos a través de la capa java para iniciar el segundo proceso, que es principalmente responsable de la comunicación entre el proceso principal del vcmpaly de cámara y el proceso libvc.so que se inyecta en el servicio de cámara cámara del sistema, y la forma principal de comunicación es ibinder.
El tercero es el archivo SO del cámara cámara inyectado en el servicio del sistema.
Si la aplicación no puede obtener privilegios root o hay un problema de red, el proceso no se iniciará
Esta cámara necesita un código de activación para activarse y usarse, y al analizar la capa Java, todas sus interfaces se conectan
La activación requiere solicitar al servidor que obtenga la información de verificación
Los datos que obtienes están todos cifrados
Analizando el ejecutable binario VCMPLAY, podemos obtener que los datos solicitados son cifrado RSA, y que la clave está localizada a través de la herramienta EBPF de stackplz, y que la clave de cifrado es de 128 bits
Una palabra más
Esta aplicación es muy astuta, añadió un sufijo so a vcmplay, lo que hace pensar a la gente que es un archivo SO y que necesita cargarse en la memoria de Java, pero en realidad es otro proceso.
Conecté el servidor de cámara del servicio de cámara libvc.so descubrí que Frida se bloqueaba en cuanto se bloqueaba el servicio de conexión de cámaras, no sé si fue detectado, lo analicé durante mucho tiempo y accidentalmente descubrí que VCMPLAY había muerto una vez, y pudo conectarse. Se sospecha que podría ser el proceso de VCMPLAY el que detectó el proceso de cámara
Usé ida para depurar el proceso de VCMpay, y vi que aún tenía anti-depuración, escaneé el tracepid en proc/self/estado para determinar si estaba depurado, y lo que fue aún más aterrador fue que descubrió que el anti-depuración no era un fallo del programa, sino que borró archivos importantes del sistema Android mediante permisos root, y luego el teléfono se reinició en estado de doble borrado, y el sistema tuvo que inicializarse para entrar en el sistema, y todo lo que había en el teléfono desapareció. Escribí el módulo de gancho del kernel kpm vía kernelpatch y evité la depuración
Tras varias noches sin dormir aquí, se ha descifrado la lógica general y se estima que no será fácil de descifrar.
Continuará más adelante......
|
Publicado el 14-10-2025 10:40:57
|
|
|
|
