diffusing a bomb

80519da:      85 c0                      test   %eax,%eax
80519dc:      74 05                      je     80519e3 <phase_1+0x1f>

The test %eax, %eax tests if the strings are equal, and the je instruction jumps to line 80519e3, that's after the explode_bomb line, right?

>> The test %eax, %eax tests if the strings are equal

Right.

>> and the je instruction jumps to line 80519e3, that's after the explode_bomb line, right?

Yes. Just take a look at the beginning of the line :

>>  80519e3:      c9                         leave  

>>  80519e3:      c9                         leave  

That instruction removes something from the top of the stack? At least that's what I figured from http://en.wikipedia.org/wiki/X86_assembly_language

You were asking whether the jump went to the line after the explode_bomb line, and I answered yes, and backed my answer up by pointing to the address at the beginning of that line. It's exactly the same as the address in the jump instruction.

Note that the leave instruction is there to manage the stack frame. It does the inverse of these two lines :

>>  80519c4:      55                         push   %ebp
>>  80519c5:      89 e5                      mov    %esp,%ebp

which were used to set up the new stack frame for the phase_1 function.

>>  80519c4:      55                         push   %ebp

pushes the function onto the base pointer

>>  80519c5:      89 e5                      mov    %esp,%ebp

moves it onto the stack pointer

So leave acts like a pop on the stack pointer?

>> >>  80519c4:      55                         push   %ebp
>> 
>> pushes the function onto the base pointer

No, it pushes the base pointer onto the stack.


>> >>  80519c5:      89 e5                      mov    %esp,%ebp
>> 
>> moves it onto the stack pointer

Sets the base pointer to the current stack pointer (ebp := esp).


>> So leave acts like a pop on the stack pointer?

It does the inverse, ie. it sets esp to ebp (esp := ebp), and pops the old base pointer off the stack. It's equivalent to :

        mov %ebp, %esp
        pop %ebp

>>Find out what would make that jump work, and that's your solution :)

Wait.. according to that, wouldn't the answer to phase 1 be in these 2 lines?
 80519d7:      83 c4 10                   add    $0x10,%esp
 80519da:      85 c0                      test   %eax,%eax

>> Wait.. according to that, wouldn't the answer to phase 1 be in these 2 lines?

You said this earlier :

>> The test %eax, %eax tests if the strings are equal, and the je instruction jumps to line 80519e3

That was on the right track. Just continue that thought.

so the answer to phase 1 is in the eax register?

Let's try again. What we found up till now is this :

(a) we want the jump to be made, so the bomb doesn't explode
(b) the jump is made if the two strings are equal

What's the conclusion of that ?

conclusion? as in what register are we looking for?

wait... if the strings are equal, the line jumps over the explode_bomb line and then returns that value?

The idea is to avoid that the bomb explodes. How do you do that ? Given that we already know :

>> (a) we want the jump to be made, so the bomb doesn't explode
>> (b) the jump is made if the two strings are equal

we enter the correct string?

sorry... I honestly don't see another answer

wait, are you talking about these 2 lines in the strings_not_equal function??

8051dda:      80 3e 00                   cmpb   $0x0,(%esi)
8051ddd:      74 0d                      je     8051dec <strings_not_equal+0x45>

>> we enter the correct string?

>> sorry... I honestly don't see another answer

Why are you so unsure about it then ? That's the correct answer ;)


>> wait, are you talking about these 2 lines in the strings_not_equal function??

As I said earlier : for now just assume that the strings_not_equal function works as expected. Focus on the phase_1 implementation.

We now now that you have to enter the correct string ... Which one is that ?

How would I go about trying to find that?

>> How would I go about trying to find that?

Check the code ;) Using a debugger will also help you a LOT.

But, remember that the strings_not_equal function compares two strings, and returns whether they're equal or not ? Find out which two strings it compares.

the answer is in these lines right?

 8051dd6:      89 f2                      mov    %esi,%edx
 8051dd8:      89 f9                      mov    %edi,%ecx
 8051dda:      80 3e 00                   cmpb   $0x0,(%esi)
 8051ddd:      74 0d                      je     8051dec <strings_not_equal+0x45>

That's the only jump instruction that isn't jumping to 8051df1.

>> the answer is in these lines right?

As I said a few times already : ignore the strings_not_equal function, but concentrate on the phase_1 function instead.

I just talked to my TA, and she said that the test %eax, %eax line tests if eax is 0 or not.

Apparently the strings_not_equal function returns a 0 if the strings are equal, and 1 if they are not... Is that what you wanted me to figure out?

>> I just talked to my TA, and she said that the test %eax, %eax line tests if eax is 0 or not.
>> 
>> Apparently the strings_not_equal function returns a 0 if the strings are equal, and 1 if they are not...

Didn't you already figure that out here : http:#24180425 ?


>> Is that what you wanted me to figure out?

So, not, I thought you were already a step further ... Namely here : http:#24182221

Actually, I had been thinking that the test %eax, %eax instruction was actually comparing the two strings, since you told me not to bother with the strings_not_equal function.

But after this... I'm not so sure anymore, you've told me several times not to bother with the strings_not_equal function, so then how would I get the result with just the phase_1 function if the test instruction is just testing for 0 or 1?

Am I supposed to check pushl  0x8(%ebp) line before the call to strings_not_equal function?

Is isrveawhobpnutfg the answer? (I used the GDB compiler and put a few breakpoints and that's what it spit out).

>> since you told me not to bother with the strings_not_equal function.

Not to bother with the implementation of the strings_not_equal function, but just assume that it does as advertised (ie. it returns whether the "strings" are "not equal")

The reason I told you to ignore the strings_not_equal implementation, is because it's not relevant to solve phase 1. It's just distracting you from the real solution :)


>> so then how would I get the result with just the phase_1 function if the test instruction is just testing for 0 or 1?

The test instruction tests the return code of the strings_not_equal function. And you know that it'll be zero when the strings are equal, and non-zero otherwise (because that's what the function name tells you).


>> Am I supposed to check pushl  0x8(%ebp) line before the call to strings_not_equal function?

Yes. Find out what's in 0x8(%ebp). If you can't see it from the code, then use a debugger to help you.


>> Is isrveawhobpnutfg the answer? (I used the GDB compiler and put a few breakpoints and that's what it spit out).

If you did that at random, then there's a good chance that it's not the solution.

If you did something specific, then post what you did here, and then I can tell you ...

In any case, if you want to know whether it's right or not, why not just run the code and try it ?

Ok, finally got phase 1 =)

Welcome to my fiendish little bomb. You have 6 phases with
which to blow yourself up. Have a nice day!
Why make trillions when we could make... billions?
Phase 1 defused. How about the next one?

Could you give me a few hints on phase 2? =D

>>The reason I told you to ignore the strings_not_equal implementation, is because it's not relevant to solve phase 1. It's just distracting you from the real solution :)

To be honest, I learned that there was a strings command that gave all the strings used by the file, and that's how I found it... if its not too much trouble, could you please explain how we'd get the answer without looking at strings_not_equal?

>> if its not too much trouble, could you please explain how we'd get the answer without looking at strings_not_equal?

I'm pretty sure you didn't find the answer inside strings_not_equal. Because it's not there ;)

strings_not_equal is just a utility function that works as advertized. The real code you should be looking at is the phase_1 code ... That contains the solution.

I've given a lot of hints already ... Anything more and I'd be giving the solution, so ... You'll just have to think on it a bit.

Let me repeat that we know that the phase_1 function explodes if two given strings are not equal, but it doesn't explode if they are equal. So, all you have to do, is find out which these two strings are, and draw your conclusions from that (ie. make sure that they are equal one way or another).

A debugger will help you A LOT with this, if reading the code is too difficult.

Oh, I did get the answer.

My earlier post:
Welcome to my fiendish little bomb. You have 6 phases with
which to blow yourself up. Have a nice day!
Why make trillions when we could make... billions?
Phase 1 defused. How about the next one?

I just asked about it because I was curious how you did it.

the answer was: Why make trillions when we could make... billions?

It's fine if you don't want to tell me how you worked out phase_1 =), I just need to work on phase 2-5 now...

 80519e5:      55                         push   %ebp
 80519e6:      89 e5                      mov    %esp,%ebp
 80519e8:      53                         push   %ebx
 80519e9:      83 ec 2c                   sub    $0x2c,%esp
 80519ec:      8d 45 d8                   lea    0xffffffd8(%ebp),%eax
 80519ef:      50                         push   %eax
 80519f0:      ff 75 08                   pushl  0x8(%ebp)
 80519f3:      e8 5f 03 00 00             call   8051d57 <read_six_numbers>
 80519f8:      bb 01 00 00 00             mov    $0x1,%ebx
 80519fd:      83 c4 10                   add    $0x10,%esp
 8051a00:      8b 44 9d d4                mov    0xffffffd4(%ebp,%ebx,4),%eax
 8051a04:      83 c0 05                   add    $0x5,%eax
 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)
 8051a0b:      74 05                      je     8051a12 <phase_2+0x2d>
 8051a0d:      e8 9a 07 00 00             call   80521ac <explode_bomb>

We have to avoid the call to <explode_bomb> in this phase too right? so we need to make the jump instruction work... so for this we need to figure out what its comparing in cmp    %eax,0xffffffd8(%ebp,%ebx,4)?

>> Oh, I did get the answer.

I know, but the reason I try to make you find the solution the proper way, is because the next phases get more ane more difficult. And if you haven't figured out the first phase, the next phase will be that much harder, until you reach a point where guesses won't help any more.
But if you, instead, solve each of the phases by understanding how they work, you'll have no problem with the later phases either.

So, in your interest, I'm trying to help you find the solution to phase_1 anyway, even though you already passed it.

If you don't want to take my advice, that's your choice, but you're making your own life harder that way :) Trust me.

Have you used the debugger to step through the phase_1 code, and watch all the variables (more specifically the two that were passed as parameter to the strings_not_equal function) ?

Ok... I'm trying to find the solution your way, but I honestly can't see anything even while stepping through the code with a decompiler...

http://csapp.cs.cmu.edu/public/docs/gdbnotes.txt

crabbe[45] [~/]> gdb bomb
GNU gdb 6.3.50_2004-11-23-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11"...
(gdb) b phase_1
Breakpoint 1 at 0x80519ca
(gdb) run
Starting program: /usa/sudhee/bomb
Welcome to my fiendish little bomb. You have 6 phases with
which to blow yourself up. Have a nice day!
stepi

Breakpoint 1, 0x080519ca in phase_1 ()
(gdb) disas
Dump of assembler code for function phase_1:
0x080519c4 <phase_1+0>: push   %ebp
0x080519c5 <phase_1+1>: mov    %esp,%ebp
0x080519c7 <phase_1+3>: sub    $0x10,%esp
0x080519ca <phase_1+6>: push   $0x8052858
0x080519cf <phase_1+11>:        pushl  0x8(%ebp)
0x080519d2 <phase_1+14>:        call   0x8051da7 <strings_not_equal>
0x080519d7 <phase_1+19>:        add    $0x10,%esp
0x080519da <phase_1+22>:        test   %eax,%eax
0x080519dc <phase_1+24>:        je     0x80519e3 <phase_1+31>
0x080519de <phase_1+26>:        call   0x80521ac <explode_bomb>
0x080519e3 <phase_1+31>:        leave  
0x080519e4 <phase_1+32>:        ret    
End of assembler dump.
(gdb) print/c $ebp
$1 = -40 'Ø'
(gdb) print/c $esp
$2 = -56 'È'
(gdb) print/c $ebp
$3 = -40 'Ø'
(gdb) print/c 0x8052858
$4 = 88 'X'
(gdb) print/c 0x8051da7
$5 = -89 '§'
(gdb) display $ebp
1: $ebp = (void *) 0x8047ad8
(gdb) display 0x8051da7
2: 134552999 = 134552999
(gdb) print/c 0x080519d7
$6 = -41 '×'
(gdb) print/c $eax
$7 = -64 'À'
(gdb) display $eax
3: $eax = 134625472
(gdb) display 0x80519e3
4: 134552035 = 134552035
(gdb) print/c 0x80519e3
$8 = -29 'ã'
(gdb) print $eax
$9 = 134625472
(gdb)

>>Let me repeat that we know that the phase_1 function explodes if two given strings are not equal, but it doesn't explode if they are equal. So, all you have to do, is find out which these two strings are, and draw your conclusions from that (ie. make sure that they are equal one way or another).

How exactly would I try to make sure the strings are equal to each other when there nothing for me to go on? Every time I print a register, it either gives me an obscure character or address, and eventually after following it, the obscure address gives me an obscure character... I was never very good at assembly, since my professor harbored a "teach yourself" attitude, so I might be missing something obvious, if only I knew what...

>> Every time I print a register, it either gives me an obscure character or address,

You have to use the right way of printing ... print/c shows the character at the given address, so it's no wonder that it shows you a character ;)

Try x/s for example to show a string at a given address ... See if you can see the two strings that are passed as argument to the strings_not_equal function.


Btw, don't just show registers etc. at random ... Try to understand what it is that you're looking at.


>> so I might be missing something obvious, if only I knew what...

Do you understand each of the instructions in the disassembly of the phase_1 function ? Can you post the disassembly here, and explain next to each instruction what you think it does ?

0x080519c4 <phase_1+0>: push   %ebp  <---- ebp is the base pointer, it pushes onto the stack?
0x080519c5 <phase_1+1>: mov    %esp,%ebp <--- esp = ebp
0x080519c7 <phase_1+3>: sub    $0x10,%esp <--- exp - 10
0x080519ca <phase_1+6>: push   $0x8052858 <--- push that value onto the stack
0x080519cf <phase_1+11>:        pushl  0x8(%ebp) <--- push the ebp offset by 8 onto the stack
0x080519d2 <phase_1+14>:        call   0x8051da7 <strings_not_equal> <-- call the strings function
0x080519d7 <phase_1+19>:        add    $0x10,%esp <--- esp + 10
0x080519da <phase_1+22>:        test   %eax,%eax <--- tests if eax = 0
0x080519dc <phase_1+24>:        je     0x80519e3 <phase_1+31> <--- if = 0, jump over the explode
0x080519de <phase_1+26>:        call   0x80521ac <explode_bomb> <--- call explode bomb
0x080519e3 <phase_1+31>:        leave  <---- leaves the explode bomb phase?
0x080519e4 <phase_1+32>:        ret    <--- exits phase 1

Ahh... Ok, now I get it... So these 2 lines have the answer?

>> 0x080519ca <phase_1+6>: push   $0x8052858 <--- push that value onto the stack

Right. What value is that ? Use the debugger to find out.

>> 0x080519cf <phase_1+11>:        pushl  0x8(%ebp) <--- push the ebp offset by 8 onto the stack

What value is that ? What can be found at an offset of 8 from the current base pointer ? Use the debugger to find out.

>>Try x/s for example to show a string at a given address ... See if you can see the two strings that are passed as argument to the strings_not_equal function.

The thing is, the gdb decompiler I'm using doesn't seem to have that option:
http://csapp.cs.cmu.edu/public/docs/gdbnotes.txt

Examining code

      print/a $pc      (print the program counter)
      print $sp      (print the stack pointer)
      disas            (display the function around the current line)
      disas ADDR       (display the function around the address)
      disas ADDR1 ADDR2 (display the function between the addresses)

Examining data

      print $eax      (print the contents of %eax)
      print/x $eax      (print the contents of %eax as hex)
      print/a $eax      (print the contents of %eax as an address)
      print/d $eax      (print the contents of %eax as decimal)
      print/t $eax      (print the contents of %eax as binary)
      print/c $eax      (print the contents of %eax as a character)

      print 0x100      (print decimal repr. of hex value)
      print/x 555      (print hex repr. of decimal value)

      x ADDR            (print the contents of ADDR in memory)
      x/NFU ADDR      (print the contents at ADDR in memory:
                        N = number of units to display
                        F = display format
                        U = b (bytes), h (2 bytes), w (4 bytes))

Ok... I take back what I said! I do have a command to make that work.. its this one:

x/NFU ADDR      (print the contents at ADDR in memory:
                        N = number of units to display
                        F = display format
                        U = b (bytes), h (2 bytes), w (4 bytes))

(gdb) x/9sw 0x8052858
0x8052858 <_lib_version+1440>:   "Why make trillions when we could make... billions?"
0x805288b <_lib_version+1491>:   ""
0x805288c <_lib_version+1492>:   "Wow! You've defused the secret stage!"
0x80528b2 <_lib_version+1530>:   ""
0x80528b3 <_lib_version+1531>:   ""
0x80528b4 <_lib_version+1532>:   "So you think you can stop the bomb with ctrl-c, do you?"
0x80528ec <_lib_version+1588>:   "Curses, you've found the secret phase!"
0x8052913 <_lib_version+1627>:   ""
0x8052914 <_lib_version+1628>:   "But finding it and solving it are quite different..."

Thanks a bunch for putting up with my nonsense up until now, and teaching that to me =)

Do you think I can do phase_2 the same way? or Do I need to bother with the read_six_numbers function?

080519e5 <phase_2>:
 80519e5:      55                         push   %ebp <------------------------Pushes ebp onto the stack
 80519e6:      89 e5                      mov    %esp,%ebp <-------------------ebp = esp
 80519e8:      53                         push   %ebx <------------------------Pushes ebx onto the stack
 80519e9:      83 ec 2c                   sub    $0x2c,%esp <------------------esp = esp-44
 80519ec:      8d 45 d8                   lea    0xffffffd8(%ebp),%eax <-------load effective address eax = 0xffffffd8(%ebp)?
 80519ef:      50                         push   %eax <------------------------Pushes eax onto the stack
 80519f0:      ff 75 08                   pushl  0x8(%ebp) <-------------------Push ebp onto the stack offset by 8
 80519f3:      e8 5f 03 00 00             call   8051d57 <read_six_numbers> <--Call the function with the parameters already there
 80519f8:      bb 01 00 00 00             mov    $0x1,%ebx <-------------------ebx = 1
 80519fd:      83 c4 10                   add    $0x10,%esp <------------------esp = esp + 10
 8051a00:      8b 44 9d d4                mov    0xffffffd4(%ebp,%ebx,4),%eax<-eax = 0xffffffd4(%ebp,%ebx,4)
 8051a04:      83 c0 05                   add    $0x5,%eax <-------------------eax = eax + 5
 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)<-compares eax with that huge offset thing
 8051a0b:      74 05                      je     8051a12 <phase_2+0x2d> <------jumps if the compare works out right
 8051a0d:      e8 9a 07 00 00             call   80521ac <explode_bomb> <------explodes bomb, have to avoid this
 8051a12:      43                         inc    %ebx <------------------------increment ebx by 1?
 8051a13:      83 fb 05                   cmp    $0x5,%ebx <-------------------compare ebx to 5
 8051a16:      7e e8                      jle    8051a00 <phase_2+0x1b> <------jump less than phase 2 + the offset 8051A00
 8051a18:      8b 5d fc                   mov    0xfffffffc(%ebp),%ebx <-------ebx = the huge offset of ebp
 8051a1b:      c9                         leave  <-----------------------------breaks down the current stack frame
 8051a1c:      c3                         ret    <-----------------------------It goes back to the calling code

I'm thinking we need to look at the eax, and ebp registers... right?

>> Ok... I take back what I said! I do have a command to make that work.. its this one:

Good :) This is the important line of output :

>> 0x8052858 <_lib_version+1440>:   "Why make trillions when we could make... billions?"

It shows that the address 0x8052858 refers to a string literal "Why make trillions when we could make... billions?".

So, since the bomb will explode unless the user enters that exact string, you have found the solution. Simply enter that string, and you pass phase 1.


>> Do you think I can do phase_2 the same way? or Do I need to bother with the read_six_numbers function?

If you want to, you can always check what the strings_not_equal and read_six_numbers do exactly by looking at the code, and examining it with the debugger.

But you can assume that read_six_numbers does what it says : it reads 6 numbers (entered by the user), and places them in an array.

>>  80519e5:      55                         push   %ebp <------------------------Pushes ebp onto the stack
>>  80519e6:      89 e5                      mov    %esp,%ebp <-------------------ebp = esp
>>  80519e8:      53                         push   %ebx <------------------------Pushes ebx onto the stack

Right. pushing ebx on the stack is necessary because the phase_2 function will modify the contents of the ebx register, and we need to be able to restore the original contents before we return from the function.

>>  80519e9:      83 ec 2c                   sub    $0x2c,%esp <------------------esp = esp-44
>>  80519ec:      8d 45 d8                   lea    0xffffffd8(%ebp),%eax <-------load effective address eax = 0xffffffd8(%ebp)?

load effective address means that the address is calculated, and then stored in the specified register (eax).
Remember that the offset(address) addressing mode means that address+offset is calculated.
Also keep in mind that you can look at 0xffffffd8 as a negative value ...

>>  80519ef:      50                         push   %eax <------------------------Pushes eax onto the stack
>>  80519f0:      ff 75 08                   pushl  0x8(%ebp) <-------------------Push ebp onto the stack offset by 8

Not just ebp, but *(ebp+8), where * is the dereference operation. ie. you calculate the address ebp+8, and then get the value at that address.

>>  80519f3:      e8 5f 03 00 00             call   8051d57 <read_six_numbers> <--Call the function with the parameters already there

Right.

>>  80519f8:      bb 01 00 00 00             mov    $0x1,%ebx <-------------------ebx = 1
>>  80519fd:      83 c4 10                   add    $0x10,%esp <------------------esp = esp + 10
>>  8051a00:      8b 44 9d d4                mov    0xffffffd4(%ebp,%ebx,4),%eax<-eax = 0xffffffd4(%ebp,%ebx,4)

This is again the standard addressing mode offset(base, index, size) that refers to the address (base + offset + (index * size))

>>  8051a04:      83 c0 05                   add    $0x5,%eax <-------------------eax = eax + 5
>>  8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)<-compares eax with that huge offset thing

Again the same addressing mode

>>  8051a0b:      74 05                      je     8051a12 <phase_2+0x2d> <------jumps if the compare works out right

More correctly : jumps if the zero flag is set (which is set if the cmp was equal).

>>  8051a0d:      e8 9a 07 00 00             call   80521ac <explode_bomb> <------explodes bomb, have to avoid this
>>  8051a12:      43                         inc    %ebx <------------------------increment ebx by 1?

Correct.

>>  8051a13:      83 fb 05                   cmp    $0x5,%ebx <-------------------compare ebx to 5
>>  8051a16:      7e e8                      jle    8051a00 <phase_2+0x1b> <------jump less than phase 2 + the offset 8051A00

jle means 'jump if less than or equal'. And it jumps to phase_2 plus the offset 0x1b, which is the address 8051a00.

>>  8051a18:      8b 5d fc                   mov    0xfffffffc(%ebp),%ebx <-------ebx = the huge offset of ebp

again the standard addressing mode. Remember that it's not really a huge offset - just interpret the value as a negative integer value.

>>  8051a1b:      c9                         leave  <-----------------------------breaks down the current stack frame
>>  8051a1c:      c3                         ret    <-----------------------------It goes back to the calling code

Right.

Hey, I was working on phase 2 of the bomb... I was just wondering, this one is nothing like phase 1, is it? I've tried stepping through the code, but call always relies on the values that are already there right?

Because when I disassembled the lines before call, I got:
(gdb) x/6db 0x080519ef
0x80519ef <phase_2+10>: 80      -1      117     8       -24     95
(gdb) x/6db 0x080519f0
0x80519f0 <phase_2+11>: -1      117     8       -24     95      3

I'm a bit unsure about what's going on here... wouldn't call always return false?

>> this one is nothing like phase 1, is it?

It's not the same if that's what you mean. But it's quite similar. It just involves some arithmetic and some looping.


>> Because when I disassembled the lines before call, I got:

What were you trying to show ?
0x080519ef and 0x080519f0 are the addresses where the two push instructions are found.

The integer values you see are simply the instructions themselves, ie. in hex :

        50  ff  75  08  e8  5f

I'm sure you can spot those vaues in the instruction dump here :

>>  80519ef:      50                         push   %eax <------------------------Pushes eax onto the stack
>>  80519f0:      ff 75 08                   pushl  0x8(%ebp) <-------------------Push ebp onto the stack offset by 8


>> I'm a bit unsure about what's going on here... wouldn't call always return false?

Why would it return false ? The two push's simply push the function parameters on the stack, and then the read_six_numbers function is called, which (surprisingly ?) reads six numbers entered by the user.

Looping? There are loops in this?

But.. I've just realized something:

 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)<-compares eax with that huge offset thing
 8051a0b:      74 05                      je     8051a12 <phase_2+0x2d> <------jumps if the compare works out right

Shouldn't the answer be in cmp? in the eax register?

I'm thinking it should be in the cmp instruction, because that's the only place its comparing anything... and it has to jump over the explode_bomb line...?

>> Looping? There are loops in this?

If you haven't spotted them yet, you'll soon do ;)


>> Shouldn't the answer be in cmp? in the eax register?

Not really. Of course, understanding what happens there is part of the solution, but you need to understand the whole call flow to find the solution, not just this cmp instruction.


Try doing this for example : write the assembly instructions in the left column on a piece of paper, and in the right column, write the corresponding C code. Start by "translating" every instruction separately, and then combine different lines of C code to make it easier to read. See if that helps you make sense of what's happening.

Uh... isn't there an easier way than me learning how assembly translates to C? =(

What about the read_six_numbers function? Are there loops in that too?

>> Uh... isn't there an easier way than me learning how assembly translates to C? =(

If you are having trouble understanding what happens exactly, doing this kind of translation might help you. It helped me ;)


>> What about the read_six_numbers function? Are there loops in that too?

Yes, but they're not directly relevant to solving phase_2. As with the strings_not_equal function in phase_1, you can ignore read_six_numbers's implementation for now, and just assume that it works as expected.

int arr[6];
read_six_numbers(input, arr);

if (arr[0] != 1) explode_bomb();

int i = 2;

while (i < 7)
{
if (!(arr[i  1] == i * arr[i  2])) explode_bomb();
i++;
}

Is that right?

>> Is that right?

Did you copy that from a different phase 2 solution ?

Try putting it in two columns, and see if the C code matches the assembler you posted ...

hm? I didn't copy the whole thing, but I did google bits and pieces I didn't understand.

>> but I did google bits and pieces I didn't understand.

Well, to be honest, it shows ;) The C code you posted has nothing to do with the assembler you posted.

You know that they design these challenges, so that they're different every time, don't you ?

Let's get back to what you started in http:#24212480, and my response to that post. See if you can continue from there.

I've heard of it... yeah.

But this thing's due in 4 days, and I still have 4 more phases after phase 2, and I also need to write a shell for my operating systems class in 3 more days, and I'm getting weird errors in that too... lol =(...

A month of school left and there's still more projects they plan to give... unorganized prof's FTL... lol =(

What part of that code isn't like the assembler?

>> What part of that code isn't like the assembler?

Pretty much everything after the first two lines of C ;)


You have two ways of approaching/solving this phase. The first is to understand what the code does, and figure out the answer from that. The second is to run the code in a debugger, and watch what happens that way ... I prefer the first, but maybe you prefer the other approach.

I was that off? lol...

Is there any good website you would suggest? I would like to try it your way.

to learn assembly I mean

Don't you have course notes ?

Here's an overview of the x86 instructions :

        http://www.jegerlehner.ch/intel/IntelCodeTable.pdf

If you need a good book, then I suggest "The Art of Assembly Language", which is freely available :

        http://webster.cs.ucr.edu/AoA/index.html

Other than that, it's about practice, and trying things ...

Is this closer to what the assembly code says?

int arr[6];
read_six_numbers(input, arr);

while(ebx <= 5){
  ebx++;

  eax = 0xffffffd4(%ebp,%ebx,4)

  eax += 5;
  if(eax = 0xffffffd8(%ebp,%ebx,4))
    //phase diffused - jumps over explode bomb
  else
    // explode bomb.
}

I kinda got confused how to translate the jump instructions to c code... I'm pretty sure there aren't any goto's in this code... and I couldn't figure out any variable names, so I didn't bother changing the registers.

>> Don't you have course notes ?

Sadly no... we were expected to already know this stuff from CISC 260... but that professor didn't teach us squat, I'm not really sure how I managed to write those half working assembly programs...

If my translation of that code is right... the answer would be in eax = 0xffffffd8(%ebp,%ebx,4), right?

>> Is this closer to what the assembly code says?

That's closer, yes.

Now, just work out what the 0xffffffd4(%ebp,%ebx,4) and 0xffffffd8(%ebp,%ebx,4)) parts refer to. See http:#24212632 for more info.

The formula to calculate what 0xffffffd4(%ebp,%ebx,4) and 0xffffffd8(%ebp,%ebx,4)) are is:

base + base * int + offset, right?

ebp + ebx * 4 + 0xffffffd4

ebp + ebx * 4 + 0xffffffd8

(what I got using a decompiler)
(gdb) print $ebp
$1 = (void *) 0x8047ad8
(gdb) print $ebx
$2 = 134511408
(gdb) print/x 134511408
$3 = 0x8047b30

I think you said something about the 0xffffffd4 be a negative number? With that... it'd be:

0x8047ad8 + 0x8047b30 * 0xffffffd0

0x8047ad8 + 0x8047b30 * 0xffffffd4

-----------------------------------------------

0x1008F608 * 0xffffffd0 = 0xFFFFFFF2F8B81980

0x1008F608 * 0xffffffd4 = 0xFFFFFFF2B8944160

Is that right?

>> ebp + ebx * 4 + 0xffffffd4
>> 
>> ebp + ebx * 4 + 0xffffffd8

ok, so what does that mean ? What addresses are they ? What values are they referring to ?


>> I think you said something about the 0xffffffd4 be a negative number?

Yes, think two's complement ...

I thought you added the values in the ebp and ebx registers and multiplied them with the result of 4 + 0xffffffd4.

which would be 0xFFFFFFF2F8B81980?

wait... do we add the values in those registers? instead of the addresses?

sorry... i'm a bit dense (or a lot...) when it comes to assembly.. could you give me some hints?

>> I thought you added the values in the ebp and ebx registers and multiplied them with the result of 4 + 0xffffffd4.

The proper operator precedence rules say that multiplication has higher precedence than addition, so ...
Again, I refer to my earlier post http:#24212632 where I already explained how to do the memory address calculation.

>>Remember that the offset(address) addressing mode means that address+offset is calculated.
Also keep in mind that you can look at 0xffffffd8 as a negative value ...

That? But that was referring to >>  80519ec:      8d 45 d8                   lea    0xffffffd8(%ebp),%eax

They gave us a formula in class:
 
off(base, bias, int)

= bias + base * int + offset

0xffffffd4(%ebp,%ebx,4) seemed to fit that formula?

Oh wait...
>>This is again the standard addressing mode offset(base, index, size) that refers to the address (base + offset + (index * size))

my bad.

so it'd be... ebp + 0xffffffd4 + (ebx * 4)?

so it'd be... ebp + 0xffffffd8 + (ebx * 4) = 281666C0

ebp + 0xffffffd4 + (ebx * 4) = 281666C4

?

>> so it'd be... ebp + 0xffffffd4 + (ebx * 4)?

Yes. Now, what's ebp + 0xffffffd4 ? What does it refer to ?

the answer?

the answer ? What do you mean ?

What's ebp ?
What's ebp + 0xffffffd4 ? (remember : two's complement)

According to the decompiler... ebp is 0x8047ad8.

2's complement? apply the 2's complement to both numbers and add them?

1000000001000111110011011000 + 11111111111111111111111111010100

After 2's complement
1000000001000111110011011000

  0111111110111000001100100111
  +                                                    1
=0111111110111000001100101000

11111111111111111111111111010100

  00000000000000000000000000101011
  +                                                            1
=00000000000000000000000000101100

so 0111111110111000001100101000 + 00000000000000000000000000101100?

= 111111110111000001101010100 or 7FB8354??

>> According to the decompiler... ebp is 0x8047ad8.

I'm not talking about the actual address value when you compile/run it on your system.
I'm talking about what it logically refers to ...


>> 2's complement?

What values does 0xffffffd4 represent in two's complement ?
Do you know what two's complement is ?

>>What values does 0xffffffd4 represent in two's complement ?
Do you know what two's complement is ?

Yeah, 2's complement is flipping all the 1's to 0's and 0's to ones and adding a 1, right?

And I'm not exactly sure what ebp is supposed to be... if I had to guess, I'd say its one of the values the user enters? since its the first thing that gets pushed onto the stack?

0xffffffd4 in binary would be 1111 1111 1111 1111 1111 1111 1101 0100

So the 2's complement of that would be.. 0000 0000 0000 0000 0000 0000 0010 1011 + 1
= 0000 0000 0000 0000 0000 0000 0010 1100 ?

no... wait, ebp would be what all the numbers are stored in, right?

>> no... wait, ebp would be what all the numbers are stored in, right?

Since its the first thing that's pushed onto the list... it would be the register where the numbers that are getting compared to user input are stored?

am I right? or wrong?

I'm guessing wrong... but if I am... I don't see another solution =(

Finally found it... ebp is the register that the user enters, right? that's why It gets pushed onto the stack first. And then it gets moved to the stack pointer. And ebx has the values we need to match.

Right?

is this the real c code for the phase?

void phase_2(char *input)
{
    int ii;
    int numbers[6];

    read_six_numbers(input, numbers);

    for (ii = 1; ii < 6; ii++) {
        if (numbers[ii] != numbers[ii-1] + 5)
            explode_bomb();
    }
}

>> Yeah, 2's complement is flipping all the 1's to 0's and 0's to ones and adding a 1, right?

Yes, but what does it mean ? What's the use of two's complement ? And more importantly : what's the value of 0xffffffd4 ?


>> And I'm not exactly sure what ebp is supposed to be..

Just go back to http:#24180719 - ebp is explained there ...

0xffffffd4 = -43?

>> And I'm not exactly sure what ebp is supposed to be..
Yeah, I knew it was getting pushed onto the stack, what I didn't know was what it was supposed to be logically.

I wasn't sure if ebp was the register where the numbers from the user got stored, or whether it was what the numbers entered from the user are compared to.

>> 0xffffffd4 = -43?

-44. So, does that value ring a bell ? Refer back to http:#24212632 if it doesn't.


>> Yeah, I knew it was getting pushed onto the stack, what I didn't know was what it was supposed to be logically.

In http:#24180719, I mentioned several times that ebp is the base pointer. It points to the start of the current stack frame.

>>  80519e9:      83 ec 2c                   sub    $0x2c,%esp <------------------esp = esp-44???

Yes. So, what would ebp-44 be ?

if ebp is -44... then it would be -88?

>> if ebp is -44...

Why would ebp be -44 ????
ebp is the base pointer - it points to the start of the current stack frame.

Oh... so you mean what address would that point to after ebp - 44 is carried out?

It would be the address 0x80519BA?

>> Oh... so you mean what address would that point to after ebp - 44 is carried out?

More accurately, what's the meaning of that address ... What data can be found at that address ?

The value the user's input gets compared to?

>> It would be the address 0x80519BA?

That has no meaning, as it depends on the compiler and the runtime environment.
Specific addresses are only of use in the context of your debugger.

>> The value the user's input gets compared to?

Don't guess. Look at the code.

>>  80519e5:      55                         push   %ebp <------------------------Pushes ebp onto the stack
>>  80519e6:      89 e5                      mov    %esp,%ebp <-------------------ebp = esp
>>  80519e8:      53                         push   %ebx <------------------------Pushes ebx onto the stack

Right. pushing ebx on the stack is necessary because the phase_2 function will modify the contents of the ebx register, and we need to be able to restore the original contents before we return from the function.

>>  80519e9:      83 ec 2c                   sub    $0x2c,%esp <------------------esp = esp-44
>>  80519ec:      8d 45 d8                   lea    0xffffffd8(%ebp),%eax <-------load effective address eax = 0xffffffd8(%ebp)?

load effective address means that the address is calculated, and then stored in the specified register (eax).
Remember that the offset(address) addressing mode means that address+offset is calculated.
Also keep in mind that you can look at 0xffffffd8 as a negative value ...

The value of ebp is stored in eax?

I'm sorry... I don't get what you are trying to say...

If the address of it doesn't matter.. then what does?

Logically... would it be where the user enters the numbers?

>> If the address of it doesn't matter.. then what does?

The actual value of the address doesn't matter - what can be found at that address does matter.


>> Logically... would it be where the user enters the numbers?

Now we're getting somewhere :)

>>  80519ec:      8d 45 d8                   lea    0xffffffd8(%ebp),%eax
>>  80519ef:      50                         push   %eax

pushes the second argument of the read_six_numbers function onto the stack. The second argument of the read_six_numbers function is the address of an array that can hold six integer values.

Wait... if eax is the 2nd argument, what's the first?

And if eax is the 2nd argument of the read_six_numbers function, it has the values the user input gets compared to?

>> Wait... if eax is the 2nd argument, what's the first?

Not eax, but the address that was placed in eax just the line before (using lea).

The first argument of the read_six_numbers function is pushed immediately after that :

>>  80519f0:      ff 75 08                   pushl  0x8(%ebp)

Put that one is of less importance to understand what's happening, so just ignore it for now.


>> And if eax is the 2nd argument of the read_six_numbers function, it has the values the user input gets compared to?

The read_six_numbers function's only purpose is to read six numbers ... It does no comparison. All it needs is an array with room for 6 integer values, and it will fill it with the six values given by the user.

>>The read_six_numbers function's only purpose is to read six numbers ... It does no comparison. All it needs is an array with room for 6 integer values, and it will fill it with the six values given by the user.

if it does no comparison, why call it at all then?

>> if it does no comparison, why call it at all then?

To read six numbers.

so all read_six_numbers does is take the input?

Then the only place the answer can be is in this line.. right?

 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)

>> so all read_six_numbers does is take the input?

Yes. That's what the name of the function says, doesn't it ?

>> Then the only place the answer can be is in this line.. right?

Don't look for the answer. Understand the code first.

You won't find the answer in one line ... You need to understand the whole code to know the answer.

I understand that there's a loop going on between 8051a00 and 8051a16...

 8051a00:      8b 44 9d d4                mov    0xffffffd4(%ebp,%ebx,4),%eax
 8051a04:      83 c0 05                   add    $0x5,%eax
 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)
 8051a0b:      74 05                      je     8051a12 <phase_2+0x2d>
 8051a0d:      e8 9a 07 00 00             call   80521ac <explode_bomb>
 8051a12:      43                         inc    %ebx
 8051a13:      83 fb 05                   cmp    $0x5,%ebx
 8051a16:      7e e8                      jle    8051a00 <phase_2+0x1b>

and there's a compare instruction going on at 8051a07, and if that isn't equal  it calls explode bomb

right?

>> right?

Right.

so the answer must be in either eax or 0xffffffd8(%ebp,%ebx,4)?

>> so the answer must be in either eax or 0xffffffd8(%ebp,%ebx,4)?

Why ? I told you it's not as simple as that.

What's the loop doing ?

if ebx is less than 5, its jumping to 80519a00

then its moving a new address into eax

>> then its moving a new address into eax

Not an address, but a value. Which value ?

then it increments eax by 5, and does  8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4).

if its not equal, it explodes, if it is equal, it moves onto the line where it increments ebx, and does the whole thing again till ebx is greater than 5

?

the... next value that must be compared to the user input?

Yes, so which values are we talking about here ?

>> the... next value that must be compared to the user input?

Which value can be found at address 0xffffffd4(%ebp,%ebx,4) ?

the pre defined values?

the first value that gets compared to the first user input?

>> the pre defined values?

What pre-defined values ? You're guessing again. Think about what address 0xffffffd4(%ebp,%ebx,4) is.

the address of the first element in the array?

>> the address of the first element in the array?

Is it always the first ? What happens on the second iteration of the loop ?

the address of the "next" element in the array?

Ok, continue from there. What's happening with that value ?

that value is getting compared to 0xffffffd8(%ebp,%ebx,4) in this line

 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4).

?

>> that value is getting compared

That exact value ? Or does something happen to it first ?

>> to 0xffffffd8(%ebp,%ebx,4) in this line

And what does 0xffffffd8(%ebp,%ebx,4) refer to ?

if 0xffffffd4(%ebp,%ebx,4)  is referring to the next value in the pre-determined array, I would say 0xffffffd8(%ebp,%ebx,4) is referring to the next value the user entered.

and no... that value is being incremented by 5 before it gets compared to 0xffffffd8(%ebp,%ebx,4)

right?

>> in the pre-determined array

What pre-determined array ?

Do we have to take this from the top ? Didn't we already establish what ebp-44 refers to here : http:#24236534 ?

Ok... so its the other way around? eax holds the values the user enters and 0xffffffd8(%ebp,%ebx,4) holds the addresses of the pre-determined array?

There's no such pre-determined array ... What makes you think there is one ? What are the addresses pointing to ?

none? I thought the numbers the user entered get compared to something...

each of those addresses are pointing to the next element in their array?

so wait.. are you telling me that there is no fixed array... and the password is dependent on what the user types?

>> so wait.. are you telling me that there is no fixed array... and the password is dependent on what the user types?

Something like that, yes.

so how would we find out what the password is if we don't know what it is until the user types in something and gets it wrong..??

Again : just figure out what the code does, and it will all become clear.

So, continue from here : http:#24236920

do I need a decompiler to figure out what values are stored in:

0xffffffd4(ebp, ebx, 4)

and

0xffffffd4(ebp, ebx, 4)?

Or should I just grab a pen and paper and substitute the addresses for ebp and ebx and see what it comes out to?

You can use the debugger to find out, or you can just do the calculation ... Whichever way you prefer. Just keep it relative to ebp, and find out what value the address refers to.

Sorry this is taking so long... I'm trying to juggle 2 projects at once.

8051a00:      8b 44 9d d4                mov    0xffffffd4(%ebp,%ebx,4),%eax
 8051a04:      83 c0 05                   add    $0x5,%eax
 8051a07:      39 44 9d d8                cmp    %eax,0xffffffd8(%ebp,%ebx,4)
 8051a0b:      74 05                      je     8051a12 <phase_2+0x2d>
 8051a0d:      e8 9a 07 00 00             call   80521ac <explode_bomb>
 8051a12:      43                         inc    %ebx
 8051a13:      83 fb 05                   cmp    $0x5,%ebx
 8051a16:      7e e8                      jle    8051a00 <phase_2+0x1b>

8051a00 I got eax = 0x28198141
add $0x5, %eax <---- Do I add it straight to the hex address or the value at that address?

Sorry... I don't wanna try solving a problem the wrong way for 30 mins and realize I did it wrong.. =(

>> I'm trying to juggle 2 projects at once.

I've noticed that. It doesn't work too well, doesn't it ? Concentrating on one project at a time usually works a lot better ;) And faster.


>> 8051a00 I got eax = 0x28198141

How did you get that ?

>> 8051a00 I got eax = 0x28198141

>>How did you get that ?

I got that by using the formula you gave:  

base + off + (ind * size)

I've replaced the ebp and ebx with the addresses they have, and substituted them in, so it became:
0x80519e5 - 44 (0x80519e8 * 4) = 0x28198141

>>I've noticed that. It doesn't work too well, doesn't it ? Concentrating on one project at a time usually works a lot better ;) And faster.

Well... I don't exactly have that luxury... =( my shell project is due in... a little over 12 hours and I'm having problems with the file redirection and pipe... and this little bomb's due in a little over 36 hours...

And just now, my professor decided to punish us a bit more... and gave us another project 2 hours ago that's due in 4 days...

unorganized professors suck... =( /cry

Oh... but, thank you a lot for putting up with my nonsense... I'm not very good at assembly, and add the stress to this, and I lose what little logic I have and keep thinking any new hint is the answer... lol =(.

>> I've replaced the ebp and ebx with the addresses they have,

First of all, ebx has a quite small value ... I'm sure you can spot it in the code.
Second, don't replace ebp ... Keep it in there, or you'll make things harder on yourself. Keep every address on the stack relative to the base pointer - it's easier to compare addresses, and to know which ones are where.


>> and add the stress to this, and I lose what little logic I have and keep thinking any new hint is the answer... lol =(.

So, just get rid of the stress and start thinking clearly then ... ;)

>> and add the stress to this, and I lose what little logic I have and keep thinking any new hint is the answer... lol =(.

So, just get rid of the stress and start thinking clearly then ... ;)

lol... so much easier said than done.

>>First of all, ebx has a quite small value ... I'm sure you can spot it in the code.
Second, don't replace ebp ... Keep it in there, or you'll make things harder on yourself. Keep every address on the stack relative to the base pointer - it's easier to compare addresses, and to know which ones are where.

Wait... I thought you said ebp wasn't -44.

Please... please tell me where I need to look and what to do... I've been banging my head on this for the past 2 days (not like you don't know...), and I've got 4 other phases to bang my head on... that's 4 more "opportunities" to learn this stuff by the day after tomorrow...

please... i'm begging you... don't you think i've earned a freebee after 2 days of banging my head on this? =(

>> Wait... I thought you said ebp wasn't -44.

ebp != ebx

>> don't you think i've earned a freebee after 2 days of banging my head on this? =(

The thing is that all of the information you need has already been repeated several times in this thread. I've given you lots of hints, some of them I've given more than once ... So, you could go over this thread again, and find anything you missed ...

Heh... K, back to the head banging I suppose...