Questo post è stato modificato l'ultima volta da Summer il 14-10-2025 alle 22:59
Una versione della telecamera virtuale che è stata hackerata dall'autore in precedenza ha pubblicato un video su Bilibili
Anche la versione precedente che avevo rotto era rotta
Collegamento:Il login del link ipertestuale è visibile.
Recentemente, un cliente mi ha chiesto di decifrare un'altra versione della telecamera virtuale dello stesso autore e semplicemente studiarla
Controlla prima il guscio, rinforzo senza Bangbang, relativamente semplice, basta una semplice rilevazione di Frida, il link sopra ha fatto un'analisi molto dettagliata del rinforzo e della rilevazione della versione senza Bangbang, usando vari strumenti come ebpf
Prima con Frida, ci sono segni di crash, potrebbe essere che il passo venga iniettato troppo presto, oppure che l'indirizzo non sia accessibile quando il gancio è pronto, correggendo il codice hook dello script a frida
In generale, il tempo di iniezione era leggermente ritardata, risolvendo il problema dei crash dell'iniezione
Hook Il processo della sua attivazione riceve i dati restituiti dall'attivazione, e deve chiedere al server di verificare che abbia ottenuto il timestamp di attivazione
All'utente viene poi assegnato tempo calcolando la differenza di tempo.
Questa telecamera virtuale richiede anche i permessi root, altrimenti non c'è comunicazione tra i processi di versione,
In totale, questa fotocamera ha iniziato tre processi
Uno è il processo principale dell'app camera, che è la comunicazione tra il livello Java e quello C++
Il secondo è che il processo principale esegue il parametro di input eseguibile binario vcmplay sulla riga di comando attraverso il livello Java per avviare il secondo processo, che è principalmente responsabile della comunicazione tra il processo principale della camera vcmpaly e il processo libvc.so che viene iniettato nel servizio camera camera del sistema, e il principale mezzo di comunicazione è ibinder.
Il terzo è il file SO del cameraserver iniettato nel servizio di sistema.
Se l'applicazione non può ottenere privilegi root o c'è un problema di rete, il processo non si avvierà
Questa telecamera necessita di un codice di attivazione per essere attivata e utilizzata, e analizzando il livello Java, tutte le sue interfacce vengono collegate
L'attivazione richiede di richiedere al server di ottenere le informazioni di verifica
I dati che ottieni sono tutti criptati
Analizzando l'eseguibile binario VCMPLAY, possiamo ottenere che i dati richiesti sono crittografia RSA, e la chiave è localizzata tramite lo strumento EBPF di stackplz, e la chiave di crittografia è di 128 bit
Un'altra parola
Questa applicazione è molto astuta, ha aggiunto un suffisso so a vcmplay, che fa pensare alle persone che sia un file SO e che debba essere caricato nella memoria di Java, ma in realtà è un altro processo.
Ho collegato il server cameraserver del servizio telecamere libvc.so ho scoperto che Frida si è bloccato non appena il servizio Attachment Camera è andato in crash, non so se sia stato rilevato, l'ho analizzato a lungo e ho scoperto accidentalmente che VCMPLAY si è interrotto una volta, ed è riuscito a collegare. Si sospetta che possa essere stato il processo VCMPLAY a rilevare il processo cameraserve
Ho usato ida per debugare il processo VCMpay, e ho scoperto che aveva ancora l'anti-debugg, ho scansionato il tracepid in proc/self/status per capire se fosse stato debuggado, e ciò che è stato ancora più spaventoso è che ha scoperto che l'anti-debugging non era un crash del programma, aveva effettivamente cancellato file importanti nel sistema Android tramite i permessi root, poi il telefono si è riavviato in stato di doppia cancellazione, e il sistema doveva essere inizializzato per entrare nel sistema, e tutto nel telefono era sparito. Ho scritto il modulo kernel hook kpm tramite kernelpatch e ho bypassato il debug
Dopo diverse notti insonni qui, la logica generale è stata chiarita e si stima che non sarà facile da decifrare.
Continuerà in seguito......
|
Pubblicato il 14-10-2025 10:40:57
|
|
|
|
