Shifting yourself to space

May 23, 2011

Nanomites – First thoughts

Filed under: Uncategorized — shift32 @ 4:19 pm

After reading about nanomites I got quite excited and thought about implementing it on Linux
I thought it would quite easy, however it didn’t seem as the development started.

My work was basically based upon signals, whenever an application hits a signal
it goes to a signal handler, either registered by the parent process (debugger, etc)
or that the executable itself has it’s own signal handler

Signals are not a vague topic in Linux and there’s full documentation, I read a few papers about them and started working

1. SINGLESTEPPING with int $3

The basic idea was this –
1. Executable executes it's instructions one by one.
2. A signal handler is registered to handle interrupt traps
3. When the executable hits int $3 - Interrupt Trap the signal handler is executed
3.1 The signal handler check its tables against the current EIP to see whether or not it's a nanomite
3.1.1 Assuming it is a nanomite - the handler replaces the instructions of int $3 with the real instructions
3.1.2 The handler transfers execution to the executable to continue its journey

Problems –
1. When an int $3 is occured the program stops :/ so you can’t do anything
2. It’s not that easy to replace instructions due to sizes, int $3 only takes two bytes, while the real instructions might take more…

The solutions I tried going with were basically these:
1. Use PTRACE (shrug, I know) interface in order to single-step the executable and look for “cc” opcodes (int $3) using PEEKUSER parameter in the ptrace(…) function
2. The instructions after the int $3 will be padded with nops/garbage so we could replace them upon runtime

2. Using a different signal than int $3

I chose a random signal than int $3 and hoped for good, the idea was basically the same except this time I wasn’t using ptrace() at all
The problems which occured were that I was unable to write code to the running process and thus had to continue execution in my own huge char tables[c0de] = { “\xcd\x80”} array

3. Section permissions

This is a theoretical idea which I read that was implemented in the Shrinker packer (win32)
We set our section permissions to non-readable/executable and once a signal is raised we check our tables

Every packed section is encrypted and has no read/execution permissions
Each time there’s a jmp a section without read/execution permissions a signal is raised
We intercept the signal and on the fly decrypt one instruction at a time (and not the whole section, to avoid cold memory attacks) and execute it on the fly
The section remains encrypted and once its execution is done we set back the permissions to non-readable/execution

I haven’t started implementing it yet but it seems quite interesting work.

Stay tuned (:


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at