Hi , is your beautiful peace of work working with .net assembly ?

Im trying to run a .net assembly shellcode generated with the donuts tools from TheWover.
https://github.com/TheWover/donut

the .net PE i converted is a asyncrat PE, when i try to inject it inside a process (i had to remove the max shellcode lengh because shellcode is 147k bytes long) but i get no connection back / the asssembly is not starting ?

is this even possible to work with a .net PE?

sorry for retarded question but im really noy good with shellcode stuff.

Hello, I'm currently studying some codes and I ended up here.

I use windows x64, I had to compile the cpp using the "-DUNICODE" flag to be able to compile, but when I run the console it does not inject any pid and brings this error:

[+] Got process handle!
[+] Got function base!
[-] Failed to change protection: 0

I tried in notepad and others, in rust when I compile it says that this program is compatible with 32bits and not x64, so the normal "cargo b" instruction doesn't work.

I tried various processes from notepad to others and it doesn't work

.

Edit:
I was able to resolve the architecture error(Windows 10 x64) in rust by running the following commands:
rustup target add x86_64-pc-windows-gnu
cargo build --target x86_64-pc-windows-gnu

After the test, the calc does not open but in the console everything seems normal, I will continue the tests
The message shows the following

:

thanks in advance!

Hello @Idov31

Many thanks for your previous advice as those allowed me to make some little progress. I have tried the C++ code as well and I am facing the following challenge. Even when I am trying to put a breakpoint to debug the code. I have tried with the POC shellcode to spawn Calc and generated other examples with reverse shells in case that was the issue. Tested with the classic Windows calculator.

Many thanks,
Kind regards,
Federico

Microsoft Windows [Version 10.0.19045.3086]

C:\Users\federico\source\repos\test\x64\Release>test.exe
[+] Got process handle!
[+] Got function base!
[+] Changed protection to RW to write the shellcode.
[+] Successfuly stomped the function!
[+] Changed protection to WCX to run the shellcode!
[+] Shellcode successfuly injected!

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at FunctionStomping(UInt32 pid) in C:\Users\federico\source\repos\test\functionstomping.hpp:line 41
at mainCRTStartup()

Hello, neat idea you found there.
Is it possible to have more then 4096 bytes available for the shellcode or is it max?
If more is not possible, would it be possible to split it across more functions to achieve the goal?

Hello @Idov31

I am currently studying slowly on related subjects and I am new to Rust, how do I compile this for 64bits?

functionstomping.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.

Many thanks,
Best regards,
Federico

First of all, thanks for your work and publishing it along with the very interesting blog post.

I've been playing a bit with your POC, especially the Rust version, and there is something I'm not fully getting. Depending on the victim process, I get the following results:

• Majority of processes (e.g notepad): when the stomped function is called the shelllcode executes (calc pops open) and the victim process crashes with an access violation error.
• Some processes (e.g explorer.exe): when the stomped function is called the process crashes with an access violation error, but the shellcode does not seem to execute (nothing happens, no calc).

I've tried with a custom shellcode and by changing the targeted function in kernel32.dll but I always get the same results. So my questions are:

• Do you know why for some process the shellcode will not execute, the process will just crash ? (function used ? bad shellcode ?)
• Do you have an idea to get reliable shellcode execution on all processes ?

Functionstomping.exe getting flagged by defender.