Ezt a bejegyzést utoljára Summer szerkesztette: 2025-10-14, 10:59
A virtuális kamera egy változata, amelyet a szerző korábban feltört, videót tett közzé Bilibiliről
Az előző verzió, amit megtörtem, szintén megrepedt volt
Láncszem:A hiperlink bejelentkezés látható.
Nemrég egy ügyfél megkért, hogy törjek fel egy másik verziót a virtuális kamerából ugyanattól a szerzőtől, és egyszerűen tanulmányozzam azt
Először a héjat nézd meg, Bangbang-mentes megerősítés, viszonylag egyszerű, csak egy egyszerű Frida detektálása, a fenti link nagyon részletes elemzést készített a Bangbang-free verzió megerősítéséről és észleléséről, különféle eszközökkel, például ebpf-vel
Először a Fridával a hook, vannak összeomlás jelei, lehet, hogy a lépés túl korán érkezik, vagy a cím elérhetetlen, amikor a hook készen áll, ha a szkript hook kódját Frida kódra javítjuk
Általánosságban a befecskendezési idő kissé késleltetett, ami megoldotta az injekciós összeomlások problémáját
Hook Az aktiválás folyamata visszakapja az adatokat, és kérnie kell a szervert, hogy ellenőrizze, megkapta-e az aktiválási időbélyeget
Ezután a felhasználó időt kap az időbeli különbség kiszámításával.
Ez a virtuális kamera root jogosultságokat is kér, különben nincs verziós crossprocess-kommunikáció,
Összesen három folyamatot indított el a kamerához
Az egyik a kamera alkalmazás fő folyamata, amely a Java réteg és a C++ réteg közötti folyamatos kommunikáció
A második, hogy a fő folyamat a bináris futtatható vcmplay bemeneti paramétert futtatja a parancssoron a java rétegen keresztül, hogy elindítsa a második folyamatot, amely elsősorban a kamera vcmpaly fő folyamata és a rendszer kamera kamera szolgáltatásába befecskendező libvc.so folyamat közötti cross-process kommunikációért felelős, és a kommunikáció fő módja az ibinder.
A harmadik a kamera kameraszerver SO fájlja, amelyet beillesztenek a rendszerszolgáltatásba.
Ha az alkalmazás nem tudja root jogosultságokat szerezni, vagy hálózati probléma adódik, a folyamat nem indul el
Ennek a kamerának aktiválási kódra van szüksége az aktiváláshoz és használathoz, és a Java réteg elemzésével minden interfésze kikapcsolódik
Az aktiváláshoz a szervertől kell kérni, hogy megszerezze az ellenőrző információkat
Az összes információ titkosított
A VCMPLAY bináris futtatható fájl elemzésével megállapíthatjuk, hogy a kért adat RSA titkosítás, a kulcs a stackplz EBPF eszközén keresztül található, és a titkosítási kulcs 128 bites
Még egy szó
Ez az alkalmazás nagyon ravasz, hozzáadott egy so utótagot a vcmplay-hez, ami miatt az emberek azt hiszik, hogy ez egy SO fájl, és be kell tölteni a Java memóriájába, de valójában ez egy másik folyamat.
Csatlakoztattam a kamera szolgáltatás kameraszerverét, libvc.so azt találtam, hogy a Frida azonnal összeomlott, amint a csatlakoztatott kamera szolgáltatás összeomlott, nem tudom, észlelték-e, hosszú ideig elemeztem, és véletlenül azt találtam, hogy a VCMPLAY egyszer leállt, és sikerült összekapcsolni. Gyanítják, hogy a VCMPLAY folyamat észlelte a Cameraserve folyamatot
Idát használtam a VCMpay folyamat hibakereséséhez, és azt találtam, hogy még mindig van hibaellenes, beolvasta a tracepidet proc/self/status szakaszban, hogy megállapítsa, hibakeresés történt-e, és ami még ijesztőbb volt, hogy rájött, hogy az anti-debugging nem program összeomlása volt, hanem a fontos fájlokat törölte az Android rendszerből root jogosultságokkal, majd a telefon újraindult dupla törlési állapotba, a rendszert inicializálni kell a belépéshez, és minden a telefonban eltűnt. Kernelpatch-en írtam meg a kernel hook modult, a kpm-et, és megkerültem a hibakeresést
Több álmatlan éjszaka után itt már megoldották az általános logikát, és becslések szerint nem lesz könnyű megtörni.
Később folytatjuk......
|
Közzétéve: 2025-10-14 10:40:57
|
|
|
|
