Dette innlegget ble sist redigert av Summer 14.10.2025 kl. 10:59
En versjon av det virtuelle kameraet som tidligere har blitt hacket av forfatteren, har lagt ut en video på Bilibili
Den forrige versjonen jeg knakk var også sprukket
Lenke:Innloggingen med hyperkoblingen er synlig.
Nylig ba en kunde meg knekke en annen versjon av det virtuelle kameraet av samme forfatter og bare studere det
Sjekk granaten først, Bangbang gratis forsterkning, relativt enkelt, bare en enkel deteksjon av Frida, lenken ovenfor har gjort en svært detaljert analyse av forsterkning og deteksjon av Bangbang gratis versjon, ved bruk av ulike verktøy som ebpf
Hook med Frida først, det er tegn på krasj, det kan være at fotsteget er injisert for tidlig, eller adressen er utilgjengelig når hooken er klar, ved å korrigere skriptets hook-kode til Frida
Generelt ble injeksjonstiden litt forsinket, noe som løste problemet med injeksjonskrasj
hook Prosessen med aktiveringen hans får dataene returnert av aktiveringen, og han må be serveren om å bekrefte at han har fått aktiveringstidsstempelet
Brukeren får deretter tid ved å beregne tidsforskjellen.
Dette virtuelle kameraet ber også om root-tillatelser, ellers finnes det ingen versjonskommunikasjon på tvers av prosesser,
Totalt har dette kameraet startet tre prosesser
Den ene er hovedprosessen i kameraappen, som er kryssprosesskommunikasjon mellom Java-laget og C++-laget
Den andre er at hovedprosessen kjører den binære kjørbare vcmplay-inputparameteren på kommandolinjen gjennom java-laget for å starte den andre prosessen, som hovedsakelig er ansvarlig for tverrprosesskommunikasjon mellom hovedprosessen til kamera-vcmpaly og libvc.so-prosessen som injiserer i kamerakameratjenesten i systemet, og hovedkommunikasjonsmåten er ibinder.
Den tredje er SO-filen til kamerakameraserveren som er injisert i systemtjenesten.
Hvis applikasjonen ikke kan få root-rettigheter eller det oppstår et nettverksproblem, vil prosessen ikke starte
Dette kameraet trenger en aktiveringskode for å aktiveres og brukes, og ved å analysere Java-laget blir alle grensesnittene koblet ut
Aktivering krever at serveren ber om å hente verifiseringsinformasjonen
Dataene du får er alle kryptert
Ved å analysere VCMPLAY binære kjørbare fil kan vi få ut at de forespurte dataene er RSA-kryptering, og nøkkelen er lokalisert gjennom EBPF-verktøyet til stackplz, og krypteringsnøkkelen er 128 biter
Ett ord til
Denne applikasjonen er veldig utspekulert, han la til et so-suffiks i vcmplay, som får folk til å tro at det er en SO-fil, og at den må lastes inn i Javas minne, men det er faktisk en annen prosess.
Jeg koblet kameratjenesten til kameraserveren libvc.so fant ut at Frida krasjet så snart Attach Camera-tjenesten krasjet, jeg vet ikke om det ble oppdaget, jeg analyserte det lenge, og oppdaget ved et uhell at VCMPLAY døde én gang, og det klarte å hooke. Det mistenkes at det kan være VCMPLAY-prosessen som oppdaget Cameraserve-prosessen
Jeg brukte ida til å feilsøke VCMpay-prosessen, og fant ut at han fortsatt hadde anti-feilsøking, skannet tracepiden i proc/self/status for å finne ut om den var feilsøkt, og det som var enda mer skremmende var at han fant ut at anti-feilsøkingen ikke var et programkrasj, han slettet faktisk viktige filer i Android-systemet via root-tillatelser, og så startet telefonen på nytt til dobbel-clearing-tilstand, og systemet måtte initialiseres for å komme inn i systemet, og alt i telefonen var borte. Jeg skrev kernel hook-modulen kpm via kernelpatch og omgikk feilsøking
Etter flere søvnløse netter her er den generelle logikken funnet ut, og det anslås at det ikke vil være lett å knekke.
Fortsettelse følger......
|
Publisert 2025-10-14 10:40:57
|
|
|
|
