[ArkPhaze]

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 byte order.



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?

[ArkPhaze]

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 byte order.



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?

[ArkPhaze]

I solved this issue, that shellcode was not at all wrong, however it was not reading the right parts... I ended up viewing the registers and having to debug this that way to find out what was going on. I can now run that shellcode directly. Success is great moke:

[Psycho_Coder]

Wow great info.But in the code

Code:

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

I think there is an extra L, within the braces, its misprinted, it should be GetModuleHandle("kernel32.dll")

and have you compiled the asm code to get the beep sound.I think there is a functon in C sound(anynumber); that does the same job, though Beep() allows us to adjust the delay time as well.

[ArkPhaze]

Wow great info.But in the code

Code:

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

I think there is an extra L, within the braces, its misprinted, it should be GetModuleHandle("kernel32.dll")

and have you compiled the asm code to get the beep sound.I think there is a functon in C sound(anynumber); that does the same job, though Beep() allows us to adjust the delay time as well.

lol, Nope this is not C... There's a reason why I had the L there. This is just basic C++. That L serves a purpose however. The parameter expects a type of LPCWSTR

LP: long pointer
C: constant
W: wide
STR: string.

Otherwise it's just a const char* and not even unicode (16 bits), but rather 8 bit or 1 byte per char.

And yes that inline asm (if that's what you are talking about) gives me the beep sound from the Beep function in kernel32.dll. That's not the point of the thread though, the point was to use the ASM disassembly to get the shellcode for doing this, so I could compile and run that directly perhaps by injection elsewhere. Anyways, I also added onto the instructions, a ret, to avoid a segmentation fault from happening after running the set of byte instructions.

[ArkPhaze]

I imrpoved the byte code a bit by splitting the register into a 16 bit portion to hold the smaller integer value. This trims off the 0x0's effectively, which is a good thing, and because the params given will probably never be up to the size of a 32 bit (4 byte) integer value, there's no need for it. 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 unless I'm dealing with really small values, it would be stupid to do that.

I could have probably even utilized some bitshifting tricks to get rid of some 0x0's... This is good enough though, a value such as 0x3E8 is a bit too big for an 8 bit storage space however, so 16 bits was the next step up.

Anyways here's what I came up with:

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:

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

And all works fine, no 0x0's. The above byte code is with one added byte for the return, in addition to the instructions from the above C++ code. I'm getting tired of having to find the address of the function each time though, although it makes things a bit simpler once you have the address... I would like to create a more "universal" revision.

[ray_22]

Hello!!
Get missing dll files at https://rb.gy/b56kf online.