Sign in to follow this  
Followers 0
unregistered

how does one encrypt a running process in ram

8 posts in this topic

Sounds to me like he wants to get Glider or something similar to run without the program it's attached to being able to detect it.

Processes in RAM can't really be "encrypted" per-se. Not in any way I know of, at least. One COULD recompile the code to do the same thing with a different assembly structure, but considering this this the Nubie HQ, I don't that's something you're up for.

0

Share this post


Link to post
Share on other sites
Processes in RAM can't really be "encrypted" per-se. Not in any way I know of, at least. One COULD recompile the code to do the same thing with a different assembly structure, but considering this this the Nubie HQ, I don't that's something you're up for

In simpler words, a running process can be dumped and then reconstructed in assembly language easily. Thus it is impossible to encrypt a running process.

0

Share this post


Link to post
Share on other sites

Some of the newer processors can encrypt everything which is stored in external ram, this is handled by hardware built into the processor. The data/code is encrypted/decrypted on the fly as it is written to/read from ram.

It is impossible to encrypt all ram, as the processor need to interpret the instructions in order to run them

Mungewell.

0

Share this post


Link to post
Share on other sites

I'm working on a userland rtld to do do runtime binary encryption/decryption.

0

Share this post


Link to post
Share on other sites
The data/code is encrypted/decrypted on the fly as it is written to/read from ram.

Here is where I can intercept it and dump it and read it...

0

Share this post


Link to post
Share on other sites

Even though code can be read and snap-shotted after decryption doesn't mean there is no point in encrypting or obfuscating your code. There are a few ways to do this. Theory-wise, I would reccomend a custom assembler that modulizes labels and functions so that they can be re-arranged, then when building a binary, sets it up so that only functions/modules are decrypted per any given time, after which they are erased. In other words, decrypt a piece, execute it, erase the decrypted copy, decrypt the next necessary function, execute it, etc etc...

Common debuggers are vulnerable to code obfuscation via out-of-order code execution, which you can see here. This may be a good method to obfuscate your decrypted code against debuggers such as OllyDBG for windows and GDB for *nix, however tools such as IDA Pro will still read the code in the correct order. If someone is using OllyDBG or GDB to disassemble your application, they will have to know machine code more or less to detect what you're doing, assuming they do not have a copy of IDA Pro.

At the assembly level there are many ways to encrypt and decrypt code. Weaker methods use the XOR and OR and mathematical (add, sub, imul, idiv) instructions, while some stronger methods may use shl, shr, rol, ror and other bit-shifting or bit-rotating instructions.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0