Fråga:
Packa upp binärer på ett generiskt sätt
Remko
2013-03-20 20:25:47 UTC
view on stackexchange narkive permalink

Jag upptäcker att allt oftare packas binärer med exe-skydd som upx, aspack etc. Jag försökte följa några handledning om hur man packar upp dem men exemplen är ofta ganska enkla medan mina mål inte är det.

Jag letar efter bra resurser och några tips / tips om hur man packar upp mål.

[Lena tutorials] (http://tuts4you.com/download.php?list.17) kommer att arbeta igenom många av de tekniker som du kommer att se i många förpackare. Det finns några handledning som fokuserar mer på sprickbildning, men de har i allmänhet också bra information.
Vet du om: [Ether: Malware Analysis via Hardware Virtualization Extensions] (http://ether.gtisc.gatech.edu/)
Tre svar:
Igor Skochinsky
2013-03-20 23:57:25 UTC
view on stackexchange narkive permalink

Att packa upp ett generiskt paketpaket eller en kryptor innebär vanligtvis följande steg:

1. Spåra koden, eventuellt undvika eller kringgå anti-felsökningskontroller.

Detta är inte svårt för enkla förpackare men kan vara svårt för de mer avancerade. De kan använda timingkontroller ( rdtsc ), undantagsbaserad kontrollöverföring, använda felsökningsregister för beräkningar etc. Användning av en virtuell dator eller en emulator hjälper här vanligtvis mot de flesta av dem.

2. Hitta ursprunglig ingångspunkt (OEP)

Det finns många sätt att göra detta. Ibland är hoppet till OEP uppenbart när det följer en bit av looping-kod och det finns inget rimligt att ta hand om det. Eller så kan du känna igen koden på OEP om du känner till de startpunkter som produceras av olika kompilatorer. Ett par andra knep:

  1. om förpackaren sparar originalregisterna innan de packas upp, ställ in en hårdvarupaus på deras plats i stacken - på det här sättet bryter du precis när de är återställs innan du hoppar till OEP.

  2. om du under spårning kan identifiera minne där den uppackade koden skrivs, ställ in en brytpunkt för sidkörning på det minnesområdet - det kommer att utlösas efter hoppa. IDA låter dig ställa in en sådan brytpunkt, och jag tror att OllyDbg också.

  3. ställa in brytpunkter på vanliga API: er som används av startkod, t.ex. GetCommandLine eller GetVersionEx . Detta ger dig inte den exakta OEP, men du kan vanligtvis gå tillbaka callstack och hitta den mer eller mindre lätt.

3. Dumpa den uppackade koden

Om du använder IDA behöver du inte dumpa filen i en separat fil - det räcker att ta en minnesbild som skulle kopiera byten från minnet till databasen så att du kan analysera dem senare. En sak att tänka på här är att om förpackaren använde dynamiskt tilldelat minne måste du markera det som "loader" så att det ingår i ögonblicksbilden. Mer här.

4. Återställ import

Jag vet inte riktigt hur det görs i Olly eller andra felsökare, men AFAIK du måste använda ett verktyg som ImpREC på din dumpning och en kopia av processen i minnet.

Det är något enklare (IMO) i IDA. Du behöver bara hitta importtabellen och byta namn på pekarna enligt de funktioner de för närvarande pekar på (detta bör göras medan felsökaren är aktiv). Du kan använda antingen renimp.idc -skript eller UUNP "manuell rekonstrueringsfunktion" (se här).

För att hitta importtabell finns det två knep som jag använd ibland:

  • följ några samtal i startkoden på OEP för att hitta externa API: er och detta skulle leda dig till importtabellen. Vanligtvis är början och slutet av tabellen uppenbar.

  • under uppackning, ställ in en brytpunkt på GetProcAddress och se var resultaten skrivs. Detta fungerar dock inte med förpackare som använder manuell importresultat med hjälp av exportkatalogen. Att sätta en läst BP på kernel32s exporttabell kan hjälpa till här.

5. Rensa upp

Detta är valfritt men det kan vara användbart att ta bort resterna av packarkoden som bara skulle distrahera dig. I IDA bör du också tillämpa en kompilator-FLIRT-signatur om du känner igen kompilatorn som används.

6. Att göra en uppackad körbar

Jag gör inte det här steget eftersom jag sällan behöver köra den uppackade filen men i allmänhet behöver du vanligtvis fixa PE-rubriken så att förskjutningar till sektionens kod i filen matchar de i dumpningen.


Nu finns det många variationer och knep som inte omfattas av ovanstående steg. Till exempel löser vissa förpackare inte importen till en början utan lägger hopp till stubbar som löser import vid första samtalet och lappar sedan den så att den går direkt till målet nästa gång. Sedan finns det en "stulen kod" -metod som gör det svårare att hitta och återställa OEP. Ibland kör packaren en kopia av sig själv och felsöker den, så att du inte kan bifoga din egen felsökare till den (detta kan lösas med hjälp av emulator eller en felsökare som inte använder felsöknings-API: er som Intel PIN). Ändå kan de beskrivna stegen täcka en hel del av det som finns där ute.

Jag kommer att avsluta med videon som Elias gjorde och visar processen att packa upp Lighty Compressor: https: //www.hex -rays.com/video/bochs_video_2.html

bra svar (+1) och utan tvekan spelar IDA en stor roll i allmänhet i RCE, men jag tror att du inte borde begränsa ditt svar till bara IDA (ja, jag såg nämna ImpRec och OllyDbg).
@0xC0000022L: Jag är tyvärr inte bekant med att packa upp i OllyDbg, jag vet bara om det i teorin. Men jag tror att det mesta av mitt svar kan användas med alla felsökare (jag skulle faktiskt inte säga att det är "begränsat" till IDA alls). Du kan dock lägga till ditt eget svar specifikt om att packa upp i OllyDbg!
trevligt svar, här är ett verktyg: http://ether.gtisc.gatech.edu/
@IgorSkochinsky Jag är faktiskt väldigt glad att du täckte IDA här, för uppriktigt sagt finns det massor av information om hur man gör detta i Olly / x64 på Tuts4You och på andra håll, men inte mycket om hur man gör detta i IDA Pro. Jag är mycket tacksam för detta eftersom jag lärde mig ett helt nytt sätt att hantera detta problem helt i IDA Pro. Har du fler IDA Pro-förslag för att lösa problemet nyare än det här inlägget (plugins / bloggar / etc)? Tack Igor.
94c3
2013-03-22 05:28:10 UTC
view on stackexchange narkive permalink

Igors svar är mycket bra. De skisserade teknikerna förlitar sig dock på antagandet att den körbara filen någon gång packas upp i minnet. Detta är inte alltid sant. Virtualiseringsobfusaktorer sammanställer den ursprungliga binären till en anpassad instruktionsuppsättning när den körs av en simulator vid körning. Om du stöter på en binär förvirrad på detta sätt har du inget annat val än att skriva en demonterare från den anpassade instruktionsuppsättningen till en instruktionsuppsättning som du förstår.

Ja, jag nämnde att jag pratar om förpackningar.
Tja, tekniskt sett till och med VM-skyddarna lämnar filen uppackad i minnet, dvs de fungerar fortfarande som "omslagspackare". Den enda skillnaden är att det är mycket svårare att förstå koden som skyddas av en virtuell dator, även om den är "i vanlig syn".
@newgre: kommer dock inte alla att packa upp allt på en gång. Så du kan sluta med bitar och bitar.
Vilka VM-packare gör det?
newgre kan du förklara hur steg 3 i Igors process är möjligt när det enda i minnet är bytekod för en randomiserad instruktionsuppsättning? Det enda sättet att dumpa en körbar skyddad på detta sätt är att skriva en disassembler för bytecode.
Det finns några alternativ när du stöter på en sådan binär, här är en - https://github.com/jnraber/VirtualDeobfuscator
rj_
2014-05-10 15:00:42 UTC
view on stackexchange narkive permalink

Blackstorm portal har en enorm samling av självuppackningshandledning Blackstorm portalhandledning

Tuts4You har en annan stor samling av självuppackningshandledning Tuts4You

Det tog mig lång tid först men med tiden blev uppackningen mycket enklare, men det behövdes mycket tålamod och övning.



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...