Introduksjon til skadevareutpakking

Når et program pakkes, blir den opprinnelige koden transformert (komprimert/kryptert) og innebygd i et nytt, lite kodestykke kalt "stub".

Når det pakkede programmet kjører, kjøres stub-en først. Oppgaven er å:

• Allokere minne.
• Dekryptere eller dekomprimere den opprinnelige programkoden til minnet.
• Overføre kontrollen (hoppe) til det opprinnelige programmets startpunkt.

Hvordan kan De se om en fil er pakket? Her er noen vanlige indikatorer:

• Høy entropi: Data som ser tilfeldige ut (for eksempel krypterte data) har høy entropi. Verktøy kan måle dette.
• Uvanlige seksjoner: Pakkede filer har ofte egendefinerte eller omdøpte seksjoner (for eksempel .UPX0, .RLC) med uvanlige tillatelser.
• Manglende importer: Filens importtabell (listen over eksterne funksjoner den kaller) kan være svært liten, siden stub-en utfører innlastingen.

Verktøy som PEiD eller Detect It Easy (DIE) kan ofte identifisere vanlige packere.

Oppakking er prosessen med å reversere pakkingen. Målet vårt er å hente den opprinnelige, ikke-tilslørte koden fra minnet og lagre den i en ny fil.

Når skadevaren er pakket opp, blir den mye enklere å analysere ved hjelp av verktøy for statisk analyse (disassembler) og feilsøkere, slik at den egentlige hensikten blir synlig.

Det mest kritiske trinnet ved manuell oppakking er å finne Original Entry Point (OEP). Dette er minneadressen der den opprinnelige, oppakkede programkoden begynner å kjøre.

Packerens stub hopper til slutt til OEP etter at den har dekryptert/dekomprimert det opprinnelige programmet. Oppgaven Deres er å finne dette hoppet.

I en debugger (for eksempel OllyDbg eller x64dbg) kan De finne OEP ved å:

• Sporing: Gå trinnvis gjennom packerens stub til De ser en lang hoppinstruksjon (JMP) eller en retur (RET) som fører til et annet minneområde.
• Maskinvarebruddpunkter: Sett et maskinvarebruddpunkt på kodedelen av den pakkede filen. Når den skrives til (pakkes opp), stopper debuggeren, ofte nær OEP.
• API-bruddpunkter: Sett bruddpunkter på vanlige API-funksjoner som LoadLibraryA/W eller GetProcAddress, som det opprinnelige programmet kan kalle kort tid etter oppakkingen.

Når programmet har kjørt oppakkingsstub-en og nådd OEP, er den opprinnelige koden tilgjengelig i prosessens minneområde.

De kan bruke funksjonaliteten i debuggeren til å «dumpe» dette minneområdet til en ny fil på disken. Den nye filen vil inneholde det oppakkede kjørbare bildet.

Verktøy som ScyllaHide eller innebygde debuggerfunksjoner kan hjelpe med dette.

Den dumpede kjørbare filen har ofte en ødelagt eller ufullstendig Import Address Table (IAT). IAT forteller programmet hvilke eksterne funksjoner (fra DLL-filer) det må kalle.

Verktøy som Import REConstructor (ImpREC) eller Scylla kan analysere den dumpede filen og prosessen som kjører, og gjenoppbygge IAT slik at den oppakkede kjørbare filen kan kjøres og analyseres.

I denne leksjonen utforsket vi skadevarepackernes verden, og forsto hvorfor de brukes og hvordan de fungerer. Vi lærte å identifisere pakkede filer og gikk gjennom de viktigste trinnene ved manuell oppakking: finne OEP, dumpe minnet og reparere importtabellen.

Det er avgjørende å beherske disse grunnleggende oppakkingsteknikkene for avansert skadevareanalyse, slik at De kan avdekke den egentlige skadelige koden for videre undersøkelser.