Această postare a fost editată ultima dată de Summer la 2025-10-14 10:59
O versiune a camerei virtuale care a fost spart anterior de autor a postat un videoclip pe Bilibili
Versiunea anterioară pe care am spart-o era și ea crăpată Legătură:Autentificarea cu hyperlink este vizibilă. Recent, un client mi-a cerut să sparg o altă versiune a camerei virtuale a aceluiași autor și pur și simplu să o studiez Verifică mai întâi cartușul, întărirea fără Bangbang, relativ simplă, doar o simplă detecție a Fridei, linkul de mai sus a făcut o analiză foarte detaliată a întăririi și detecției versiunii fără Bangbang, folosind diverse instrumente precum ebpf Hook cu frida mai întâi, există semne de crash, poate fi că pasul este injectat prea devreme sau adresa nu este accesibilă când hook-ul este pregătit, corectând codul hook al scriptului către frida
În general, timpul de injectare a fost puțin întârziat, ceea ce a rezolvat problema blocărilor de injecție Hook Procesul activării sale primește datele returnate de activare, iar el trebuie să solicite serverului să verifice că a primit timestamp-ul activării
Utilizatorului i se oferă apoi timp calculând diferența de timp. Această cameră virtuală solicită, de asemenea, permisiuni de root, altfel nu există comunicare între procese între versiuni, În total, această cameră are trei procese începute Unul este procesul principal al aplicației camera, care constă în comunicarea între procesele dintre stratul Java și cel C++ Al doilea este că procesul principal rulează parametrul binar executabil vcmplay de intrare pe linia de comandă prin stratul Java pentru a începe al doilea proces, care este responsabil în principal pentru comunicarea între procesul principal al camerei vcmpaly și procesul libvc.so injectat în serviciul camerei camerei al sistemului, iar principala modalitate de comunicare este ibinder. Al treilea este fișierul SO al camerei cameraserver injectat în serviciul de sistem. Dacă aplicația nu poate obține privilegii root sau există o problemă de rețea, procesul nu va începe
Această cameră are nevoie de un cod de activare pentru a fi activată și folosită, iar prin analiza stratului Java, toate interfețele sale sunt conectate Activarea necesită solicitarea serverului pentru a obține informațiile de verificare
Datele pe care le primești sunt toate criptate Analizând executabilul binar VCMPLAY, putem obține că datele solicitate sunt criptare RSA, cheia este localizată prin instrumentul EBPF al stackplz, iar cheia de criptare este de 128 de biți Încă un cuvânt Această aplicație este foarte ingenioasă, a adăugat un sufix so în vcmplay, ceea ce îi face pe oameni să creadă că este un fișier SO și că trebuie încărcat în memoria Java, dar de fapt este un alt proces. Am conectat serverul camerelor de serviciu de camere libvc.so am descoperit că Frida s-a blocat imediat ce serviciul Attach Camera s-a blocat, nu știu dacă a fost detectat, l-am analizat mult timp și am descoperit din greșeală că VCMPLAY a murit o dată și a reușit să se conecteze. Se suspectează că ar putea fi procesul VCMPLAY cel care a detectat procesul de servire a camerei Am folosit ida pentru a depana procesul VCMpay și am descoperit că încă avea anti-debugging, a scanat tracepid-ul în proc/self/status pentru a determina dacă era depanat, iar ceea ce a fost și mai înfricoșător a fost că a descoperit că anti-depanarea nu era un crash de program, ci chiar a șters fișiere importante din sistemul Android prin permisiuni root, iar telefonul a repornit în stare de dublă ștergere, iar sistemul trebuia inițializat pentru a intra în sistem, iar totul din telefon dispăruse. Am scris modulul kernel hook kpm prin kernelpatch și am ocolit depanarea După câteva nopți nedormite aici, logica generală a fost descoperită și se estimează că nu va fi ușor de descifrat. Va continua mai târziu......
|