[cxS]

Alright, so in a mental debate on which area of the forum I should post this in, it was decided that this is "enough" of a suitable place for it. What I am trying to do is to compile a shellcode string (representing a set of instructions), that is to call the Beep function from kernel32.dll in Windows.

I was able to get a message box to show, as well as the beep in XP SP3... But I can't get this to work with Win8 x64.

This is what I am trying to simulate if you will:

Code:

Beep(700, 1000);

So I used from NASM suite, the NDISASM.exe utility to disassemble a test compiled binary in C++ with Visual Studio and got this result:

Code:

push word 0x3e8
add [bx+si],al
push word 0x2bc
add [bx+si],al
call word [di]

As you can see in this portion of the disassembly, there is the arguments for the function being pushed onto the stack starting with the duration, and then the frequency (with consideration to LIFO).

I created wrote and debugged a tidbit of C++ code to retrieve the address of the Beep function from the kernel32.dll:

Code:

GetProcAddress(
    GetModuleHandle(L"kernel32.dll"),
    "Beep"
);

Which gave me this address ~ 0x764531AF, which I suspect would be the equivalent of 0xAF 0x31 0x45 0x76 in shellcode, in that endianess.



After pointing to this address with my shellcode string, I still couldn't get a beep, so I went back to the start and verified that my address was correct. I even wrote inline asm block in C++ to verify that this address was pointing to the Beep function in the dll...

Code:

__asm
{
    mov eax,dword ptr 0x764531AF
    push 0x3E8
    push 0x2EE
    call eax
}

Code:

mov         eax,764531AFh  
push        3E8h  
push        2EEh  
call        eax

Worked like a charm. But my byte code did not:

Code:

0xB8 0xAF 0x31 0x45 0x76 0x68 0xE8 0x03 0x00 0x00 0x68 0xEE 0x02 0x00 0x00 0xFF 0xD0

Initially I wrote some inline asm, without the hard coded address, which gave values that I couldn't really use.

I managed to get a beep in XP SP3, but this would not work in Win8 x64 obviously as shellcode is usually very OS dependent.

Any ideas on where my shellcode is wrong?

edit: I have fixed this by adding a ret, and now I'm trying to get notepad and calc to execute. For some reason calc crashes the host afterwards, but the new independent process created is entirely fine. I think to avoid the main program from crashing I'll be compiling and executing the shellcode on a remote thread and do some other things there.

[w00t]

You can't have 0x00 in a string, that's the terminator.

[cxS]

You can't have 0x00 in a string, that's the terminator.

What makes you think that the Beep function takes string input for either of the 2 arguments? :S Those 0x0's are fine because they don't represent the null terminating character in this case for a c-style string. To confirm this, it works when I have several of them in a row for these arguments that are placed onto the stack in LIFO order when the Beep function executes.

Arg2: 0xE8 0x03 0x00 0x00
Arg1: 0xEE 0x02 0x00 0x00

These are (32 bit) integers as they are 4 bytes each. Definitely not string's though.

[w00t]

My point was more that your shellcode is being prematurely cut off when it's being interpreted. Rather than that do...

Code:

xor ecx, ecx
mov cl, 3e8h
push ecx

[cxS]

I thought of storing the full value in a register, and then pushing the high and low off on the stack separately before, which should work. Unless I go with higher values. 8 bits is really small though... So why cl? :S Perhaps split one up into 16 bits instead?

I could probably even utilize some bitshifting to get rid of some 0x0's. I suppose this will work for smaller values though, but I think 0x3E8 is a bit too big for an 8 bit storage, so I'm not sure why you posted that. :S

Anyways here's what I got:

Code:

__asm
{
    mov ecx, dword ptr 0x755631AF
    xor eax, eax
    mov ax, 0x320
    push eax
    mov ax, 0x450
    push eax
    call ecx
}

Which would be:

Code:

\xB9\xAF\x31\x56\x75\x33\xC0\x66\xB8\x20\x03\x50\x66\xB8\x50\x04\x50\xFF\xD1\xC3

And all works fine

[w00t]

I'm not sure why, but for some reason I thought cl would come out to be half of ecx.

[cxS]

I'm not sure why, but for some reason I thought cl would come out to be half of ecx.

Haha, that's cx, cl is the low 8 bit portion. Reversely ch; high.