6 replies to this topic

[screamer]

Finally decided to move into the realm of assembler and shellcoding, anyone know of any good tutorials?

Oh, and one question: I've been reading a lot about writing shellcode by using assembler, and then throwing the program into gdb to examine the endian it spits out...but I'm somewhat confused. It says the following.

push $0x6d6f7266 #push from on the stack
push $0x20626f62 #push bob on the stack

(where "from" and "bob" are simply words being sent to write() to be printed to the screen)

But the article never explains how you know to translate the words "bob" and "from" into the hex shown above...can anyone fill me in? Or at least point me to the right spot online.

[dual]

Get in touch with Zapperlink.

[screamer]

Arright, will do. Thanks.

[ntheory]

Hmmm... no followups on this. For anyone who was looking for an explanation here goes...

The original code is:
push $0x6d6f7266 #push from on the stack
push $0x20626f62 #push bob on the stack

They probably should've put "from" and "bob" in quotes. What goes on the stack is actually the string "from" and then the string "bob " (notice the space at the end). The numbers are the hexadecimal representations of the strings.

0x6d == "m"
0x6f == "o"
0x72 == "r"
0x66 == "f"

0x20 == space
0x62 == "b"
0x6f == "o"
0x62 == "b"

Of course you'll notice the strings are in reverse order. This is because Intel arranges its memory in a format called "little-endian". Basically this means that the "little end" goes first and is really annoying when you're reading hex dumps.

If anyone wants more of an explanation just let me know.

[White_Raven]

thats why gnu has such nice tools for reading dumps.. people just hate doing it by hand..

nice info nick.

[dual]

Thanks for the info, ntheory. That stuff fascinates me.

[ntheory]

No worries. Feel free to bounce more Intel (or Sparc) asm questions off of me anytime guys.