search

TheWover / donut

Generates x86, x64, or AMD64+x86 position-independent shellcode that loads .NET Assemblies, PE files, and other Windows payloads from memory and runs them with parameters
BSD 3-Clause "New" or "Revised" License
3.53k stars 628 forks source link

Add syscalls #101

Open S4ntiagoP opened 2 years ago

S4ntiagoP commented 2 years ago

I added support for direct system calls using syswhispers2.

Due to how the loader is coded, I had to make some changes to SW2 so that it doesn't use global variables.
What I did is pass the syscall table as the last parameter for each syscall.
I works for both x64 and x86 (not for WoW64)

I also removed some APIs that are no longer used (as they have been replaced by syscalls).

Note:
This PR is built on top of this one: https://github.com/TheWover/donut/pull/100

Hope you like it!

TheWover commented 1 year ago

This also fixes errors with the Python module in Python 3.8

S4ntiagoP commented 1 year ago

That's because it sits on top of a previous PR that fixes that, maybe I should have created just one large PR instead of several smaller ones 😛

TheWover commented 1 year ago

I noticed that there are a couple PRs on the source repo/branch about stricmp.

This is a note to myself to adjust the code accordingly after merging.

TheWover commented 1 year ago

So I have considered how to integrate this and made the following decision:

1) I love this addition and appreciate the work to make it happen.

2) I'm not going to integrate it into the master branch. While it does make clear OpSec improvements, it reduces the reliability and flexibility of the project because syscalls occasionally change their function signature / parameters and the lack of WOW64 support. I see donut primarily as a proof-of-concept project that demonstrates TTPs, but does not go to all possible lengths to ensure operational security. That is left as an exercise to the user or is extra cost that may be incurred by full-time operators / organizations who choose to incorporate the tool into their operations or products. As such, I prioritize reliability and flexibility over an absolute degree of OpSec. Additionally, there would be an added maintenance burden on the project for adjusting the syscall usage if Microsoft changes those syscalls in the future.

3) However, I do want to provide it to users as a clear, documented option.

4) So, once v1.0 is released into master, I will create a branch that forks from that release and includes this PR. I will also update the readme in master to instruct people who prefer syscalls that they can find a version that fits that requirement in the syscalls branch. I will also add a disclaimer that it will not be supported or updated as regularly so use of it assumes a maintenance burden and the reliability/flexibility tradeoffs.

Meanwhile I will leave up the PR. Thanks again for the work and the other two PRs that this was built upon!

S4ntiagoP commented 1 year ago

You make a great point, thank you for the detailed explanation, I completely agree 😄