Encryption and decryption of executing memory

[ilcrba]

I have been looking at in memory scan evasion techniques. I have came across a few but they all rely on a Sleep() hook. Is it possible to encrypt all content and decrypt only single executing lines via step by step? What issues would that cause? Is there a better way to do this? I read about Armadillo and how it creates a parent process as debugger but not sure how that would be much different.

 

[DildoFagins]

https://xss.pro/threads/64259/ - you can try reading this article with a google translate. This method is not very practical, but maybe you'd get some new ideas based on it.

What issues would that cause?

Most of the solutions like that will make your code execute like 20 times slower.

 

[TrafficShop]

I have been looking at in memory scan evasion techniques. I have came across a few but they all rely on a Sleep() hook. Is it possible to encrypt all content and decrypt only single executing lines via step by step? What issues would that cause? Is there a better way to do this? I read about Armadillo and how it creates a parent process as debugger but not sure how that would be much different.

There are several techniques that can be used to evade memory scans:

1. Process hollowing: This technique involves creating a new process with a legitimate name, and then replacing the memory of the new process with the malicious payload. This can be done by using APIs such as VirtualAllocEx and WriteProcessMemory.
2. Process "Doppelgänging": This technique involves creating a new process and a legitimate file, and then using the NTFS file system to create a hard link to the legitimate file. The malicious payload is then executed by the legitimate file, bypassing memory scans.
3. Reflective DLL injection: This technique involves injecting a DLL into a process's memory and executing it using a reflective loader. This allows the payload to be executed directly from memory, bypassing disk scans.
4. AtomBombing: This technique involves the use of Atom Tables, which are a way for different processes to share data, by creating new atom and allocating memory for payload in the atom, making it hard for the scanner to detect.
5. Dynamic code generation: This technique involves generating code at runtime, rather than statically linking it. This can make it difficult for scanners to detect the malicious payload, as the code is not present in the binary.

 

[ilcrba]

There are several techniques that can be used to evade memory scans:

1. Process hollowing: This technique involves creating a new process with a legitimate name, and then replacing the memory of the new process with the malicious payload. This can be done by using APIs such as VirtualAllocEx and WriteProcessMemory.
2. Process "Doppelgänging": This technique involves creating a new process and a legitimate file, and then using the NTFS file system to create a hard link to the legitimate file. The malicious payload is then executed by the legitimate file, bypassing memory scans.
3. Reflective DLL injection: This technique involves injecting a DLL into a process's memory and executing it using a reflective loader. This allows the payload to be executed directly from memory, bypassing disk scans.
4. AtomBombing: This technique involves the use of Atom Tables, which are a way for different processes to share data, by creating new atom and allocating memory for payload in the atom, making it hard for the scanner to detect.
5. Dynamic code generation: This technique involves generating code at runtime, rather than statically linking it. This can make it difficult for scanners to detect the malicious payload, as the code is not present in the binary.

These don't prevent being scanned in memory. AV can scan whichever process it wants to. If you have a file not signed or trusted your chances of being scanned are high (my guess 100%). I am not sure if AVs scan microsoft executables but I would assume so.

 

[ilcrba]

https://xss.pro/threads/64259/ - you can try reading this article with a google translate. This method is not very practical, but maybe you'd get some new ideas based on it.


Most of the solutions like that will make your code execute like 20 times slower.

Yeah I had a look at that. It is kinda interesting how you took apart the program and then included it as a .hpp file. My goal would be to make it so I can evade memory scans for all programs. So I wouldn't want to have to build this into something.

Thoughts about using a length disassembler to encrypt/decrypt each line but issues come with rets, jmps, calls, etc. Would have to create something that handles all of that.

As far as attaching as a debugger I am not sure what you gain from that. My guess is you are just controlling the child process single step and you have access to all the memory? Even then you run into same problem as above. I wonder how Armadillo did it. But from reading they do full page encryption/decryption instead of lines.

 

[DildoFagins]

Thoughts about using a length disassembler to encrypt/decrypt each line but issues come with rets, jmps, calls, etc. Would have to create something that handles all of that.

Yes, you will need to make an emulator that does that for you. Filling .text section with int3 in the article was kinda cheat to make it simple while still working.

As far as attaching as a debugger I am not sure what you gain from that. My guess is you are just controlling the child process single step and you have access to all the memory? Even then you run into same problem as above. I wonder how Armadillo did it. But from reading they do full page encryption/decryption instead of lines

Well, as far as I remember Armadillo's Nanomotes was something like that: there was a second process who attached to the first process with a debugger and single stepping and decrypting instructions. You don't need to treat rets/jmps differently that way, I think, but you need to have two processes, as I believe it is impossible for process to debug itself (atleast it is not possible to do with IDebugControl interfaces, I tried it).

 

[ilcrba]

Yes, you will need to make an emulator that does that for you. Filling .text section with int3 in the article was kinda cheat to make it simple while still working.


Well, as far as I remember Armadillo's Nanomotes was something like that: there was a second process who attached to the first process with a debugger and single stepping and decrypting instructions. You don't need to treat rets/jmps differently that way, I think, but you need to have two processes, as I believe it is impossible for process to debug itself (atleast it is not possible to do with IDebugControl interfaces, I tried it).

I have some information that I would like to share with you privately. Are you able to send me a PM or have a Telegram?

 

[qGodless]

There are several techniques that can be used to evade memory scans:

1. Process hollowing: This technique involves creating a new process with a legitimate name, and then replacing the memory of the new process with the malicious payload. This can be done by using APIs such as VirtualAllocEx and WriteProcessMemory.
2. Process "Doppelgänging": This technique involves creating a new process and a legitimate file, and then using the NTFS file system to create a hard link to the legitimate file. The malicious payload is then executed by the legitimate file, bypassing memory scans.
3. Reflective DLL injection: This technique involves injecting a DLL into a process's memory and executing it using a reflective loader. This allows the payload to be executed directly from memory, bypassing disk scans.
4. AtomBombing: This technique involves the use of Atom Tables, which are a way for different processes to share data, by creating new atom and allocating memory for payload in the atom, making it hard for the scanner to detect.
5. Dynamic code generation: This technique involves generating code at runtime, rather than statically linking it. This can make it difficult for scanners to detect the malicious payload, as the code is not present in the binary.

ChatGPT output :/