RE FORUM
[REVERSE ENGINEERING] => General Discussion => Topic started by: Kockatá hlava on January 03, 2019, 01:27:00 PM
-
Při startu Win64 programu potřebuju namapovat do paměti datový soubor (který je součást distribuce aplikace a nikdy se nemění), přečíst z něho data a soubor zase zavřít (a tím uvolnit paměť).
Chtěl bych ty data z toho souboru ale přesunout přímo někam do PE exe, kde mám možnost je trochu líp ochránit, než když jsou v externím souboru. Nevím ale, jak potom vyřešit uvolnění paměti. PE specifikaci trochu znám, ale nevím o tom, že by se dala nějaká část načteného PE souboru dodatečně uvolnit. Neexistuje nějaká možnost?
-
podla mna mas 2 moznosti:
1) bud to budes mat priamo ako resource v exe (mozes to mat napr cryptovane) ale tam neviem ci vies uvolnit pamat kedze system si tak ci tak nacita cele exe do pamati a ked to napr budes decryptovat tak si zase vyhradi na to dalsie nove miesto... Mohol by si to dat aj ako externe dll, ale tam sa potom dostavame k bodu 2:
2) externy subor (cryptovany) kde si riesis vsetko vo vlastnej rezii (nacitanie, decrypt, release, uvolnis pamat)
ak sa nejedna o velke data (do 50MB) chod cestou 1) inac 2). Dnesne systemy to zvladnu. Velakrat ma samotna aplikacia: exe + externe dll aj cez 100mb a "bezi to" :-)
-
Jak jsem četl ten tvůj komentář, napadla mě ještě další možnost - dát ty data do DLL (kde bych je mohl "ochránit"), načíst je, kam potřebuju, a potom je uvolnit přes FreeLibrary.
-
Ved tak som myslel, otazka je ze o ake data sa konkretne jedna, ako sa budu vyuzivat dalej, podla toho sa bude odvijat aj riesenie :-)
-
Můžeš ty data hodit do nové sekce souboru a tu sekci po použití normálně odmapovat (API funkce NtUnmapViewOfSection), čímž by mělo dojít k uvolnění paměti. Další možností je připojit ty data za reálný konec (koukni na PE hlavičky a konkrétně na IMAGE_OPTIONAL_HEADER) souboru a pak si to z něj jen načíst. Tohle je technika, kterou dost často používají packery.
-
O téhle možnosti jsem nevěděl, pokud by to fungovalo, tak by to bylo super. Taky jsem našel linuxový munmap (https://linux.die.net/man/2/munmap), ten by mohl fungovat na Androidu.
Nechce se někomu napsat proof of concept? :)
-
Pro Windows ti to napsat můžu. Tam je to easy.
-
Pro Windows ti to napsat můžu. Tam je to easy.
To by mi pomohlo. Bylo by potřeba ověřit, že to fakt unmapne jenom tu jednu sekci a ne třeba ještě něco jinýho :)
-
pr0p4g4nd4: hmm, na overlay jsme si nikdo nevzpomněli :) popřemýšlím, jestli by to bylo použitelný.
-
overlay je ta najjednoduchsia moznost, len tam naprcas co chces (kludne aj kryptovane data, hociake). data nacistas TROMA apickami CreateFileA/W (dostanes handle) -> CreateFileMapping (dostanes handle) -> MapViewOfFile. dostanes to v alokovanej pamati - ked ti nebude vyhovovat adresa, tak si skratka naalokujes taku aku budes chciet (VirtualAlloc tusim ma aj parameter, ktory umoznuje alokovat na adresu, ktora ti vyhovuje.. samozrejme ak je volna) a data si tam skopirujes (bud rucne svojim kodom, alebo pomocou nejakej api).
-
Pro Windows ti to napsat můžu. Tam je to easy.
To by mi pomohlo. Bylo by potřeba ověřit, že to fakt unmapne jenom tu jednu sekci a ne třeba ještě něco jinýho :)
Hned teď ti to neudělám. Buď si ohni kód na základě mého článku https://web.archive.org/web/20150403162935/https://bflow.security-portal.cz/spousteni-binarky-z-pameti-bez-nutnosti-ulozeni-na-disk/ (https://web.archive.org/web/20150403162935/https://bflow.security-portal.cz/spousteni-binarky-z-pameti-bez-nutnosti-ulozeni-na-disk/) nebo si budeš muset pár dnů počkat, než si na to udělám čas. Volba je na tobě 8)
-
Pokud se ti to chce udelat, rad pockam :)
-
inac, skusal som jednu vec, ci je mozne uvolnit cast pamate procesu, ktora patri nejakej konkretnej sekcii PE. do PE sa da pridat pomocou dajme tomu lordpe nova sekcia - pridat akykolvek subor a urobit z neho sekciu PEcka. vyskusal som to (pridal som nahodny subor ako PE sekciu), a nasledne som sa pokusal uvolnit danu cast PE (pridanu sekciu zo suboru). prisiel som na to, ze klasicky pomocou VirtualFree to nejde. nechytali sa ani rozne pluginy do olly, ktore umoznuju uvolnit nejaku cast pamate (ktore to ale asi tiez robia cez VirtualFree(Ex)). cize, pravdepodobne su api windows urobene, tak aby neuvolnovali tu pamat, patriacu nejakej PE sekcii. asi jedina moznost bude uvolnovat PE sekcie pomocou driveru.
-
Zkus importovat ntdll.dll a zavolat NtUnmapViewOfSection.
-
Beru zpět. Nezkoušel jsem, ale vypadá to, že Nt/ZwUnmapViewOfSection odmapuje naráz celou paměť. To mě přivedlo na myšlenku, že si můžeš napsat vlastní PE loader (jako shellcode to mělo kolem 1k2 bajtů) a prostě si postupně namapovat, co potřebuješ ;)
-
inac, skusal som jednu vec, ci je mozne uvolnit cast pamate procesu, ktora patri nejakej konkretnej sekcii PE. do PE sa da pridat pomocou dajme tomu lordpe nova sekcia - pridat akykolvek subor a urobit z neho sekciu PEcka. vyskusal som to (pridal som nahodny subor ako PE sekciu), a nasledne som sa pokusal uvolnit danu cast PE (pridanu sekciu zo suboru). prisiel som na to, ze klasicky pomocou VirtualFree to nejde. nechytali sa ani rozne pluginy do olly, ktore umoznuju uvolnit nejaku cast pamate (ktore to ale asi tiez robia cez VirtualFree(Ex)). cize, pravdepodobne su api windows urobene, tak aby neuvolnovali tu pamat, patriacu nejakej PE sekcii. asi jedina moznost bude uvolnovat PE sekcie pomocou driveru.
API funkci/funkce VirtualFree(Ex) můžeš použít jen na paměť alokovanou pomocí VirtualAlloc(Ex) - viz dokumentace.
-
Beru zpět. Nezkoušel jsem, ale vypadá to, že Nt/ZwUnmapViewOfSection odmapuje naráz celou paměť. To mě přivedlo na myšlenku, že si můžeš napsat vlastní PE loader (jako shellcode to mělo kolem 1k2 bajtů) a prostě si postupně namapovat, co potřebuješ ;)
Z toho mám právě obavy, jestli ta Section je fakt totéž jako PE section. Musí se to vyzkoušet.
Přidávat tam PE loader (zatím) v plánu nemám :)
-
API funkci/funkce VirtualFree(Ex) můžeš použít jen na paměť alokovanou pomocí VirtualAlloc(Ex) - viz dokumentace.
islo mi o ine, skusal som nejake veci co mi napadli - okrem ineho som si nechal zobrazit informacie o novej
sekcii co som pridal do PE - len klasicke VirtualQuery, a tam je MEMORY_BASIC_INFORMATION struct a tam je
zaujimava polozka:
PVOID AllocationBase; // allocation base address
AllocationBase
Points to the base address of a range of pages allocated by the VirtualAlloc function. The page pointed to by
the BaseAddress member is contained within this allocation range.
ako keby tam VirtualAlloc bolo nejako zakomponovane (podla toho popisu), skusal som sa teda pohrat s api
VirtualFree - pozeral som sa na fungovanie tejto api, ale viacmenej sa s tym nedalo nic robit (z user space),
lebo hned to islo volat kernel/r0.
-
API funkci/funkce VirtualFree(Ex) můžeš použít jen na paměť alokovanou pomocí VirtualAlloc(Ex) - viz dokumentace.
islo mi o ine, skusal som nejake veci co mi napadli - okrem ineho som si nechal zobrazit informacie o novej
sekcii co som pridal do PE - len klasicke VirtualQuery, a tam je MEMORY_BASIC_INFORMATION struct a tam je
zaujimava polozka:
PVOID AllocationBase; // allocation base address
AllocationBase
Points to the base address of a range of pages allocated by the VirtualAlloc function. The page pointed to by
the BaseAddress member is contained within this allocation range.
ako keby tam VirtualAlloc bolo nejako zakomponovane (podla toho popisu), skusal som sa teda pohrat s api
VirtualFree - pozeral som sa na fungovanie tejto api, ale viacmenej sa s tym nedalo nic robit (z user space),
lebo hned to islo volat kernel/r0.
Trošku jsem se koukal, jaké funkce jsou volány z driveru během volání VirtualAllocEx a možná by stálo za to vyzkoušet volat funkci ZwFreeVirtualMemory (https://msdn.microsoft.com/en-us/library/windows/hardware/ff566460(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/hardware/ff566460(v=vs.85).aspx)). Tam by to mohlo být nadějné. Ještě jsem přemýšlel, jestli loader během inicializace binárky nenastavuje těm jednotlivým částem paměti nějaké speciální příznaky, které by pak mohly zabránit jejich uvolnění. Jinak: https://reverseengineering.stackexchange.com/questions/8238/ntapi-calls-made-by-virtualalloc/8240#8240 (https://reverseengineering.stackexchange.com/questions/8238/ntapi-calls-made-by-virtualalloc/8240#8240)
-
Trošku jsem se koukal, jaké funkce jsou volány z driveru během volání VirtualAllocEx a možná by stálo za to vyzkoušet volat funkci ZwFreeVirtualMemory (https://msdn.microsoft.com/en-us/library/windows/hardware/ff566460(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/hardware/ff566460(v=vs.85).aspx)). Tam by to mohlo být nadějné. Ještě jsem přemýšlel, jestli loader během inicializace binárky nenastavuje těm jednotlivým částem paměti nějaké speciální příznaky, které by pak mohly zabránit jejich uvolnění. Jinak: https://reverseengineering.stackexchange.com/questions/8238/ntapi-calls-made-by-virtualalloc/8240#8240 (https://reverseengineering.stackexchange.com/questions/8238/ntapi-calls-made-by-virtualalloc/8240#8240)
zistit co vsetko sa deje pri alokovani a uvolnovani pamati sa bude dat asi jedine, tak ze to nahodis do
windbg/syser, lebo predpokladam ze od MS sa ziadne veci okolo interneho fungovania funkcii (servicov) z SYSTEM
SERVICE DESCRIPTOR TABLE nedozieme.
co som pozeral ZwFreeVirtualMemory (ntkrnlpa.exe) v disassembleri, tak ta funkcia nevyzerala az tak zlozito
(ale nepocitam vnorene cally v ramci funkcie, ktore tam boli obsiahnute, tie som nepozeral).