Looking for "binary bombs"
Timo Schneider
I am looking for a "binary bomb" (check [1] for a description). A lot of
universities issue such programs to their assembly-learning students to
give them something funny to train their assembly/reverse engeneering
skills. At least that was the impression I got by using google.
Unfortunately I wasn't able to get such a bomb for my own entertainment.
So if you happen to have a nice linux/elf bomb for me I would be quite
happy to try it.
It would be nice if you could say something about the difficulty level
of your bomb.
[1]: http://www.cs.rpi.edu/~hollingd/comporg.2003/hw/hw3.html
Regards,
Timo
Charles A. Crayne
Timo Schneider <spam...@crayne.org> wrote:
:So if you happen to have a nice linux/elf bomb for me I would be quite
:happy to try it.
I found the source for the one which they use as a demo, compiled it for
linux, and made it available on my web site:
http://www.pacificsites.com/~ccrayne/clax86/demobomb
It only has one phase, but I could add a few more, if you find the
original too easy.
-- Chuck
Frank Kotler
Whew! Way too "hair trigger" for me! Blows up before I even touch it.
SIGFPE at 0x40007999 - div dword [ecx + 0x164] (ecx = 0x40014f90). Is
that supposed to happen???
Best,
Frank
Charles A. Crayne
Frank Kotler <spam...@crayne.org> wrote:
:Whew! Way too "hair trigger" for me! Blows up before I even touch it.
:SIGFPE at 0x40007999 - div dword [ecx + 0x164] (ecx = 0x40014f90). Is
:that supposed to happen???
No. What is supposed to happen is that, when you start it, it prints:
Welcome to the demo bomb. In another moment of weakness, Dr. Evil created
this demo bomb. Phase 1
Then it waits for keyboard input. If you enter the correct input, then it
prints:
You safely defused the bomb. Well done.
Otherwise, it prints:
KABOOM!!!
-- Chuck
Timo Schneider
Hi!
> No. What is supposed to happen is that, when you start it, it prints:
>
> Welcome to the demo bomb. In another moment of weakness, Dr. Evil created
> this demo bomb. Phase 1
>
> Then it waits for keyboard input. If you enter the correct input, then it
> prints:
>
> You safely defused the bomb. Well done.
>
> Otherwise, it prints:
>
> KABOOM!!!
Thank you for your efforts! But I happen to have the same problem as
Frank. I used objdump -d demobomb to get a first clue how it might work.
So I figured out that the actual bomb subroutine is phase_1_of_1. So I
fired up gdb and set a breakpoint on phase_1_of_1. But gdb never reached
this breakpoint, the SIGFPE is thrown before.
Regards,
Timo
Frank Kotler
Apparently not. Library version incompatibility? I thought maybe
corrupted in downloading, but I downloaded it again - same result. I
found what I'm sure is the same source and compiled it myself - works as
expected. Of course, that completely spoils the "secret"!
Even knowing what it "is", I'd have a tough time figuring it out from
the disassembly. There are actually a sheaf of phrases that will "safely
defuse the bomb". And it/they can be entered on one line or two...
Interesting... but tough homework!!!
Best,
Frank
Charles A. Crayne
Frank Kotler <spam...@crayne.org> wrote:
:Library version incompatibility?
Apparently so. I originally compiled and tested it under FC6, where, of
course, it work fine. However, I just tried running it under FC5, and got
the FP exception. So, I recompiled it with FC5, and it seems to run on
both systems. I have replaced the version on my web site, and am
interested to know it that version works for you.
-- Chuck
Charles A. Crayne
Timo Schneider <spam...@crayne.org> wrote:
:But gdb never reached
:this breakpoint, the SIGFPE is thrown before.
Probably in the glibc startup code, since there are no floating point
variables or operations in the user code. In any case, if my replacement
version doesn't work for you, Frank's probably will. Please let us know.
-- Chuck
Frank Kotler
...
>>Otherwise, it prints:
>>
>>KABOOM!!!
(wanted to leave that in, so people won't think we're talking about
malware!)
> Thank you for your efforts! But I happen to have the same problem as
> Frank. I used objdump -d demobomb to get a first clue how it might work.
> So I figured out that the actual bomb subroutine is phase_1_of_1. So I
> fired up gdb and set a breakpoint on phase_1_of_1. But gdb never reached
> this breakpoint, the SIGFPE is thrown before.
That's too bad. I was hoping that it'd work for you. I guess that's why
the original assignment specified *which* machines in the cluster were
to be used!
Odd paradox here. C is supposed to be "portable"... and it is! If we
compile the source, it'll run on Linux, or Windows, or some other CPU
entirely. But dynamic-linked executables are fussy! Static linking would
probably solve it (but would make a *huge* executable!). But a
"non-portable" all-asm solution using sys_calls probably *would* run on
all of our machines. Go figure!
I guess obfuscated source code would be a solution...
Of course, if we were *really* good, we'd be able to figure it out
*without* having to run it (or step through it)...
Best,
Frank
Frank Kotler
Yup! Fooled me at first... I "re-downloaded" it, and same result.
Suspicious - same address, too! Apparently "downloaded" it from a
cached page! Refreshing the page and *then* downloading it got me a
working version. Thanks, Chuck - hope it works for Timo, too!
Best,
Frank
Timo Schneider
> working version. Thanks, Chuck - hope it works for Timo, too!
It does. Thanks again! I had a first look at it and it did not look very
easy.
Regards,
Timo
Timo Schneider
Mm, the fscanf trick is neat. But a short "strings demobomb" will reveal
the pattern (%d %d) very quickly. And as most people will use "1 1" as a
quick check if %eax really becomes 0x2 (at least I did) this was over
very soon. :-(
But hey, at least I can savely go to bed now :-) But this binary bomb
thing is great. Thanks again for the thrill!
Regards,
Timo
Charles A. Crayne
Timo Schneider <spam...@crayne.org> wrote:
:And as most people will use "1 1" as a
:quick check if %eax really becomes 0x2 (at least I did) this was over
:very soon. :-(
You got off to a good start, and did everything the program overtly asked
of you. However, you still need to find the secret challenge.
As Frank mentioned, there are many strings which will defuse the bomb. For
full credit, post the rule which defines the set of such strings.
-- Chuck
João Jerónimo
> Of course, if we were *really* good, we'd be able to figure it out
> *without* having to run it (or step through it)...
I used objdump to disassemble the executable and solve the problem...
JJ
João Jerónimo
> :So if you happen to have a nice linux/elf bomb for me I would be quite
> :happy to try it.
>
> I found the source for the one which they use as a demo, compiled it for
> linux, and made it available on my web site:
> http://www.pacificsites.com/~ccrayne/clax86/demobomb
>
> It only has one phase, but I could add a few more, if you find the
> original too easy.
The program expects two numbers read by fprintf (with format string "%d %d")...
Be X the first number and Y the second, the correct Y depends on the X... X can be any number!
If X is one or less than one, then Y must be one...
If X is two or more, Y is defined recursively with: Y(X) = (X-1)*Y(X-1), with Y(1) = 1
After all, it's a mathmatical recursion!
JJ
spam...@crayne.org
> You got off to a good start, and did everything the program overtly asked
> of you. However, you still need to find the secret challenge.
> As Frank mentioned, there are many strings which will defuse the bomb. For
> full credit, post the rule which defines the set of such strings.
Here's my stab at a general statement of the rule to defuse the bomb:
There must be two input integers provided; call the first input x and
the second y. Then y must be equal to (x-1)!
[Or, more precisely, if x is less than or equal to 1, y must be 1.
Otherwise, y must be equal to the factorial of (x-1) modulo 2^32.
Some interesting overflow conditions: For x==33 and x==34, y must be
equal to -2147483648. For all x > 34, y must be 0.]
GH
João Jerónimo
> Of course, if we were *really* good, we'd be able to figure it out
> *without* having to run it (or step through it)...
I ran it before disassembling, but didn't step...
JJ
João Jerónimo
> It only has one phase, but I could add a few more, if you find the
> original too easy.
No more bombs?!
And more complicated algoritms!
JJ
Charles A. Crayne
João Jerónimo <spam...@crayne.org> wrote:
:No more bombs?!
:And more complicated algoritms!
Yeas, I will do at least one more, with multiple levels, but probably not
until this weekend.
-- Chuck
João Jerónimo
> :No more bombs?!
> :And more complicated algoritms!
>
> Yeas, I will do at least one more, with multiple levels, but probably not
> until this weekend.
OK, tks
JJ
Charles A. Crayne
João Jerónimo <spam...@crayne.org> wrote:
:No more bombs?!
:And more complicated algoritms!
An all new, original, "bomb" is now available from my website:
http://www.pacificsites.com/~ccrayne/clax86/demobomb1
Extra credit for reporting any bugs.
-- Chuck
Charles A. Crayne
"Charles A. Crayne" <ccr...@crayne.org> wrote:
:An all new, original, "bomb" is now available from my website:
:
:http://www.pacificsites.com/~ccrayne/clax86/demobomb1
:
:Extra credit for reporting any bugs.
It has been almost two weeks since I posted this, with no feedback. Is
there a problem with downloading it? Is there a version compatibility
problem? Or is it merely too difficult?
Frank, would you do me the favor of seeing if it will run on your system?
-- Chuck
Frank Kotler
> On Sun, 14 Jan 2007 16:22:34 -0800
> "Charles A. Crayne" <ccr...@crayne.org> wrote:
>
> :An all new, original, "bomb" is now available from my website:
> :
> :http://www.pacificsites.com/~ccrayne/clax86/demobomb1
> :
> :Extra credit for reporting any bugs.
>
> It has been almost two weeks since I posted this, with no feedback. Is
> there a problem with downloading it? Is there a version compatibility
> problem? Or is it merely too difficult?
To be honest, after downloading it, it kinda slipped my mind. (I've got
a pretty slippery mind!)
> Frank, would you do me the favor of seeing if it will run on your system?
Okay... "access denied"... "chmod +x demobomb1"... Yup, goes "KABOOM".
This one looks "different". No "C cruft", looks like all "int 80h"...
which paradoxically should make it *more* portable - no lib version
dependencies... Less "label" information in it (stripped, or maybe
that's a Fasm vs Nasm/ld difference)... but everything's "right there",
no mysterious "call (.plt + ????)"...
I'll get back to ya on this. Thanks for reminding me I had a toy to play
with!
Best,
Frank
Timo Schneider
> On Sun, 14 Jan 2007 16:22:34 -0800
> "Charles A. Crayne" <ccr...@crayne.org> wrote:
>
>:An all new, original, "bomb" is now available from my website:
>:
>:http://www.pacificsites.com/~ccrayne/clax86/demobomb1
>:
>:Extra credit for reporting any bugs.
>
> It has been almost two weeks since I posted this, with no feedback. Is
> there a problem with downloading it? Is there a version compatibility
> problem? Or is it merely too difficult?
It runs great, I just do not have the time to look at it any closer for
now.
Regards,
Timo
Charles A. Crayne
Frank Kotler <spam...@crayne.org> wrote:
:This one looks "different".
Thanks for the reply Frank (and Timo). Yes, following your suggestion, I
wrote this one in Fasm, and linked it with ld. I did not strip the
label info, but Fasm only generates references for global symbols. Nor did
I make any attempt to obfuscate the code, but I did make sure that nobody
is going to stumble into the solution by trial and error.
I look forward to your next report.
-- Chuck
Frank Kotler
Chicken! :)
I think I've figured it out. Yeah, it's too difficult! That level 2 is
*rotten* (pun). Tough to type right, even when you've figured it out.
Levels 1 and 3 aren't too bad. Is the third buffer a "red herring", or
is it "just there"?
I suppose there's no sense posting the "solution" - the only people
interested are probably the people working on it. If any. You still with
us, JJ?
Best,
Frank
Charles A. Crayne
Frank Kotler <spam...@crayne.org> wrote:
:Is the third buffer a "red herring", or
:is it "just there"?
I blush to admit that, although I originally had something in mind for it,
when I ended up not needing it, I forgot to go back and take it out.
-- Chuck
Robert Redelmeier
> This one looks "different". No "C cruft", looks like all "int
> 80h"... which paradoxically should make it *more* portable -
> no lib version dependencies... Less "label" information in it
> (stripped, or maybe that's a Fasm vs Nasm/ld difference)... but
> everything's "right there", no mysterious "call (.plt + ????)"...
Yes. And I've written code loading both stack & registers
so that both Linux FASTCALL and *BSD LIBC-CALL int 80h
conventions would run without requiring non-native support.
-- Robert