RE FORUM
[REVERSE ENGINEERING] => General Discussion => Topic started by: johnsmithx on December 01, 2009, 03:30:32 AM
-
Ahoj vsichni, hledam nejaky program na statickou analyzu PE souboru. Potrebuji, aby byl ve forme DLL (anebo byly k dispozici jeho zdrojove kody), protoze ho potrebuji volat ze sveho programu (http://forensic-experts.eu/tools/fvi/ (http://forensic-experts.eu/tools/fvi/)).
V tuto chvili jsem treba pouzil PEiDLL (http://www.peid.info/BobSoft/Other/PEiDLL.html), jenze to je prakticky jen wrapper pro PEiD, takze je velmi pomaly.
Cili me otazky jsou dve:
1) vite nekdo o nejakem solidnim statickem PE analyzatoru, u ktereho je bud k dispozici DLL nebo zdrojovy kod?
2) znate jeste nejake jine zpusoby, jak automatizovane ziskavat nejake zajimave informace z PE souboru?
"Zajimava informace" je neco, co mi pomuze vytipovat soubory, ktere jsou nejakym zpusobem atypicke a mohou slouzit k necemu nestandardnimu. Samozrejme vzdy to zalezi na konkretnim zadani od vysetrovatele, ale obecne receno v computer forensics zajistujeme a analyzujeme digitalni dukazy a zkoumame, zda a pripadne jak byly zajistene technicke prostredky pouzity v souvislosti s vysetrovanym pripadem, pricemz jedna z cinnosti, ktere je potreba udelat temer vzdy, je ziskani a identifikace veskerych dat. V dnesni dobe musime pracovat s miliony i desitky milionu souboru, cili tam samozrejme neni v lidskych silach zkoumat kazdy soubor rucne. K tomuto ucelu mame mnoho softwaru, ktery ruznym zpusobem soubory zkouma a "skatulkuje", vyuzivaji se ruzne fingerprint a hash databaze atd. atp., jenze co se tyce spustitelnych souboru, tak tam mi prijdou ty analyticke vystupy trochu nedostatecne. Nic moc se z toho nedozvim.
Napsal jsem si proto program, ktery vytahuje informace z VersionInfo sekce, dalsi identifikacni informace ziskava diky vyuziti libmagic knihovny (pouziva ji napr. unixovy prikaz "file" pro identifikaci typu souboru) no a ted diky PEiDLL tam mam i dalsi informace o typu kompileru/packeru/crypteru. Ovsem ten posledne jmenovany to extremne zpomaluje, protoze on prakticky pro kazdy soubor "neviditelne" spousti PEiD.exe. Bohuzel PEiD nema verejne dostupne zdrojove kody :(
Cili hledam jednak nejakou alternativu a taky i pripadne nejake dalsi vylepseni. Co jsem se dival po jinych PE identifikatorech, tak jsem nenasel zadny, ktery by nabizel DLL, ani zadny se zdrojovymi kody.
Zajimava informace treba pro mne je, jestli je dany soubor GUI nebo CUI. To ted vim diky libmagic (puvodne jsem si naprogramoval analyzu PE headeru sam, ale pak jsem zjistil, ze libmagic je mnohem dal). Dalsi zajimava informace treba je, jaky kompilator nebo packer/crypter byl u daneho souboru pouzit. Todle mam ted diky tomu PEiDLL. Ted mne napadlo, ze bych taky mohl treba kontrolovat PE checksumy jako takovou pseudoindikaci, ze byl soubor nejak umele pozmenen (i kdyz PE checksumy nesedi vzdycky ani u genuine souboru). No nevim co by mohlo byt jeste dalsiho zajimave takhle statisticky zjistovat. Napada nekoho neco?
-
Zajimavy napad, neco k tomu rici muzu:
1) Ja jsem pouzival zmineny PEiD a LordPe.
Trochu jsem zagooglil, ale zda se mi, ze zdrojovy kody volne nejsou ani u jednoho. Prestoze to nebude jedoduche, mozna by nebylo od veci "ziskat" vsechny tyhle veci z PEiDu, jelikoz uz s nim zkusenosti mas. Tusim ze PEiD je psany v C++, no Olly by si s tim mel poradit. Pokud je to alespon trochu slusne napsane, tak bys mohl byt schopny lokalizovat presne tu fci/fce, ktere pouzivas. Samozrejme, co se legalnosti tyce, pouzil bys PEiD pouze jako "inspiraci" ;) Jina rozumna cesta me nenapada, pokud nenajdes nejakej jinej soft nebo si to nechces napsat sam, coz by taky nemuselo bejt tak strasne. Spousta packeru/unpackeru ma volne zdrojove kody (napr. UPX, ...), takze identifikace by nemusela bejt takovy problem, ale byla by to drbacka. Nejdrive bys potreboval seznam packeru, ktere implementujes, atd.
2) Automatizovane zpusoby neznam, nicmene par veci me napada.
Predne bys pri analyze mohl filtrovat (po checksumu) vsechny soubory operacniho systemu, coz by ti mohlo "par" milionu souboru vyloucit. K tomu bys potreboval pravdepodobne seznamy jejich souboru (pro kazdy OS), coz se da take jednoduchym programkem s pouzitim databaze zvladnout. Co se tyce analyzy .exe souboru, mozna by nebylo od veci se mrknout do Import Table po nejakych specifickych APInach. Krome toho s .exe souborem moc neporidis, asi proto se ti zda ten vystup nedostatecny. Spis bych provadel analyzu exacu podle toho, co hledas a kdo je tvuj "protivnik". Treba pokud hledas jednoduse zasifrovana data pomoci APIn windowsu, jiste najdes nejaky watermark (nehlede, ze na ne pak muzes pouzi COFEE :) ). Pokud hledas data sifrovana TrueCryptem, tak to by se taky mohlo dat. (Otazkou spis je, jestli to pak desifrujes). Spustitelne soubory mohou obsahovat samozrejme take zajimave informace, ale pokud budou obsahovat polymorfismus nebo nedej boze metamorfismus, tak z toho stejne moc nezjistis. (i kdyz poznat polymorfismus ci metamorfismus by mozna jit mohlo, a to by rozhodne ukazalo na VELMI podezrely soubor - pokud pomineme par "znamych" vyjimek jako Total Commander apod. :D )
-
fiiizl fuuj ,no treba takove wisty a vyse maj soubory digtalne podepsane aje nato i naka API :)
-
nooo, engine by som si nakodil na tvojom mieste sam a pouzil volne dostupne DB (napr s PEID) ktore su celkom rozsiahle a uzivatelia ich stale doplnaju a hlavne su "otvorene". Vyhoda tohoto riesenia je, ze casom si budes moct do svojeho enginu pridat vlastne eventy ktore mozu v urcitej zavislosti spustat dalsie akcie. Priklad: najde sa UPX file -> rozbal, zanalyzuj povodne exe, ak sa najde nieco "zaujimave", potom dalsi krok atd ..., teda na zaklade urcitych vyskytov mozes spustat dodatocne analyzy ... Cize uloha pre teba ostava akurat nakodit dobre optimalizovany rychly engine ...
ked pouzijes app 3 stran tak si viazany na ich pevnu funkcnost co sa ti moze neskor vypomstit ...
-
Ja bych postupoval presne, jak radil DARKER. PEiD vlastne pracuje na systemu signatur, takze vyuzit jeho signaturni databazi a hledat signatury ve spustitelnych souborech pomoci sveho vlastniho algoritmu.
Dale by se hodilo delat si treba seznamy API funkci a hledat v nich podezdrele, ale pokud bude program packovan nejaky toolem, tak ho s nejvetsi pravdepodobnosti stejne neunpacknes automaticky, takze by se to hodilo jen na ciste soubory.
-
Skus tu ale je to v delphi http://www.felix-colibri.com/papers/colibri_utilities/exe_dll_pe_explorer/exe_dll_pe_explorer.html
-
1) Ja jsem pouzival zmineny PEiD a LordPe.
Trochu jsem zagooglil, ale zda se mi, ze zdrojovy kody volne nejsou ani u jednoho. Prestoze to nebude jedoduche, mozna by nebylo od veci "ziskat" vsechny tyhle veci z PEiDu, jelikoz uz s nim zkusenosti mas. Tusim ze PEiD je psany v C++, no Olly by si s tim mel poradit. Pokud je to
Myslis jakoze to disassemblerovat? No to je mozny. I kdyz teda co se tyce te zakladni funkce - identifikace - tak ono to stejne nedela o moc vic nez porovnava dany soubor vuci ruznym signaturam. Ty signatury jsou jednak interne zakompilovane, ale taky jsou ve forme externiho souboru userdb.txt, ktery je prubezne aktualizovan na webu, takze ten by asi byl lepsi zdroj informaci. A tento soubor je verejne dostupny, takze kdybych si udelal vlastni funkci, ktera ty signatury umi pouzivat, tak cely PEiD nepotrebuju. Jen teda budu muset nekde najit syntaxi toho souboru. Vypada to nejak takhle:
[UPX 0.50 - 0.70]
signature = 60 E8 00 00 00 00 58 83 E8 3D
ep_only = true
[UPX 0.72]
signature = 60 E8 00 00 00 00 83 CD FF 31 DB 5E
ep_only = true
[UPX 2.00-3.0X -> Markus Oberhumer & Laszlo Molnar & John Reiser]
signature = 5E 89 F7 B9 ?? ?? ?? ?? 8A 07 47 2C E8 3C 01 77 F7 80 3F ?? 75 F2 8B 07 8A 5F 04 66 C1 E8 08 C1 C0 10 86 C4 29 F8 80 EB E8 01 F0 89 07 83 C7 05 88 D8 E2 D9 8D ?? ?? ?? ?? ?? 8B 07 09 C0 74 3C 8B 5F 04 8D ?? ?? ?? ?? ?? ?? 01 F3 50 83 C7 08 FF ?? ?? ?? ?? ?? 95 8A 07 47 08 C0 74 DC 89 F9 57 48 F2 AE 55 FF ?? ?? ?? ?? ?? 09 C0 74 07 89 03 83 C3 04 EB E1 FF ?? ?? ?? ?? ?? 8B AE ?? ?? ?? ?? 8D BE 00 F0 FF FF BB 00 10 00 00 50 54 6A 04 53 57 FF D5 8D 87 ?? ?? ?? ?? 80 20 7F 80 60 28 7F 58 50 54 50 53 57 FF D5 58 61 8D 44 24 80 6A 00 39 C4 75 FA 83 EC 80 E9
ep_only = false
[UPX 2.90 [LZMA] (Delphi stub) -> Markus Oberhumer, Laszlo Molnar & John Reiser]
signature = 60 BE ?? ?? ?? ?? 8D BE ?? ?? ?? ?? C7 87 ?? ?? ?? ?? ?? ?? ?? ?? 57 83 CD FF 89 E5 8D 9C 24 ?? ?? ?? ?? 31 C0 50 39 DC 75 FB 46 46 53 68 ?? ?? ?? ?? 57 83 C3 04 53 68 ?? ?? ?? ?? 56 83 C3 04
ep_only = true
No na prvni pohled mi to prijde, ze ve vetsine pripadu staci najit EP a porovnat x bajtu.. Zkusim o tom neco zjistit, dik za tip!
2) Automatizovane zpusoby neznam, nicmene par veci me napada.
Predne bys pri analyze mohl filtrovat (po checksumu) vsechny soubory operacniho systemu, coz by ti mohlo "par" milionu souboru vyloucit. K tomu bys potreboval pravdepodobne seznamy jejich souboru (pro kazdy OS), coz se da take jednoduchym programkem s pouzitim databaze
No to jsou ty fingerprint a hash databaze, ktere jsem zminoval. To samozrejme pouzivame. Nejvetsi databaze kontrolnich souctu je NSRL, spravuje ji americky NIST, tam je neco pres 50 milionu souboru, z toho kolem 16 milionu unikatnich checksumu. To jsou "known good" soubory. Pak mame treba HashKeeper od NDIC US DoJ a nekolik dalsich databazi, to je vetsinou dostupne jen pro LE a obsahuji spise ty "known bad" soubory. No ale tim to konci, muzu pouzit jen duveryhodne zdroje, coz jsou vicemene jen urcite statni instituce. Mohl bych si udelat a pouzit i vlastni seznamy checksumu, jenze abych mohl neco takhle zkatalogizovat, tak bych to musel nejdrive koupit a mit to pak permanentne ulozene v "supliku", aby mohl kdykoliv prokazat zdroj. Problem u vsech techto databazi checksumu je to, ze v evropskem prostredi se to moc nechyta, odfiltruji diky tomu tak 20%.
Krome hashu jsou jeste ruzne fingerprint databaze, coz je na stejnem principu jako libmagic nebo tady ten PEiD, jen jsou zamereny velmi specificky na urcite "bad" programy.
No a tim veskera automaticka identifikace PE souboru konci. Pro vsechny ostatni formaty mi ruzne softwary (jako zaklad se vetsinou pouziva EnCase a FTK) dokazi vytahnout kdejakou informaci, metadata, alternativni streamy, data carving, desifrace, analyza redundantnich dat (v mp3, jpg atd.) za ucelem detekce skrytych informaci (steganografie) atd. atp., mame dokonce i nastroje na automaticke rozpoznavaji pornografickych obrazku, ale kdyz jde o PE soubory, tak to toho rekne velmi velmi malo, treba jen: "executable", coz navic ani neni vzdy pravda (ne kazdy PE je executable). Od softwaru za 100 tisic bych skutecne cekal, ze dokaze aspon tolik, co obycejny unix prikaz "file" umi uz desitky let. :-\
Cili kdyz to shrnu, tak z celkoveho mnozstvi souboru mi nakonec zbude rekneme 10-30%, ktere jsou PE a temer nic o nich nevim. A to jsou stale stovky tisic souboru.
zvladnout. Co se tyce analyzy .exe souboru, mozna by nebylo od veci se mrknout do Import Table po nejakych specifickych APInach. Krome
Todle je dobry napad, nad tim se zkusim zamyslet, diky!
toho s .exe souborem moc neporidis, asi proto se ti zda ten vystup nedostatecny. Spis bych provadel analyzu exacu podle toho, co hledas a
To je strasne ruzne. Nekdy se vi dopredu, co se stalo a jak v tom dane technicke prostredky figuruji, a hledaji se dukazy pro podporu techto podezreni. Muze jit o typickou pocitacovou kriminalitu, nelegalni software, bezpecnostni incidenty, servery, internet atd. Ale casto je jednoduse spachan nejaky (jakykoliv) trestny cin a vysetrovatel proste zabavi pocitace. Dneska ma kazdy pocitac a vzdy je moznost, ze se na takovem pocitaci bude nachazet nejaka informace, souvislost, digitalni dukaz, ktery s danym cinem souvisi. (Vtipne je, jak se postupuje v pripade, kdy se zjisti indicie o jinych nezakonnych aktivitach s aktualne vysetrovanym cinem nesouvisejicim. V americe je kvuli tomu v aktualni dobe hodne hluku, podle posledni precedensu oni proste dostanou warrant na zajisteni konkretnich stop a nic jineho je nesmi zajimat a dokonce ani nesmi zkouset hledat. U nas je to divocejsi, bereme vsechno a jsou to pak pritezujici okolnosti pokud ne rovnou dalsi pripad, nejaka ochrana soukromi v tomto smyslu k nam jeste nedorazila.)
Typicke zadani pak je zajistit veskere informace souvisejici s vysetrovanym pripadem. Cili dopredu nevim, co hledam. Na to mame urcite postupy, checklisty, ktere vychazi z best practices pouzivanych v computer forensics a jedna z prvnich fazi je prave vytezeni veskerych dat z nosicu a jejich nasledna identifikace. Zkomprimovane a zaheslovane soubory se rozbaluji, zjistuji se hesla do ruznych programu, veskera data se fulltextove indexuji (vznikne index s desitky milionu klicovych slov, ktery umozni prohledavat terabajty dat behem sekundy, takovy soukromy google), proste v teto pocatecni fazi jde o to, aby se znalcovy vedomosti o systemu co nejvice priblizily znalostem puvodniho uzivatele/majitele.
Takova "defaultni" otazka take casto byva zjistit nainstalovany software. To nezjistim ze seznamu adresaru v "Program Files" ani z registru. To zjistim pouze skutecnou identifikaci souboru. V tom treba trochu pomahaji prave informace z VersionInfo sekce (ProductName).
kdo je tvuj "protivnik". Treba pokud hledas jednoduse zasifrovana data pomoci APIn windowsu, jiste najdes nejaky watermark (nehlede, ze na ne pak muzes pouzi COFEE :) ). Pokud
COFEE je pro pouziti v terenu jeste nez se pocitac vypne. Do pocitace se strci flashka, neco se z ni spusti a udela to ruzne snapshoty. Muze to sice byt nekdy uzitecne, muze to vytahnout nejaka hesla, ale takove postupy se moc nepouzivaji, protoze se tim narusuje integrita a autenticita tech nosicu. Ty disky nejsou v te chvili chranene proti zapisu. Uz jen to, ze se tam strci USB flashka zpusobi mnoho nevratnych zmen. Todle nikdo nedela. Ja vysetrovatelum vzdycky radim nesahat vubec na nic, vytahnout snury natvrdo z elektrickych zasuvek a vsechno sbalit. U nas se pres hardwarove writeblockery udelaji binarni image ze vsech nosicu (vcetne HPA/DCO oblasti samozrejme) a disky putuji do zapecetenych pytliku.
hledas data sifrovana TrueCryptem, tak to by se taky mohlo dat. (Otazkou spis je, jestli to pak desifrujes). Spustitelne soubory mohou obsahovat samozrejme take zajimave informace, ale pokud budou obsahovat polymorfismus nebo nedej boze metamorfismus, tak z toho stejne moc nezjistis. (i kdyz poznat polymorfismus ci metamorfismus by mozna jit mohlo, a to by rozhodne ukazalo na VELMI podezrely soubor - pokud pomineme par "znamych" vyjimek jako Total Commander apod. :D )
Todle je ovsem dalsi velmi dobra myslenka! Ted jeste zjistit, jak to zjistim..
-
fiiizl fuuj ,no treba takove wisty a vyse maj soubory digtalne podepsane aje nato i naka API :)
Dalsi dobry napad, diky! Tam jsou dve veci - jednak zjistovat existenci certifikatu a pak je taky overovat (protoze kdyz je nekde certifikat od "Microsoft Corp." jeste to neznamena, ze to je skutecne od Microsoftu). Uvidim, jak dlouho bude trvat to overeni..
-
nooo, engine by som si nakodil na tvojom mieste sam a pouzil volne dostupne DB (napr s PEID) ktore su celkom rozsiahle a uzivatelia ich stale doplnaju a hlavne su "otvorene". Vyhoda tohoto riesenia je, ze casom si budes moct do svojeho enginu pridat vlastne eventy ktore mozu v urcitej zavislosti spustat dalsie akcie. Priklad: najde sa UPX file -> rozbal, zanalyzuj povodne exe, ak sa najde nieco "zaujimave", potom dalsi krok atd ..., teda na zaklade urcitych vyskytov mozes spustat dodatocne analyzy ... Cize uloha pre teba ostava akurat nakodit dobre optimalizovany rychly engine ...
ked pouzijes app 3 stran tak si viazany na ich pevnu funkcnost co sa ti moze neskor vypomstit ...
Pravda, pravda. Rekurzivni analyza. Koneckoncu muzu to udelat vicefazove. V prvni fazi muzu nejdrive pouze identifikovat a nerozbalovat, abych vubec vsechny ty soubory nekdy dojel do konce, a v druhe fazi pak muzu delat dodatecne analyzy pro vybrane "zajimave" soubory, ktere z te prvotni analyzy vypadnou jako flagged. Diky.
-
Tak dekuji moc vsem za rady i za linky, dali jste mi hodne uzitecnych podnetu.
Videl bych to na nasledujici 2-fazovy postup:
1. faze (fast)
done:
a) VersionInfo
b) libmagic
c) identifikace kompileru/packeru/crypteru pomoci PEiDLL (to be replaced)
todo:
c) identifikace kompileru/packeru/crypteru pomoci vlastni interpretace PEiDovskeho userdb.txt
d) kontrola PE checksumu
e) detekce "zajimavych" API z import table
f) detekce digitalniho podpisu
2. faze (slower)
todo:
a) pokus o rozbaleni packovanych (i cryptovanych?) souboru, v pripade uspechu skok na 1. fazi
b) verifikace certifikatu digitalniho podpisu
c) detekce poly/meta-morfniho kodu
No, s timhle uz budou z PE souboru znatelne lepsi vystupy. Ze vsech tech bodu je jen 2c (detekce poly/meta-morfismu), ktery nemam teda vubec poneti, jak udelat.
Kazdopadne ted budu mit na nekolik mesicu o zabavu postarano :D
P.S.: kdyby se cirou nahodou nekdo moc hodne nudil a chtel mi pomoci s implementaci nekterych bodu (i na komercni bazi), klidne dejte vedet ;)
-
Detekce tech poly a metamorfismu muzu shrnout asi takto. Pouziti v kriminalite co se tyce zabaveneho softu me napada jenom to, ze se majitel snazi nektere "usvedcujici" programy zamaskovat pred beznou analyzou. Problemem je (co jsem malo nasel na wikipedii), ze nektere programovaci jazyky mohou standartne pouzivat polymorfismus, takze tam muze bejt nejake "smeti" krom hledanych souboru. Narozdil od toho metamorfismus by zadny programovaci jazyk byt schopen pouzivat nemel (proste proto, ze je to tisickrat tezsi nez poly).
Nevim, jake mas znalosti ohledne teto problematiky, ale pokud hledas pomoc, tak bych zkusil antivirove odborniky. Ony totiz obe tyhle techniky programovani s viry uzce souvisi. Kdysi jsem si o tomto tematu precet par veci na strankach
http://vx.netlux.org/ (http://vx.netlux.org/)
a tobe je take doporucuji. ;) Co se tyce samotne detekce, napadaji me dve cesty.
Prvni z nich je nasledujici. Polymorfismus funguje na nasledujicim principu. Mas pevne stanoveny decryptovaci a cryptovaci fci, ktera "rozbali" exac. Tyhle routiny jsou casto hned na EP, ale mohou byt i jinde. Faktem je, ze tohle neni zrovna jednoduche programovani, a pokud protivnik neni expertem v programovani, predevsim v assembleru, tak jistotne pouziva jiz existujici "engine". Na uvedenych strankach najdes pomerne rozsahlou databazi techto enginu, takze se nabizi udelat si jejich databazi a pak je jako retezce v souborech hledat. Slabinou polymorfismu je prave to, ze tenhle decryptor a cryptor se sami nijak nemeni, takze i dnesni antiviry je proste pouzivaji jako watermarky. Obdobne u metamorfismu, vytvorit databazi techto enginu a hledat je v souborech (bohuzel znamkou metamorfismu je "neustala" mutace programu, takze tam ta databaze nemusi a pravdepodobne ani nikdy neodhali vse). Vyhodou je, ze nemusis program spoustet.
Druhou moznosti, co me napada, je konstrolovat pristup do .code casti pameti. Z PE ji lehce urcis, a pak nastavit breakpointy na zmenu teto casti pameti (mozna hardwarove breakpointy by se hodily nejvice. btw: vi nekdo, v cem se vubec lisi od tech "normalnich"?). To by ti melo odfiltrovat jak poly tak meta. Nevyhodou tohoto pristupu je, ze program musis spoustet, a take se program vubec nemusi dostat k tomu cryptovani a decryptovani (pokud to nebude delat hned u EP, ale az po nejake if podmince).
Vic moznosti me zatim nenapada. Ale jak jsem rikal, uz nejakou dobu jsem mimo tohle tema, takze by bylo vhodne ziskat aktualni info. :)
-
Problemem je (co jsem malo nasel na wikipedii), ze nektere programovaci jazyky mohou standartne pouzivat polymorfismus, takze tam muze bejt nejake "smeti" krom hledanych souboru. Narozdil od toho metamorfismus by zadny programovaci jazyk byt schopen pouzivat nemel (proste proto, ze je to tisickrat tezsi nez poly).
To by mě zajímalo. Jakože HLL compiler může generovat polymorfní kód? Proč by to dělal?
Jenom doufám, že si to nepleteš s polymorfizmem v OOP, což je úplně něco jinýho :D
http://cs.wikipedia.org/wiki/Polymorfismus_%28programov%C3%A1n%C3%AD%29
-
Druhou moznosti, co me napada, je konstrolovat pristup do .code casti pameti. Z PE ji lehce urcis, a pak nastavit breakpointy na zmenu teto casti pameti (mozna hardwarove breakpointy by se hodily nejvice. btw: vi nekdo, v cem se vubec lisi od tech "normalnich"?).
Rozdilu je nekolik: (zkus pouzit misto Olly SoftIce a uvidis co zmuze "kernel debugger" oproti olly)
Napr - SW BP das kolik chces - HW BP dle architektury myslim max 4 standardne soucasne
SW BP (BPX) je nastaveni "stop" na kod programu, kdezto HW BP je nastaven primo na pamet (RAM a dokonce i ROM - cteni, zapis, zmena)
SW BP je vlastne prepsani instrukce na int3 a program prose zastavi, naopak HW BP dava instrukci primo procesoru a v tom tkvi jeho sila - proste zastaveni chodu v zavislosti na vecech, ktere v kodu "nevidis".
Tak nejak asi zhruba - jak rikam SiCE byl sice narocny na instalaci (nemel gui), ale fungoval spolehlive a byl "nekompromisni" ;-))
-
Jenom doufám, že si to nepleteš s polymorfizmem v OOP, což je úplně něco jinýho :D
Jop, tak to si asi pletu. ;D Jsem se dival, jestli na wikipedii bude o tech morfismech nejakej dobrej clanek, a narazil jsem presne na ten odkaz :D. Tak to se omlouvam, v tom pripade bude ten postup o to ucinnejsi.
2 llAmElliK:
diky, to jsem si nebyl moc jistej.
V tom pripade asi nepripada v uvahu davat na celou code sekci hw breakpointy s ohledem na jejich omezeny pocet. Pokud se to neda udelat nejak jinak (otazka k zamysleni do plena "Jak monitorovat zapis do code sekce?"), tak druhy zpusob odpada cely.
btw. Jinak nevite, bude SoftIce fungovat pod wine na linuxu? Nebo mu ta emulace zabrani v pristupu k linuxovskemu jadru? Zatim jsem se setkal na linuxu jen s gdb, ale jestli je to kernel debugger nevim.
-
Jenom doufám, že si to nepleteš s polymorfizmem v OOP, což je úplně něco jinýho :D
Jop, tak to si asi pletu. ;D Jsem se dival, jestli na wikipedii bude o tech morfismech nejakej dobrej clanek, a narazil jsem presne na ten odkaz :D. Tak to se omlouvam, v tom pripade bude ten postup o to ucinnejsi.
2 llAmElliK:
diky, to jsem si nebyl moc jistej.
V tom pripade asi nepripada v uvahu davat na celou code sekci hw breakpointy s ohledem na jejich omezeny pocet. Pokud se to neda udelat nejak jinak (otazka k zamysleni do plena "Jak monitorovat zapis do code sekce?"), tak druhy zpusob odpada cely.
btw. Jinak nevite, bude SoftIce fungovat pod wine na linuxu? Nebo mu ta emulace zabrani v pristupu k linuxovskemu jadru? Zatim jsem se setkal na linuxu jen s gdb, ale jestli je to kernel debugger nevim.
Netusim proc chces volit HW breakpoint - ale v olly se na sekce PE daji dat "memory bp" s definici na zapis, cteni - cteni zapis atd.Funguji myslim velmi dobre - jen je treba sledovat zmeny...
U druhe otazky ti spis odpovi Z80 - na Linuxu mam pouze Olly, ale na VMware a sice je na googlu spousty navodu...
Jeste to johnsimthx
todo:
c) identifikace kompileru/packeru/crypteru pomoci vlastni interpretace PEiDovskeho userdb.txt
d) kontrola PE checksumu
e) detekce "zajimavych" API z import table
f) detekce digitalniho podpisu
2. faze (slower)
todo:
a) pokus o rozbaleni packovanych (i cryptovanych?) souboru, v pripade uspechu skok na 1. fazi
b) verifikace certifikatu digitalniho podpisu
c) detekce poly/meta-morfniho kodu
v techto dvou fazich vidim nejvetsi problem, vim, ze samozrejme "bezny uzivatel" tezko bude menit hlavicky PE a hrat si s API ale ciste hypoteticky, je zcela bezne API cryptovat , maskovat atd (podivej na oblibene Conflictakovi vychytavky) - cili spousty jich po pouziti packeru "chybi".
Vec druha - nevim jake mate moznosti, ale nezda se mi prilis realne vytvorit jakykoliv universalni (generic) nastroj na decrypci a unpack(unwrap) nejen polymorfnich packeru....jejich detekce je vec jedna ale uspesny navrat do puvodniho napr exe dost problematicky bez manualnich zasahu
A jeste jedna vec by mne zajimala , ackoliv dnes to davno neni zadne "tabu"- jak dokazete analyzovat - zmapovat soubory vytvorene v PCODE?
Ono taghle - jenom uplnej DEBIL si zmeni xicht ve photoshopu a vystavi jej na net a laka -nactilety na svoje sexualne uchylny orgie s tim, ze je "dobre pres fotosop zamaskovan" (tady nemusime chodit daleko, neni uplne neznama afera "chytrych" amiku, kteri nez vypustili do sveta jiste dokumenty tak citliva mista "zacmarali" v malovani a zjevne jim nedoslo, ze ta cerna cara jsou pouze nejaka data navic a, ze nebude trvat dlouho a nekdo je odstrani)
Ale upravy PE a s tim spojene packery a crytovani zadni blbci nedelaj a povetsinou jsou to lide "z druhe strany", kteri vi ceho se vyvarovat a na internetu se vali spousty "home made" packeru a crypteru, ktere dokazi situaci zneprijemnit..
-
je zcela bezne API cryptovat , maskovat atd (podivej na oblibene Conflictakovi vychytavky)
(dopredu rikam, ze sem necetl celou diskuzi)
Asi mas na mysli EPO, kde se da treba za API ExitProcess schovat GetDlgItemTextA a nebo jakykoliv jiny, nejlepe spustitelny kod.
Vyzaduje to ale hratky a planovani pri aplikovani teto metody => zbytecne slozity (ale ucinny). Uplne staci pres LoadLibraryA + GetProcAddress ziskat potrebne API. Delal to tak UPX a spousta dalsich packeru. Navic neni zapotrebi zadny importni tabulky, viz. viry a jejich hledani API.Ale tohle sou extremni pripady.
Pokud mas praci na hratkach s .exe zaplacenou, tak oukej. Pokud to delas pro svy poteseni, tak se na to vykasli, v dnesni dobe (temer) zbytecna ztrata casu. Radsi jdi pro svy poteseni ven.
-
Me napadla jedna metoda, ktera sice nebude 100% a uz tady byl nastineny podobny princip. Konkretne se jedna o tu detekci poly/meta morfismu. Jako moznost se jevi program 2x spustit, pokazde si udelat checksum jeho .code pameti a porovnat. Sice to nebude 100% a muze to teoreticky zarvat na fake, ale morfismus by to melo najit.
-
e) detekce "zajimavych" API z import table
a) pokus o rozbaleni packovanych (i cryptovanych?) souboru, v pripade uspechu skok na 1. fazi
v techto dvou fazich vidim nejvetsi problem, vim, ze samozrejme "bezny uzivatel" tezko bude menit hlavicky PE a hrat si s API ale ciste hypoteticky, je zcela bezne API cryptovat , maskovat atd (podivej na oblibene Conflictakovi vychytavky) - cili spousty jich po pouziti packeru
Jestli chces naznacit, ze je blbost toto zkouset, protoze to nebude 100%, pak se na to divas ze spatneho pohledu. Samozrejme, ze to nebude 100%, mozna to i bude velmi chabe, ale stale to bude krok dopredu. Zadny software, ktery nyni pouzivame (a vetsinou jde o pomerne drahe softwary), takto automatizovane zkoumat PE soubory neumi a bohuzel jsem ani nenasel zadny, ktery by neco takoveho vubec umel. Klidne bych ho i koupil (za nejakou rozumnou cenu), ale proste takovy program neznam.
Nejefektivnejsi by samozrejme bylo zkoumat kazdy soubor rucne, debuggerovat atd. Jenze to jde udelat u jednotek souboru, ne u tisicu ci desetitisicu. Pro nas jsou vzdy limitujici 2 faktory: deadline a budget. Tyto faktory maji navic protichudne dusledky. Abych se vlezl do terminu a stihnul udelat hodne prace, tak to mohu sice vyresit tak, ze praci rozlozim mezi vice lidi, jenze pak mi vzrostou naklady natolik, ze mi to nikdo nikdy nezaplati. Navic rozpocet je znam predem. Ilustrativni priklad: pred 10 lety zkoumal znalec 2 mesice datove nosice o celkove kapacite 1000 MB a inkasoval za to 50 tisic. Kc. Techto 50 tisic muze predstavovat v dnesnich penezich (s prihlednutim k rustu nakladu, inflaci apod.) rekneme 100 tis. Kc. Ovsem dnes za 100 tisic mame 2 mesice zkoumat napr. 1000 GB dat. Cili penize i doba zustaji stale stejne, ale objem dat se nam zvetsuje 1000 krat! Takze logicky se automatizuje vsechno, co jde, aby se to pocatecni kvantum dat zredukovalo na to skutecne minimum, ktere se pak da (byt stale ve spechu) mozna trochu zkoumat rucne.
Kdyz se podivas na nejaka computer forensics fora ve svete nebo se zeptas nejakych zahranicnich znalcu, nikdo nema cas (ani chut, pripadne znalosti) PE soubory zkoumat vic nez proste proti nim pustit automatizovane programy (ktere vyplivnou temer nic). Oni to beru jako realitu, se kterou nemohou nic udelat. Ja se snazim jit trochu dal, v metodach, v pouzitem softwaru (napr. dle ceskeho distributora firmy AccessData jsme jedini v republice, kdo si zatim koupil novou radu FTK), v hloubce analyz. No a co se tyce analyzy PE souboru, tak vzhledem k tomu, ze programuji nejakych 23 let (na te strance s knihovnou viru, co tady postnul NeptuN, jsem dokonce nasel svuj virus, ktery jsem napsal zacatkem 90. let), se snazim i trochu neco udelat v teto oblasti a vysledny software davam (alespon zatim) verejne k dispozici jako freeware. Nemel jsem zadna ocekavani, kdyz jsem tady napsal, ale to mnozstvi podnetu, ktere jsem tady dostal, je skutecne skvele. Myslim, ze se mi podari hodne z tech veci naimplementovat a co je nepodstatnejsi je, ze mi to realne pomuze v praci. Stale to vsak bude mit velmi velmi daleko k dostatecnosti, jak spravne podotykas. Ale co muzu delat vice? Nebo se na to vykaslat, protoze to "stejne neni dokonale"? Technik, jak zmast a zneefektivnit praci znalcu v tomto oboru je mnoho (google "anti-computer forensic") a znalec se vice a vice stava jen statistou. Velky problem vidim s tim exponencialne rostoucim mnozstvim dat - dnes lze bez obtizi do kazdeho jednoho pocitace vlozit 8 harddisku, coz muze byt 16 TB. Kolik takovych pocitacu muze mit organizovana skupina? V takove situaci uz ani ti kriminalnici nemusi nic sifrovat, staci, aby vsechna sva tajna data ukryly do .exe souboru, a nikdo to nema sanci najit.
Coz mne privadi k myslence, ze by stalo za to nejakym zpusobem kontrolovat, jestli k PE souboru nejsou pripojena "bezprizorni" data. Jakoze treba vezmu .zip soubor a prilepim ho ke konci .exe souboru. Jak by se neco takoveho pak dalo zjistit? Nesoulad mezi velikosti dle PE headeru a skutecnou velikosti?
-
Vyzaduje to ale hratky a planovani pri aplikovani teto metody => zbytecne slozity (ale ucinny). Uplne staci pres LoadLibraryA + GetProcAddress ziskat potrebne API. Delal to tak UPX a spousta dalsich packeru. Navic neni zapotrebi zadny importni tabulky, viz. viry a jejich hledani API.Ale
Pokud nejaky program supluje importni tabulku pomoci LoadLibraryA + GetProcAddress, pak ale musi mit v importni tabulce alepon prave tyto dve funkce, ne? Cili tyto funkce mozna mohou byt prvni kandidati do seznamu "zajimavych" API.
-
Me napadla jedna metoda, ktera sice nebude 100% a uz tady byl nastineny podobny princip. Konkretne se jedna o tu detekci poly/meta morfismu. Jako moznost se jevi program 2x spustit, pokazde si udelat checksum jeho .code pameti a porovnat. Sice to nebude 100% a muze to teoreticky zarvat na fake, ale morfismus by to melo najit.
Dalsi dobry napad. K tomu bych asi musel pouzit maly VMware image, pro kazdy soubor vzdy udelat novy klon, zkopirovat tam podezrely soubor, spustit a pak zkoumat zmeny, ktere nastaly v tomto klonu (coz bude urcite obsah pameti a mozna i nejake zmeny na harddisku). Mozna k tomu mit soucasne pusteny process monitor a pak analyzovat jeho log? Nastesti VMware ma nejake API pro programove ovladani guest systemu z host systemu.
-
Pokud nejaky program supluje importni tabulku pomoci LoadLibraryA + GetProcAddress, pak ale musi mit v importni tabulce alepon prave tyto dve funkce, ne? Cili tyto funkce mozna mohou byt prvni kandidati do seznamu "zajimavych" API.
jenze tyhle dve funkce sou ve vsech programech. Takze nejsou kandidaty. Maximalne, ze by byly v importni tabulce jen tyhle dve funkce.
V takove situaci uz ani ti kriminalnici nemusi nic sifrovat, staci, aby vsechna sva tajna data ukryly do .exe souboru, a nikdo to nema sanci najit.
Coz mne privadi k myslence, ze by stalo za to nejakym zpusobem kontrolovat, jestli k PE souboru nejsou pripojena "bezprizorni" data. Jakoze treba vezmu .zip soubor a prilepim ho ke konci .exe souboru. Jak by se neco takoveho pak dalo zjistit? Nesoulad mezi velikosti dle PE headeru a skutecnou velikosti?
O skryvani souboru do .exe se tu jeden clovek pokousel.
Nesoulad mezi velikosti v PE headeru a skutecnou velikosti by nemel nastat, protoze by to pak zavadec neprelouskal a vyhodil chybu.
Lepsi nez schovavat data do .exe, je schovat data do obrazku.
-
(napr. dle ceskeho distributora firmy AccessData jsme jedini v republice, kdo si zatim koupil novou radu FTK)
a mate k dispozicii aj novy PRTK od tejto firmy, zaujimali by ma urcite benchmarky.
-
(napr. dle ceskeho distributora firmy AccessData jsme jedini v republice, kdo si zatim koupil novou radu FTK)
a mate k dispozicii aj novy PRTK od tejto firmy, zaujimali by ma urcite benchmarky.
Jasne, PRTK i DNA s 50ti workery. Ackoliv se mi vetsinou osvedcily spise programy z russian password crackers portalu, a ted v dobe CUDA uz CPU-only programy nemaji smysl vubec, tak jsem PRTK/DNA s velkou davkou skepticismu trochu zkousel, RAR konkretne, a je to zhruba o 10-20% rychlejsi nez jine programy. Jeste lepsi zprava ale je, ze AccessData uz potvrdili na foru, ze pripravuji vyuziti GPGPU.
Co naopak jsem nenasel vubec jsou nejaka konkretni cisla o vykonnosti tech hardwarovych akceleratoru TACC1441 a jejich srovnani treba s GTX295, a pokud by to bylo nesrovnatelne, pak treba s 3x Tesla C1060 (coz by celkem vyslo stejne jako jedna ta TACC krabicka).
-
RAR konkretne, a je to zhruba o 10-20% rychlejsi nez jine programy.
Co naopak jsem nenasel vubec jsou nejaka konkretni cisla o vykonnosti tech hardwarovych akceleratoru TACC1441
o 10-20% rychlejsi s tymi 50ti workery? :-)
nejake benchmarky ohladom TACC1441 su tu:
http://www.tableau.com/index.php?pageid=tacc_alg
suhlasim softy kt nemaju podporu GPU su uz dneska v nevyhode ... Inac celkom sa mi pozdavaju aj niektore ElcomSoft produkty.
Niekedy v minulosti som chcel nakodit nieco ako DNA so zasuvnymi modulami (modul = podpora dakeho hashu alebo pswd) s tym ze, pisanie modulov by bolo opensource, bolo by k tomu SDK, cize ludia by si mohli pridavat vlastne veci a len server app by bola produkt.
-
o 10-20% rychlejsi s tymi 50ti workery? :-)
Ne :D 10-20% rychlejsi je PRTK, coz je prakticky DNA s jedinym workerem na localhostu.
nejake benchmarky ohladom TACC1441 su tu:
http://www.tableau.com/index.php?pageid=tacc_alg
Parada! No to ale vypada katastrofalne - RAR 1300 p/s??
Ted jsem zkousel na obycejne GTX275 za 4.8 tis. Kc a cRARk udela 2227 p/s a igrargpu dokonce 3185 p/s. TACC stoji taky 4.8 tis., ale USD. Tak jestli je 2x pomalejsi nez GTX275, tak je prakticky 34x drazsi.
Kdyz srovnam Tesly a GTX, tak Tesla je docela nevyhodna. Tesla C1060 ma vicemene srovnatelny vykon s GTX285, tedy o trochu rychlejsi nez GTX275, avsak stoji 5x draz nez GTX275. Nebo ve srovnani s GTX295 je Tesla C1060 2x pomalejsi, ale pritom je 2.5x drazsi. Nemuzu si pomoct, nejvyhodnejsi mi stale prijdou stare dobre GTX295.
suhlasim softy kt nemaju podporu GPU su uz dneska v nevyhode ... Inac celkom sa mi pozdavaju aj niektore ElcomSoft produkty.
Souhlas, ElcomSoft je dost dobry, no tak je to vlastne ten autor cRARku. Ale maji to drahe, 100 klientu za 3995 USD: http://www.crackpassword.com/products/prs/corp/eprb/ (http://www.crackpassword.com/products/prs/corp/eprb/), to DNA se 100 klienty stoji zhruba 1500 USD.
Niekedy v minulosti som chcel nakodit nieco ako DNA so zasuvnymi modulami (modul = podpora dakeho hashu alebo pswd) s tym ze, pisanie modulov by bolo opensource, bolo by k tomu SDK, cize ludia by si mohli pridavat vlastne veci a len server app by bola produkt.
No k tomu bys mohl vyuzit Johna, zdrojaky to ma, jen bys tam pridal CUDU, multi core a sitovinu. Idealni by bylo na kazdem pocitaci umet vyuzivat vsechny GPU i CPU, tak jako to dela BarsWF. Skoda, ze John nefunguje jako BarsWF :'(
-
Souhlas, ElcomSoft je dost dobry, no tak je to vlastne ten autor cRARku.
Uz som sa bavil v minulosti s Pavlom Semjanovom a jeho system je teraz licencovany v Parallel Password Recovery (RAR module) http://www.parallelrecovery.com/rar-password.html kde je pouzity cRARk engine - momentalne najrychlejsi.
-
Nevim, proc jsem si myslel, ze cRARk je pouzity v ElcomSoft produktech :-[
Dobre, stahl jsem si demo toho parallel password, tak to zkusim porovnat.