Jeg prøvede at reverse engineer en android ndk (arm) ved hjælp af ida pro på en statisk analyse. Det ser imidlertid ud til, at der er mange ubrugelige spring til det samme sted og med tilfældige værdier indstillet til R1 for at sammenligne og hoppe igen. Ligesom følgende billede. Næsten hver funktion gør noget lignende - Initialisering først (ting som push-registre), så hopper det til kode et eller andet sted (som højre hjørne af billedet), indlæser tilfældige værdier til R1-register og sammenligner det med R0 og gør springene , men det springer altid tilbage til det øverste hjørne igen

Her er en anden sag, det ser ud til, at loc_FFBA og de følgende grene fungerer som en stor switch, men hvad der ikke giver mening er, at næsten hver gren til sidst hopper tilbage til loc_FFBA igen. Der kan være en strøm rød-> grøn-> blå-> rød, men det giver ikke engang mening ... Du kan se springet i blåt er endda ubrugeligt, for hvis det tager spring til blått (R0> 0x6fe5e521), det vil helt sikkert tage springet til det røde (R0> 0x661cf941) ...

Mit spørgsmål er, er dette gjort med vilje forfatteren til at forhindre reverse engineering? I bekræftende fald, hvordan opnås det? For mig lyder det som om forfatteren har brug for en masse if-else og goto-klausul i sin C ++ - kode, men det vil også bremse udviklingen, fordi han måske forvirrer sig selv ... Og det ser ikke ud til .so ndk er pakket, da jeg ved hjælp af en debugger generelt fandt ud af, hvad det rent faktisk gør er bare at afkode en ressourcefil til en apk og indlæse den dynamisk, men al dekryptering sker ved at kalde JNI-funktioner for at lave en AES-dekryptering for at indlæse APK , snarere end at gøre det i C ++, så de rodede spring synes heller ikke at være noget relateret til dekrypteringen ...

Måske er der en slags kompilator, der vil generere skibene, hvis dette virkelig er en forsætlig tilslørelse?