MadMouse's latest binary stego challenge spoiler/tutorial

This is the place for ALL of the user submitted challenges. If you create a little challenge/mission/riddle/whatever, post it here.
Forum rules
Do not post missions that you did NOT create without proper citing.

MadMouse's latest binary stego challenge spoiler/tutorial

Post by MadM0use on Mon Jun 01, 2015 4:17 am
([msg=88281]see MadMouse's latest binary stego challenge spoiler/tutorial[/msg])

So recently, not a lot of people have solved my challenges. I work really hard on these, and try to make them as challenging as possible to help my fellow hackers learn more, and explore more creative thought patterns. If no one solves them, it makes me feel bad, not to mention skiddies and noobs start accusing me of making them unsolvable. SO without further to do, here is a walk though to clear my name, and help to educate you guys a little on some of my approach to reverse engineering.

the challenge:
Code: Select all
Subject: I have a secret to tell you...
MIME-Version: 1.0 (mime-construct 1.11)
Content-Type: multipart/mixed; boundary=steelmaker

Content-Transfer-Encoding: base64


Content-Disposition: attachment; filename=secret
Content-Type: application/octet-stream; name=secret
Content-Transfer-Encoding: base64



Ok so here, we have a mime encoded multipart email. The first base64 encoded chunk is the body of the email, and the second bit is an attachment.
lets see what the body of the message says:

Ok, so that is very informative lol. now we know the secret is probably contained in the attachment ;) lol
lets go ahead and decode the attachment to see what we have going on.


Ok, so we have an ELF binary, with a suspicious ELF header...

lets see what's going on with this:

This has the tell tale signs of a custom ELF header, and will be a headache for most reverse engineers. there is no symbol table, no library calls, and no sectons. this is a flat binary. the flags are marked as RWE which is a good sign that the binary contains global self modifying code. The important thing to take note of here is the entry point, (0x8048054) we will need that because without a symbols table, all we have to work with is the binary as it is loaded into memory, in this case the entire file + its header are loaded. lets go ahead and place a breakpoint at the entry point so that it will be loaded into memory, and will thus be able to be disassembled by gdb:

now lets disassemble some of the code from the entry point to see what we have waiting for us :D


Ok, this shouldn't look TOO scary to you, but let me walk you through it line by line here.

first thing upon entry we do a non conditional jmp to 0x804806e, which is then a call to 0x8048056 which is the line directly below the entry point jmp that brought us there, and under that line is a pop instruction, which pops the instruction pointer into esi, this is commonly used in position independent code to cheat relative addressing and get the address to a memory region. lets place a breakpoint under that pop instruction to better visualize this:

As you can see, esi now contains the address to the memory directly beneath the call instruction. take note of this.

now back to the code below the pop instruction. we move the value 0x198 / 408 into ecx, and then there is what looks like a classic key based encryption loop for a count of 408 bytes, and then a jmp to 0x804820b:


it appears that in the decoding loop, the data starts at offset 0x19f / 415 from address 0x8048073, which would make the data's start address 0x8048212.

so a quick symbolic recap:
the key and data are 408 bytes long each. this would imply the following from the loop:
key: start = 0x8048073, end = 0x804820b
data: start = 0x8048212, end = 0x80483aa

ok, so it looks like we can just let the decoder loop do its thing, set a breakpoint right at the jmp instruction after the loop, and then dump the contents of the data memory region to a file like so :D


now lets do a quick hexdump of our dump.bin file:

well, I would go out on a limb here if i were you, and say there is a theme of base64 encoding going on here, so lets try ii:

Success :) now for me, every time I see JFIF like that in a hex dump, I know it is almost certainly a jpeg file I am looking at. however, you should always go ahead and just dump it to a file and run the file command to make sure anyway lol.

and it is in FACT a jpeg :D time to rename that shit and see what it looks like :)

CONGRATULATIONS, the jpeg is the key ;)
const char main[]="\xeb\xfe -> A fully functional program in C";

<@MadMouse> i am forgot what i was doing today but i had motivation and a distinct plan when i woke up stoned right now
User avatar
Experienced User
Experienced User
Posts: 70
Joined: Thu Sep 11, 2014 10:30 pm
Blog: View Blog (0)

Return to User Submitted

Who is online

Users browsing this forum: No registered users and 0 guests