Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 312 Vote(s) - 3.53 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Kernel32.dll Beep Function

#1
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:

Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


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:

Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


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:


Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


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

[Image: k0DCxfA.png]

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


Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.



Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


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

Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


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.
Reply

#2
Quote:(04-25-2013, 06:13 AM)w00t Wrote:

[To see links please register here]

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.
Reply

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

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


Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.

Reply

#5
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:

Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


Which would be:

Hidden Content
You must

[To see links please register here]

or

[To see links please register here]

to view this content.


And all works fine
Reply

#6
Quote:(04-25-2013, 07:59 AM)w00t Wrote:

[To see links please register here]

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.
Reply

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



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through