Dit bericht is voor het laatst bewerkt door Summer op 14-10-2025 om 10:59
Een versie van de virtuele camera die eerder door de auteur is gehackt, heeft een video op Bilibili geplaatst
De vorige versie die ik kraakte was ook gebarsten Verbinden:De hyperlink-login is zichtbaar. Onlangs vroeg een klant mij om een andere versie van de virtuele camera van dezelfde auteur te kraken en deze gewoon te bestuderen Controleer eerst de granaat, Bangbang gratis versterking, relatief eenvoudig, gewoon een eenvoudige detectie van Frida, de bovenstaande link heeft een zeer gedetailleerde analyse gemaakt van de versterking en detectie van de gratis versie van Bangbang, met behulp van verschillende tools zoals ebpf Eerst haak met Frida, er zijn tekenen van crash, het kan zijn dat de voetstap te vroeg wordt geïnjecteerd, of het adres onbereikbaar is wanneer de haak klaar is, door de hookcode van het script naar frida te corrigeren
Over het algemeen was de injectietijd iets vertraagd, wat het probleem van injectiecrashes oploste hook Het activatieproces krijgt de data die door de activatie wordt teruggegeven, en hij moet de server vragen te verifiëren dat hij de activatietijdstempel heeft gekregen
De gebruiker krijgt vervolgens tijd door het tijdsverschil te berekenen. Deze virtuele camera vraagt ook om root-rechten, anders is er geen versie-cross-process communicatie, In totaal zijn er drie processen bij deze camera gestart Eén daarvan is het hoofdproces van de camera-app, namelijk de cross-process communicatie tussen de Java-laag en de C++-laag De tweede is dat het hoofdproces de binaire uitvoerbare vcmplay-invoerparameter op de commandoregel via de java-laag uitvoert om het tweede proces te starten, dat voornamelijk verantwoordelijk is voor de cross-process communicatie tussen het hoofdproces van de camera vcmpaly en het libvc.so proces dat injecteert in de cameracamera-service van het systeem, en de belangrijkste communicatiemethode is ibinder. De derde is het SO-bestand van de camera-cameraserver die in de systeemservice is geïnjecteerd. Als de applicatie geen rootrechten kan verkrijgen of er een netwerkprobleem is, zal het proces niet starten
Deze camera heeft een activatiecode nodig om te activeren en te gebruiken, en door de Java-laag te analyseren worden al zijn interfaces gekoppeld Activatie vereist dat de server wordt gevraagd om de verificatie-informatie te verkrijgen
De data die je krijgt is allemaal versleuteld Door het binaire uitvoerbare bestand van VCMPLAY te analyseren, kunnen we achterhalen dat de gevraagde data RSA-encryptie is, en dat de sleutel wordt gevonden via het EBPF-instrument van stackplz, en dat de encryptiesleutel 128 bits is Nog één woord Deze applicatie is erg sluw, hij voegde een so-achtervoegsel toe aan vcmplay, waardoor mensen denken dat het een SO-bestand is en dat het in het geheugen van Java geladen moet worden, maar het is eigenlijk een ander proces. Ik heb de cameraserver van de cameraservice gekoppeld libvc.so ontdekte dat Frida crashte zodra de Attach Camera-service crashte, ik weet niet of het werd gedetecteerd, ik heb het lang geanalyseerd en ontdekte per ongeluk dat VCMPLAY één keer was uitgevallen, en het kon hooken. Er wordt vermoed dat het het VCMPLAY-proces is dat het cameraservice-proces heeft gedetecteerd Ik gebruikte ida om het VCMpay-proces te debuggen, en ontdekte dat hij nog steeds anti-debugging had, scande de tracepid in proc/self/status om te bepalen of het gedebuggd was, en wat nog angstaanjagender was, was dat hij ontdekte dat de anti-debugging geen programmacrash was, hij verwijderde daadwerkelijk belangrijke bestanden in het Android-systeem via root-permissions, waarna de telefoon opnieuw opstartte in een dubbele clearing-toestand, het systeem geïnitiseerd moest worden om het systeem binnen te komen, en alles in de telefoon was weg. Ik schreef de kernel hook module kpm via kernelpatch en omzeilde debugging Na enkele slapeloze nachten hier is de algemene logica doorgrond, en men schat dat het niet makkelijk zal zijn om het te kraken. Wordt later vervolgd......
|