DotNet First Side: Emulating Shellcodes

There are many basic shellcodes that can be emulated from the beginning from the end providing IOC like where is connecting and so on. But what can we do when the emulation get stuck at some point?

The console has many tools to interact with the emulator like it was a debugger but the shellcode really is not being executed so is safer than a debugger.

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin -vv

In some shellcodes the emulator emulates millions of instructions without problem, but in this case at instruction number 176 there is a crash, the [esp + 30h] contain an unexpected 0xffffffff.

There are two ways to trace the memory, tracing all memory operations with -m or inspecting specific place with -i which allow to use registers to express the memory location:

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin -i 'dword ptr [esp + 0x30]'

Now we know that in position 174 the value 0xffffffff is set.

But we have more control if we set the console at first instruction with -c 1 and set a memory breakpoint on write.

This "dec" instruction changes the zero for the 0xffffffff, and the instruction 90 is what actually is changing the stack value.

Lets trace the eax register to see if its a kind of counter or what is doing.

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin --reg eax

Eax is not a counter, is getting hardcoded values which is probably an API name:

In this case this shellcode depend on previous states and crash also in the debugger because of register values. this is just an example of how to operate in cases where is not fully emulated.

In next chapter will see how to unpack and dump to disk using the emulator.

DotNet First Side

Friday, June 2, 2023

Emulating Shellcodes - Chapter 1

More articles

No comments:

Post a Comment

Dotnet-Interviews

Blog Archive

Blog Roll