Jump to content











Submitter

SUPPORT TOPIC File Information

  • Submitted: Dec 20 2011 12:38 PM
  • Last Updated: Dec 22 2011 10:50 PM
  • File Size: 5.94MB
  • Views: 6037
  • Downloads: 4024
  • Approved by: Nuno Brito
  • Approved on: 21 December 2011 - 12:02 PM

Previous Versions

  • 21 Dec 2011 Download ShellCodeExecGUI v3

Download ShellCodeExecGUI v4

- - - - -



Screenshots
This is a GUI for executing machinecode in text form, or as one would say uncompiled shellcode. The application makes use of a trick to execute binaries from memory. What is mapped to memory first, is a standard minimal shellcode executer looking like this;

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char code[] =   "the shellcode";

int main(int argc, char **argv)
{
	((void (*)())code)();
	
	return 0;
}

However, I compiled it in Visual Studio with 10240 bytes of junk (00's), so the actual executer does absolutely nothing in itself, but can receive as much as 10240 bytes of code. Now we can write our custom shellcode into the right memory location and execute the memory-mapped shellcode executer that now holds our shellcode. Btw, the execute-from-memory trick originates from trancexx; http://www.autoitscr...412-run-binary/ which again probably learned from; http://www.joachim-b...ll-from-memory/

The memory-mapped exe is located inside the GUI as a resource. On the 32-bit version it is named SHELLCODE, and on the 64-bit version named SHELLCODE64 and is of type RCDATA. In the download both these base exe's can be found as empty_x86.exe and empty_x64.exe. Alternatively they could have been embedded in the actual script, but I chose not to.

So there's 3 ways to execute the code:
  • Paste the code directly in the input field and press execute. Code can be in the usual form; "\xFC\x33\xD2\xB2\x30\x64\xFF\x32\x5A\x8B" or "FC33D2B23064FF325A8B". All non-hexadecimal characters are automatically stripped out, so paste the code without any comments.
  • Open and execute a text file with code in the form as specified in #1.
  • Open and execute a binary file containing the shellcode.
Both 32-bit and 64-bit version are included. It has been tested on 32-bit XP and Windows 7, and 64-bit Windows 7, for which it works great. Bear in mind that shellcode usually are very OS dependant, so if something does not work, it is likely the shellcode and not the GUI that is wrong. For some very basic testing I included my own application that implements GetProcAddress. Ie, it will get the address of a given function. Also usually referred to as "arwin.exe". Note that functions are case sensitive.

Debugging shellcode:
Debugging of the code is now implemented and can be configured with a tickbox. What I did was just inserting 0xCC (INT 3) right before the shellcode, or 0x90 if configured off. To debug, JIT debugger obviously must be configured. If using WinDBG it can be set by this command; "windbg -I". What happens then is, the debugger will fire up exactly at the start of the shellcode. Very handy! The debug stuff has been tested OK on 32-bit XP, but I see no reason it should not work on other OS/Arch since 0xCC = INT 3 anyway.. Look at the linked image and you'll see that 0xCC will trigger debugger and that you are right at shellcode start.

Posted Image

The above image really is very descriptive of what is going on in a debug session. Notice how badly formatted shellcode is just pasted in and executed.

More shellcode explanantion might be necessary, but I'm really not very experienced with shellcoding, and am therefore not the right person to. But I think it is a nice way of jumping into it. I am not saying this is something great to have when developing shellcode. I am just saying it might be usefull when getting your hands dirty for the first time, and learning. For instance you have some shellcode that opens a messagebox, but the address is wrong and you want to change it and test without recompiling. Or you have some basic shellcode that executes a Beep or calc.exe, that you want to fiddle with, and expand on. Preferrably run all this inside a virtual machine when testing (highly recommended, but not necessary if you know what you're executing). For some serious tracing, a debugger would be necessary, and for that reason I added an option to do so by means of INT3. This is fun to learn, and sometimes practical testing is a good and funny part of it. I think the easyness of testing modified existing code is appealing here.

Of course one could have compiled a cli executer that would take the textual machinecode as an argument, but that's a different method. Now a few days later I found one at; http://mcdermottcybe...s-x64-shellcode but it will take the shellcode as a binary file, so use use the included text2bin.exe to convert textual hex into binary form. The app's source runbin.c have been compiled into both runbin_x86.exe and runbin_x64.exe. A nice feature on that little app is -d switch for debugging. Also compiled the source shell64.asm on that site. The machine code variant is included as shell64.bin, and can be used to test msgbox shellcode on Windows 7 x64. Its disassembly is included as msgbox64.txt.

The method implemented in the GUI is almost the same as patching an executable on-disk. Except we already know where to inject the code and don't need to worry about cleaning up afterwards. And to clarify, this is NOT about executing exploits! It is about observing what would otherwise happen after an exploit has worked (ie the payload execution in the metasploit world).

Included in the download is a "OS universal" sample written by Berend-Jan "SkyLined" Wever that launches calc.exe, at only 100 bytes of code.

The included text2bin.exe is a handy utility for converting shellcode source into binary. Be sure to have excluded comments and other c source stuff from it so the file only contains;

; "\x2f\xbe\x2f\xd9\x2f\xc7\x2f\xd0\xe7\x9a\xfe\xfe\xfe\x54\x2f\xbe"
; "\x62\x89\x3e\x2e\x83\xbe\x76\x0a\x89\x3e\x0a\x89\x6e\x1a\xab\x89"

or smething like;

FC33D2B23064FF325A8B

Having its binary form is necessary when disassembling it. For that task, ndisasm.exe (included with nasm) is great; http://www.nasm.us/

Example:
Here is some very basic 19 bytes designed for XP SP3 that will execute the Beep function in kernel32.dll;

\x33\xC0\xB8\x8F\x7A\x83\x7C\x68\x00\x04\x00\x00\x68\x00\x03\x00\x00\xFF\xD0

When disassembled look like this;

00401000	 33C0		   XOR EAX,EAX							
00401002	 B8 8F7A837C	MOV EAX,kernel32.Beep				  
00401007	 68 00040000	PUSH 400							  
0040100C	 68 00030000	PUSH 300							  
00401011	 FFD0		   CALL EAX								

Pasting that code in my program, may or may not work. In my case it did not. I have the right OS, but probably wrong language. So I looked up the address of Beep in kernel32 on my system, and noticed;

Found function Beep in module kernel32.dll at address: 0x7C837AA7
Shellcode formatted: \xA7\x7A\x83\x7C

So I replaced "\x8F\x7A\x83\x7C" with "\xA7\x7A\x83\x7C" and tried again, and voila it works. Now looking up the function at msdn; http://msdn.microsof...7(v=vs.85).aspx reviels that PUSH 400 and PUSH 300 pushes the values of dwDuration and dwFreq onto the stack (in the reverse order compared to documentation at msdn). So if we change PUSH 400 to PUSH 8000 and PUSH 300 to Push 870, you would be rather annoyed, especially if suffering tinnitus.

What's New in Version v4 (See full changelog)

  • v4:
  • - Added a more userfriendly input field for code to be copy/pasted and edited.
  • v3:
  • - Added configuration for debugging
  • v2:
  • - 64-bit
  • - Some more handy utilities, like text2bin and runbin.
  • - More samples and description.


Screenshots

Screenshots Screenshots




  • 375 Total Files
  • 13 Total Categories
  • 90 Total Authors
  • 5097455 Total Downloads
  • Emsisoft Emergency Kit Latest File
  • Rolf Latest Submitter

42 user(s) are online (in the past 3000 minutes)

0 members, 41 guests, 0 anonymous users


Bing (1)