You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey there. Great tool! I was testing some generated dotnet binaries with metasploit's execute assembly module and noticed arguments don't seem to do anything.
Here's a screenshot. Notice the binary runs but the arguments aren't used.
Using the -p flag to hardcode arguments in seems to work just fine
If I had to guess, this might be caused by a mismatch in function signatures between what Metasploit thinks the assembly would have (Main(string args[])) and the actual main function of the assembly. In this case: wmain(int argc, wchar_t * argv[])
The text was updated successfully, but these errors were encountered:
The behavior you are observing is related to how command line parameters are acquired.
execute_dotnet_assembly loads the clr into a new process via dll inject and invokes the assembly main method passing the indicated parameters. The parameters you pass to the module are not process command line parameters for notepad.
Donut tries to read the command line parameters of the process so it is able to read any notepad parameters.
So ultimately we think this behavior is hard to fix
Hey there. Great tool! I was testing some generated dotnet binaries with metasploit's execute assembly module and noticed arguments don't seem to do anything.
Here's a screenshot. Notice the binary runs but the arguments aren't used.
Using the
-p
flag to hardcode arguments in seems to work just fineIf I had to guess, this might be caused by a mismatch in function signatures between what Metasploit thinks the assembly would have (
Main(string args[])
) and the actual main function of the assembly. In this case:wmain(int argc, wchar_t * argv[])
The text was updated successfully, but these errors were encountered: