Pitanje:
Kako mogu analizirati program koji koristi JIT kompajlirani kod?
ŹV -
2013-03-23 23:38:10 UTC
view on stackexchange narkive permalink

Mnogo koda s kojim se danas susrećem ima značajnu količinu koda generiranog u vrijeme izvođenja, što analizu čini izuzetno mučnom i dugotrajnom.

Mogu li na bilo koji način stvoriti simbolička imena za razne funkcije koje je uveo JIT kompajler koji se neprestano pojavljuje ili za razne artefakte (poput informacija o tipu) uvedene u izvršnu datoteku putem JIT kompajlera u GDB ili WinDBG?

Mislim da će vam biti lakše odgovoriti ako kažete s kojim kompajlerom / VM-om imate posla.
Dva odgovori:
#1
+8
Peter Andersson
2013-03-24 01:47:00 UTC
view on stackexchange narkive permalink

Za .net postoje SOS.dll i WinDbg. Verzije, za svaku verziju instaliranih .NET okvira, možete pronaći u podmapama u %SYSTEMROOT%\Microsoft.NET\Framework\ . Možete ga učitati u WinDbg tako što ćete upisati .load i puni put do SOS dll-a.

Upotrijebite ! name2ee za dobivanje tablice metoda klase, ! dumpmt za izbacivanje tablice metoda, ! dumpmd u izbacite opisnik metode za metodu koju želite pogledati, CodeAddr je adresa JITed koda i na kraju ! U za rastavljanje adrese koda.

Evo veze na blog koji opisuje postupak.

Zapravo nisam siguran što biste dobili napadom JIT-kompiliranog koda, jer je gotovo uvijek slučaj da je izvorni VM jednostavniji i jako zabilježeni. Gotovo je uvijek lakše napasti srednji jezik. Jedinog razloga kojeg se mogu sjetiti je ako želite koristiti optimizaciju JIT-a za uklanjanje zamagljenosti. Čak je i tada vjerojatno lakše primijeniti optimizacijske propusnice na srednji jezik. Pretpostavljam da postoji i slučaj kada želite masirati JIT kôd tako da se može ponovno koristiti u nekoj vrsti exploita.

Jesam li pogrešno razumio pitanje?

#2
+1
Pavel Sapehin
2019-10-12 08:15:07 UTC
view on stackexchange narkive permalink

Da, odgovor ovisi o tome što točno pokušavate postići.

Što se tiče analize same .NET aplikacije, možete dobiti cjeloviti izvorni kod pomoću, npr. DotPeek napisao JetBrains. Možete ga čak izvesti u potpuno funkcionalni Visual Studio Project, izgraditi i otkloniti pogreške. Međutim, neke aplikacije mogu biti zamućene.

Drugi je scenarij kada je .NET aplikacija dio druge aplikacije napisane na drugom jeziku (npr. C ++). U ovom se slučaju najvjerojatnije .NET kôd kompajlira u DLL koji se također može rastaviti pomoću aplikacija poput DotPeeka.

Vjerojatno mogu postojati mnogo složeniji scenariji poput prilagođenog JIT-kompajlera, ugrađenog u zlonamjerni softver. U takvim slučajevima najrazumniji način može biti pisanje prilagođenog dodatka (npr. Pomoću IDAPythona za IDA Pro). Ovaj dodatak trebao bi biti svjestan strukture podataka ili ponašanja i može vam pomoći u svakom koraku obrnutog inženjerskog postupka. Ali pisanje prilagođenog dodatka može zahtijevati puno znanja osnovnog jezika i samo po sebi može predstavljati izazov.



Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 3.0 licenci pod kojom se distribuira.
Loading...