From fafd62dd9c374f9ab3075ee0a023d6c68d380e1e Mon Sep 17 00:00:00 2001
From: Navan Chauhan
Date: Wed, 4 Oct 2023 20:05:17 -0600
Subject: finished bomb lab 1-6
---
Content/posts/2023-10-04-bomb-lab.md | 153 +++--
docs/feed.rss | 1045 ++++++++++++++++++---------------
docs/index.html | 4 +-
docs/posts/2023-10-04-bomb-lab.html | 1047 +++++++++++++++++++---------------
docs/posts/index.html | 4 +-
5 files changed, 1265 insertions(+), 988 deletions(-)
diff --git a/Content/posts/2023-10-04-bomb-lab.md b/Content/posts/2023-10-04-bomb-lab.md
index d72322f..c805279 100644
--- a/Content/posts/2023-10-04-bomb-lab.md
+++ b/Content/posts/2023-10-04-bomb-lab.md
@@ -1,23 +1,29 @@
---
date: 2023-10-04 13:12
-description: Introduction, Phases 1-5 of Bomb Lab for CSCI 2400 Lab - 2
+description: Walkthrough of Phases 1-6 of Bomb Lab for CSCI 2400 Computer Systems Lab 2
tags: gdb, reverse-engineering, c++, csci2400, assembly
---
-# Bomb Lab Phases 1-5
+# Bomb Lab
## Introduction
-Lab 2 for CSCI 2400 - Computer Systems.
+Lab 2 for CSCI 2400 @ CU Boulder - Computer Systems
-I like using objdump to disassemble the code and see a broad overview of what is happening.
+> The nefarious Dr. Evil has planted a slew of “binary bombs” on our class machines. A binary bomb is a program that consists of a sequence of phases. Each phase expects you to type a particular string on stdin. If you type the correct string, then the phase is defused and the bomb proceeds to the next phase. Otherwise, the bomb explodes by printing "BOOM!!!" and then terminating. The bomb is defused when every phase has been defused.
+
+> There are too many bombs for us to deal with, so we are giving each student a bomb to defuse. Your mission, which you have no choice but to accept, is to defuse your bomb before the due date. Good luck, and welcome to the bomb squad!
+
+I like using objdump to disassemble the code and get a broad overview of what is happening before I start.
`objdump -d bomb > dis.txt`
+*Note: I am not sure about the history of the bomb lab. I think it started at CMU.*
+
## Phase 1
-```
-jovyan@jupyter-nach6988:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_1' -ex 'break explode_bomb' -ex 'run' ./bomb
+```shell
+joxxxn@jupyter-nxxh6xx8:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_1' -ex 'break explode_bomb' -ex 'run' ./bomb
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
@@ -36,7 +42,7 @@ Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bomb...
Breakpoint 1 at 0x15c7
Breakpoint 2 at 0x1d4a
-Starting program: /home/jovyan/lab2-bomblab-navanchauhan/bombbomb/bomb
+Starting program: /home/joxxxn/lab2-bomblab-navanchauhan/bombbomb/bomb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to my fiendish little bomb. You have 6 phases with
@@ -68,7 +74,7 @@ $1 = 93824992244048
## Phase 2
-```
+```shell
Phase 1 defused. How about the next one?
1 2 3 4 5 6
@@ -106,7 +112,7 @@ End of assembler dump.
(gdb)
```
-```
+```shell
0x00005555555555fd <+18>: cmpl $0x0,(%rsp)
0x0000555555555601 <+22>: js 0x55555555560d
...
@@ -116,7 +122,7 @@ End of assembler dump.
The program first compares if the first number is not 0. If the number is not 0, then the `cmpl` instruction returns a negative value. The `js` instruction stands for jump if sign -> causing a jump to the specified address if the sign bit is set. This would result in the explode_bomb function being called.
-```
+```shell
0x0000555555555603 <+24>: mov %rsp,%rbp
0x0000555555555606 <+27>: mov $0x1,%ebx
```
@@ -129,13 +135,13 @@ By executing `mov %rsp,%rbp` we are setting the base pointer (`%rbp`) to point t
Now, for the second instruction `mov $0x1,%ebx`, we are initalising the `%ebx` register with the value 1. Based on the assembly code, you can see that this is being used as a counter/index for the loop.
-```
+```shell
0x000055555555560b <+32>: jmp 0x555555555620
```
The program now jumps to
-```
+```shell
0x0000555555555620 <+53>: mov %ebx,%eax
0x0000555555555622 <+55>: add 0x0(%rbp),%eax
0x0000555555555625 <+58>: cmp %eax,0x4(%rbp)
@@ -150,7 +156,7 @@ Then, the value at the memory location pointed by `%rbp` is added to the value i
`je 0x555555555614 ` - The program will jump to `phase_2+41` if the previous `cmp` instruction determined the values as equal.
-```
+```shell
0x0000555555555614 <+41>: add $0x1,%ebx
0x0000555555555617 <+44>: add $0x4,%rbp
0x000055555555561b <+48>: cmp $0x6,%ebx
@@ -173,7 +179,7 @@ Thus,
* 6th number = 10 (prev value) + 5 = 15
-```
+```shell
...
Phase 1 defused. How about the next one?
0 1 3 6 10 15
@@ -188,7 +194,7 @@ That's number 2. Keep going!
Let us look at the disassembled code first
-```
+```shell
0000000000001638 :
1638: f3 0f 1e fa endbr64
163c: 48 83 ec 18 sub $0x18,%rsp
@@ -275,7 +281,7 @@ Let us look at the disassembled code first
1797: eb f4 jmp 178d
```
-```
+```shell
...
165b: e8 80 fc ff ff call 12e0 <__isoc99_sscanf@plt>
...
@@ -285,8 +291,8 @@ We can see that `scanf` is being called which means we need to figure out what d
Because I do not want to enter the solutions to phases 1 and 2 again and again, I am goig to pass a file which has these solutions.
-```
-jovyan@jupyter-nach6988:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_3' -ex 'break explode_bomb' -ex 'run' -args ./bomb sol.txt
+```shell
+joxxxn@jupyter-nxxh6xx8:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_3' -ex 'break explode_bomb' -ex 'run' -args ./bomb sol.txt
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
@@ -305,7 +311,7 @@ Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bomb...
Breakpoint 1 at 0x1638
Breakpoint 2 at 0x1d4a
-Starting program: /home/jovyan/lab2-bomblab-navanchauhan/bombbomb/bomb sol.txt
+Starting program: /home/joxxxn/lab2-bomblab-navanchauhan/bombbomb/bomb sol.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to my fiendish little bomb. You have 6 phases with
@@ -348,7 +354,7 @@ Dump of assembler code for function phase_3:
`gdb` has thankfully marked the address which is being passed to `scanf`. We can access the value:
-```
+```shell
(gdb) x/1s 0x5555555571b6
0x5555555571b6: "%d %c %d"
(gdb)
@@ -356,7 +362,7 @@ Dump of assembler code for function phase_3:
BINGO! The program expects an integer, character, and another integer. Onwards.
-```
+```shell
0x0000555555555660 <+40>: cmp $0x2,%eax
0x0000555555555663 <+43>: jle 0x555555555685
...
@@ -367,7 +373,7 @@ The program checks whether `scanf` returns a value <= 2, if it does then it call
*Note: `scanf` returns the number of fields that were succesfully converted and assigned*
-```
+```shell
0x0000555555555665 <+45>: cmpl $0x7,0xc(%rsp)
0x000055555555566a <+50>: ja 0x55555555577d
...
@@ -377,7 +383,7 @@ The program checks whether `scanf` returns a value <= 2, if it does then it call
Similarly, the program checks and ensures the returned value is not > 7.
-```
+```shell
0x0000555555555670 <+56>: mov 0xc(%rsp),%eax
0x0000555555555674 <+60>: lea 0x1b55(%rip),%rdx # 0x5555555571d0
0x000055555555567b <+67>: movslq (%rdx,%rax,4),%rax
@@ -413,7 +419,7 @@ $1 = 3
We can see that this makes us jump to `` (Continue to step through the code by using `ni`)
-```
+```shell
0x00005555555556f2 <+186>: mov $0x64,%eax
0x00005555555556f7 <+191>: cmpl $0x280,0x8(%rsp)
0x00005555555556ff <+199>: je 0x555555555787
@@ -422,7 +428,7 @@ We can see that this makes us jump to `` (Continue to step through
We see that `0x64` (Decimal 100) is being stored in `%eax`. Then, the program compares `0x280` (Decimal 640) with memory address `0x8` bytes above the stack pointer (`%rsp`). If the values are equal, then it jumps to ``, otherwise `explode_bomb` is called.
-```
+```shell
0x0000555555555787 <+335>: cmp %al,0x7(%rsp)
0x000055555555578b <+339>: jne 0x555555555792
0x000055555555578d <+341>: add $0x18,%rsp
@@ -434,7 +440,7 @@ Here, the program is comparing the value of our given character to the value sto
Knowing that the character is stored at an offset of 7 bytes to `%rsp`, we can print and check the value by running:
-```
+```shell
(gdb) x/1cw $rsp+7
c
(gdb) print $al
@@ -443,7 +449,7 @@ $1 = 100
We can simply lookup the [ASCII table](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html), and see that 100 in decimal stands for the character `d`. Let us try this answer:
-```
+```shell
...
That's number 2. Keep going!
3 d 640
@@ -456,8 +462,8 @@ Halfway there!
## Phase 4
-```
-jovyan@jupyter-nach6988:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_4' -ex 'break explode_bomb' -ex 'run' -args ./bomb sol.txt
+```shell
+joxxxn@jupyter-nxxh6xx8:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_4' -ex 'break explode_bomb' -ex 'run' -args ./bomb sol.txt
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
@@ -476,7 +482,7 @@ Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bomb...
Breakpoint 1 at 0x17d3
Breakpoint 2 at 0x1d4a
-Starting program: /home/jovyan/lab2-bomblab-navanchauhan/bombbomb/bomb sol.txt
+Starting program: /home/joxxxn/lab2-bomblab-navanchauhan/bombbomb/bomb sol.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to my fiendish little bomb. You have 6 phases with
@@ -518,28 +524,28 @@ End of assembler dump.
Again, `gdb` has marked the string being passed to `scanf`
-```
+```shell
(gdb) x/1s 0x5555555573a6
0x5555555573a6: "%d %d"
```
Okay, so this time we are supposed to enter 2 numbers.
-```
+```shell
0x00005555555557f6 <+35>: cmp $0x2,%eax
0x00005555555557f9 <+38>: jne 0x555555555802
```
Checks if there were 2 values read from calling `scanf`, if not -> jump to `` which calls ``.
-```
+```shell
0x00005555555557fb <+40>: cmpl $0xe,0xc(%rsp)
0x0000555555555800 <+45>: jbe 0x555555555807
```
Compare `0xe` (14 in Decimal) and value stored at `$rsp` + `0xc` bytes (Decimal 12). If this condition is met (<= 14), jump to ``. If not, then explode bomb.
-```
+```shell
...
0x0000555555555807 <+52>: mov $0xe,%edx
0x000055555555580c <+57>: mov $0x0,%esi
@@ -557,7 +563,7 @@ Compare `0xe` (14 in Decimal) and value stored at `$rsp` + `0xc` bytes (Decimal
Let us look into `func4`
-```
+```shell
(gdb) disas func4
Dump of assembler code for function func4:
0x0000555555555799 <+0>: endbr64
@@ -586,7 +592,7 @@ This looks like a recursive function :( (I hate recursive functions)
Let's annotate the instructions.
-```
+```shell
endbr64
sub $0x8,%rsp // subtract 8 bytes from the stack pointer
mov %edx,%ecx // Move the value in register %edx to %ecx
@@ -633,14 +639,14 @@ Okay, so we know that the number needed to be passed to `func4` is 5. But, what
If we go back to the code for ``, we can see that:
-```
+```shell
0x000055555555581f <+76>: cmpl $0x2,0x8(%rsp)
0x0000555555555824 <+81>: je 0x55555555582b
```
The value at `$rsp+8` should be equal to 2. So, let us try passing `5 2` as our input.
-```
+```shell
...
Phase 1 defused. How about the next one?
That's number 2. Keep going!
@@ -655,7 +661,7 @@ So you got that one. Try this one.
## Phase 5
-```
+```shell
So you got that one. Try this one.
test string
@@ -695,7 +701,7 @@ End of assembler dump.
(gdb)
```
-```
+```shell
...
0x000055555555583c <+12>: call 0x555555555b10
0x0000555555555841 <+17>: cmp $0x6,%eax
@@ -723,7 +729,7 @@ We can also see a similar pattern compared to Phase 2, where we had a loop:
We can check the reference string we need, which `gdb` has marked as `# 0x5555555571bf`, and the lookup table marked as `# 0x5555555571f0 `
-```
+```shell
(gdb) x/s 0x5555555571bf
0x5555555571bf: "bruins"
(gdb) x/s 0x5555555571f0
@@ -761,7 +767,7 @@ s -> g
Let us try out this answer:
-```
+```shell
...
That's number 2. Keep going!
Halfway there!
@@ -778,7 +784,7 @@ Awesome!
## Phase 6
-```
+```shell
Good work! On to the next...
test string
@@ -887,7 +893,7 @@ Again, we see the familiar `read_six_digits` function.
Let us analyse this function in chunks:
-```
+```shell
0x00005555555558bb <+34>: call 0x555555555d97
0x00005555555558c0 <+39>: mov %r14,%r12
0x00005555555558c3 <+42>: mov $0x1,%r15d
@@ -902,7 +908,7 @@ Let us analyse this function in chunks:
2.3. `mov %r14,%r13`: The value is also copied to `%r13`
3. Jump to start of loop:
-```
+```shell
0x0000555555555997 <+254>: mov %r14,%rbp
0x000055555555599a <+257>: mov (%r14),%eax
0x000055555555599d <+260>: sub $0x1,%eax
@@ -920,21 +926,21 @@ Let us analyse this function in chunks:
=> All numbers should be between 1 and 6.
-```
+```shell
0x00005555555559a9 <+272>: cmp $0x5,%r15d
0x00005555555559ad <+276>: jg 0x5555555558f9
```
This checks if the value stored in `%r15` is > 5, if it is then it jumps somewhere else. This validates our assumption that `%r15` is acting as a counter.
-```
+```shell
0x00005555555559b3 <+282>: mov %r15,%rbx
0x00005555555559b6 <+285>: jmp 0x5555555558e8
```
Let us jump to +79
-```
+```shell
0x00005555555558e8 <+79>: mov 0x0(%r13,%rbx,4),%eax
0x00005555555558ed <+84>: cmp %eax,0x0(%rbp)
0x00005555555558f0 <+87>: jne 0x5555555558db
@@ -944,7 +950,7 @@ Let us jump to +79
This section deals with checking if all the numbers in the sequence are unique or not. Thus, we need to ensure out 6 digits are unique
-```
+```shell
0x00005555555558db <+66>: add $0x1,%rbx // Increments by 1
0x00005555555558df <+70>: cmp $0x5,%ebx
0x00005555555558e2 <+73>: jg 0x55555555598f // Jump if > 5 (Loop iterations are complete)
@@ -961,7 +967,7 @@ After stepping through the instructions, we can also see that the numbers are be
Let us try to figure out what ` 0x0000555555555928 <+143>: lea 0x3d01(%rip),%rdx # 0x555555559630 ` is:
-```
+```shell
(gdb) x/30wx 0x555555559630
0x555555559630 : 0x000000d9 0x00000001 0x55559640 0x00005555
0x555555559640 : 0x000003ab 0x00000002 0x55559650 0x00005555
@@ -993,4 +999,49 @@ struct node {
};
```
-Let us convert the values into decimal
+Let us convert the values into decimal:
+
+```
+0x000000d9 -> 217
+0x000003ab -> 939
+0x0000014f -> 335
+0x000000a1 -> 161
+0x000001b3 -> 435
+0x000002da -> 730
+```
+
+**Missing Notes**
+
+To re-arrange this linked list in descending order, we would arrange it as follows:
+
+```
+Node 2 -> Node 6 -> Node 5 -> Node 3 -> Node 1 -> Node 4
+```
+
+Since we also need to apply the transformation: `7 - x`:
+
+```
+(7-2) -> (7-6) -> ... -> (7-4)
+```
+
+Final answer: `5 1 2 4 6 3`
+
+Let us try the answer:
+
+```
+...
+That's number 2. Keep going!
+Halfway there!
+So you got that one. Try this one.
+Good work! On to the next...
+5 1 2 4 6 3
+
+Breakpoint 1, 0x0000555555555899 in phase_6 ()
+(gdb) continue
+Continuing.
+Congratulations! You've defused the bomb!
+Your instructor has been notified and will verify your solution.
+[Inferior 1 (process 1754) exited normally]
+```
+
+But, what about the secret phase?
\ No newline at end of file
diff --git a/docs/feed.rss b/docs/feed.rss
index 17c12c3..b1ead9e 100644
--- a/docs/feed.rss
+++ b/docs/feed.rss
@@ -4,8 +4,8 @@
Navan's ArchiveRare Tips, Tricks and Posts
https://web.navan.dev/en
- Wed, 04 Oct 2023 16:58:57 -0000
- Wed, 04 Oct 2023 16:58:57 -0000
+ Wed, 04 Oct 2023 20:05:03 -0000
+ Wed, 04 Oct 2023 20:05:03 -0000250
@@ -3212,141 +3212,160 @@ logger.info("rdkit-{} installation finished!".format(rdkit.__version__))
https://web.navan.dev/posts/2023-10-04-bomb-lab.html
- Bomb Lab Phases 1-5
+ Bomb Lab
- Introduction, Phases 1-5 of Bomb Lab for CSCI 2400 Lab - 2
+ Walkthrough of Phases 1-6 of Bomb Lab for CSCI 2400 Computer Systems Lab 2
https://web.navan.dev/posts/2023-10-04-bomb-lab.html
Wed, 04 Oct 2023 13:12:00 -0000
- Bomb Lab Phases 1-5
+ Bomb Lab
Introduction
-
Lab 2 for CSCI 2400 - Computer Systems.
+
Lab 2 for CSCI 2400 @ CU Boulder - Computer Systems
-
I like using objdump to disassemble the code and see a broad overview of what is happening.
+
+
The nefarious Dr. Evil has planted a slew of “binary bombs” on our class machines. A binary bomb is a program that consists of a sequence of phases. Each phase expects you to type a particular string on stdin. If you type the correct string, then the phase is defused and the bomb proceeds to the next phase. Otherwise, the bomb explodes by printing "BOOM!!!" and then terminating. The bomb is defused when every phase has been defused.
+
+
+
+
There are too many bombs for us to deal with, so we are giving each student a bomb to defuse. Your mission, which you have no choice but to accept, is to defuse your bomb before the due date. Good luck, and welcome to the bomb squad!
+
+
+
I like using objdump to disassemble the code and get a broad overview of what is happening before I start.
objdump -d bomb > dis.txt
+
Note: I am not sure about the history of the bomb lab. I think it started at CMU.
+
Phase 1
-
jovyan@jupyter-nach6988:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_1' -ex 'break explode_bomb' -ex 'run' ./bomb
-GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
-Copyright (C) 2022 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+
+
joxxxn@jupyter-nxxh6xx8:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_1' -ex 'break explode_bomb' -ex 'run' ./bomb
+GNU gdb (Ubuntu 12.1-0ubuntu1~22.04)12.1
+Copyright (C)2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
-Type "show copying" and "show warranty" for details.
-This GDB was configured as "x86_64-linux-gnu".
-Type "show configuration" for configuration details.
+Type "show copying" and "show warranty"for details.
+This GDB was configured as "x86_64-linux-gnu".
+Type "show configuration"for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word"...
+For help, type"help".
+Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bomb...
-Breakpoint 1 at 0x15c7
-Breakpoint 2 at 0x1d4a
-Starting program: /home/jovyan/lab2-bomblab-navanchauhan/bombbomb/bomb
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
-Welcome to my fiendish little bomb. You have 6 phases with
+Breakpoint 1 at 0x15c7
+Breakpoint 2 at 0x1d4a
+Starting program: /home/joxxxn/lab2-bomblab-navanchauhan/bombbomb/bomb
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+Welcome to my fiendish little bomb. You have 6 phases with
which to blow yourself up. Have a nice day!
-test string
-
-Breakpoint 1, 0x00005555555555c7 in phase_1 ()
-(gdb) dias phase_1
-Undefined command: "dias". Try "help".
-(gdb) disas phase_1
-Dump of assembler code for function phase_1:
-=> 0x00005555555555c7 <+0>: endbr64
- 0x00005555555555cb <+4>: sub $0x8,%rsp
- 0x00005555555555cf <+8>: lea 0x1b7a(%rip),%rsi # 0x555555557150
+test string
+
+Breakpoint 1, 0x00005555555555c7 in phase_1 ()
+(gdb) dias phase_1
+Undefined command: "dias". Try "help".
+(gdb) disas phase_1
+Dump of assembler code forfunction phase_1:
+=> 0x00005555555555c7 <+0>: endbr64
+ 0x00005555555555cb <+4>: sub $0x8,%rsp
+ 0x00005555555555cf <+8>: lea 0x1b7a(%rip),%rsi # 0x555555557150
0x00005555555555d6 <+15>: call 0x555555555b31 <strings_not_equal>
- 0x00005555555555db <+20>: test %eax,%eax
+ 0x00005555555555db <+20>: test %eax,%eax
0x00005555555555dd <+22>: jne 0x5555555555e4 <phase_1+29>
- 0x00005555555555df <+24>: add $0x8,%rsp
+ 0x00005555555555df <+24>: add $0x8,%rsp
0x00005555555555e3 <+28>: ret
0x00005555555555e4 <+29>: call 0x555555555d4a <explode_bomb>
0x00005555555555e9 <+34>: jmp 0x5555555555df <phase_1+24>
End of assembler dump.
-(gdb) print 0x555555557150
-$1 = 93824992244048
-(gdb) x/1s 0x555555557150
-0x555555557150: "Controlling complexity is the essence of computer programming."
-(gdb)
+(gdb) print 0x555555557150
+$1=93824992244048
+(gdb) x/1s 0x555555557150
+0x555555557150: "Controlling complexity is the essence of computer programming."
+(gdb)
+
Phase 2
-
Phase 1 defused. How about the next one?
-1 2 3 4 5 6
+
The program first compares if the first number is not 0. If the number is not 0, then the cmpl instruction returns a negative value. The js instruction stands for jump if sign -> causing a jump to the specified address if the sign bit is set. This would result in the explode_bomb function being called.
The program first compares if the first number is not 0. If the number is not 0, then the cmpl instruction returns a negative value. The js instruction stands for jump if sign -> causing a jump to the specified address if the sign bit is set. This would result in the explode_bomb function being called.
+
%rsp in x86-64 asm, is the stack pointer i.e. it points to the top of the current stack frame. Since the program just read six numbers, the top of the stack (%rsp) contains the address of the first number.
By executing mov %rsp,%rbp we are setting the base pointer (%rbp) to point to this address.
-
Now, for the second instruction mov $0x1,%ebx, we are initalising the %ebx register with the value 1. Based on the assembly code, you can see that this is being used as a counter/index for the loop.
Now, for the second instruction mov $0x1,%ebx, we are initalising the %ebx register with the value 1. Based on the assembly code, you can see that this is being used as a counter/index for the loop.
+
Here, the value from %ebx is copied to the %eax register. For this iteration, the value should be 1.
@@ -3354,17 +3373,18 @@ End of assembler dump.
cmp %eax,0x4(%rbp) - The instruction compares the value in %eax to the value at the memory address %rbp + 4. Since Integers in this context are stored using a word of memory of 4 bytes, this indicates it checks against the second number in the sequence.
-
je 0x555555555614 <phase_2+41> - The program will jump to phase_2+41 if the previous cmp instruction determined the values as equal.
Here, we can see that the program increments %ebx by 1, adds a 4 byte offset to %rbp (the number we will be matching now), and checks if %ebx is equal to 6. If it is, it breaks the loop and jumps to <phase_2+70> succesfully finishing this stage.
@@ -3379,208 +3399,223 @@ End of assembler dump.
6th number = 10 (prev value) + 5 = 15
-
...
-Phase 1 defused. How about the next one?
-0 1 3 6 10 15
+
+
...
+Phase 1 defused. How about the next one?
+01361015
-Breakpoint 1, 0x00005555555555eb in phase_2 ()
-(gdb) continue
+Breakpoint 1, 0x00005555555555eb in phase_2 ()
+(gdb)continue
Continuing.
-That's number 2. Keep going!
+That's number 2. Keep going!
We see that 0x64 (Decimal 100) is being stored in %eax. Then, the program compares 0x280 (Decimal 640) with memory address 0x8 bytes above the stack pointer (%rsp). If the values are equal, then it jumps to <phase_3+335>, otherwise explode_bomb is called.
We see that 0x64 (Decimal 100) is being stored in %eax. Then, the program compares 0x280 (Decimal 640) with memory address 0x8 bytes above the stack pointer (%rsp). If the values are equal, then it jumps to <phase_3+335>, otherwise explode_bomb is called.
+
Compare 0xe (14 in Decimal) and value stored at $rsp + 0xc bytes (Decimal 12). If this condition is met (<= 14), jump to <phase_4+52>. If not, then explode bomb.
This looks like a recursive function :( (I hate recursive functions)
Let's annotate the instructions.
-
endbr64
-sub $0x8,%rsp // subtract 8 bytes from the stack pointer
-mov %edx,%ecx // Move the value in register %edx to %ecx
-sub %esi,%ecx // Subtract the value in %esi from %ecx
-shr %ecx // Right shift the value in %ecx by one bit (dividing the value by 2)
-add %esi,%ecx // Add the value in %esi to %ecx
+
+
endbr64
+sub $0x8,%rsp // subtract 8 bytes from the stack pointer
+mov %edx,%ecx // Move the value in register %edx to %ecx
+sub %esi,%ecx // Subtract the value in %esi from %ecx
+shr %ecx // Right shift the value in %ecx by one bit (dividing the value by 2)
+add %esi,%ecx // Add the value in %esi to %ecx
cmp %edi,%ecx // Compare
ja 0x5555555557b9 <func4+32> // If %ecx > %edi -> jump to instruction at offset +32
-mov $0x0,%eax // Move 0 to %eax
+mov $0x0,%eax // Move 0 to %eax
jb 0x5555555557c5 <func4+44> // If %ecx < %edi -> jump to instruction at offset +44.
-add $0x8,%rsp // add 8 bytes to the stack pointer
-ret // return
-lea -0x1(%rcx),%edx // LEA of $rxc - 1 into $edx
+add $0x8,%rsp // add 8 bytes to the stack pointer
+ret // return
+lea -0x1(%rcx),%edx // LEA of $rxc - 1 into $edx
call 0x555555555799 <func4> // Call itself
-add %eax,%eax // Double the value in %eax
+add %eax,%eax // Double the value in %eax
jmp 0x5555555557b4 <func4+27> // jump to the instruction at offset +27
-lea 0x1(%rcx),%esi
+lea 0x1(%rcx),%esi
call 0x555555555799 <func4>
-lea 0x1(%rax,%rax,1),%eax // LEA of %rax * 2 + 1 into $eax
+lea 0x1(%rax,%rax,1),%eax // LEA of %rax * 2 + 1 into $eax
jmp 0x5555555557b4 <func4+27>
+
We can either try to compute the values by hand, or write a simple script in Python to get the answer.
Okay, so we know that the number needed to be passed to func4 is 5. But, what about the second digit?
-
If we go back to the code for <phase_4>, we can see that:
-
-
0x000055555555581f <+76>: cmpl $0x2,0x8(%rsp)
+
If we go back to the code for <phase_4>, we can see that:
+
+
0x000055555555581f <+76>: cmpl $0x2,0x8(%rsp)
0x0000555555555824 <+81>: je 0x55555555582b <phase_4+88>
-
+
+
The value at $rsp+8 should be equal to 2. So, let us try passing 5 2 as our input.
-
...
-Phase 1 defused. How about the next one?
-That's number 2. Keep going!
+
+
...
+Phase 1 defused. How about the next one?
+That's number 2. Keep going!
Halfway there!
-5 2
+52
-Breakpoint 1, 0x00005555555557d3 in phase_4 ()
-(gdb) continue
+Breakpoint 1, 0x00005555555557d3 in phase_4 ()
+(gdb)continue
Continuing.
So you got that one. Try this one.
First things first, these instructions check to make sure the passed string is of length 6, otherwise explode_bomb is called.
@@ -3914,12 +3974,14 @@ End of assembler dump.
We can check the reference string we need, which gdb has marked as # 0x5555555571bf, and the lookup table marked as # 0x5555555571f0 <array.0>
-
(gdb) x/s 0x5555555571bf
-0x5555555571bf: "bruins"
-(gdb) x/s 0x5555555571f0
-0x5555555571f0 <array.0>: "maduiersnfotvbylSo you think you can stop the bomb with ctrl-c, do you?"
-(gdb)
+
+
(gdb) x/s 0x5555555571bf
+0x5555555571bf: "bruins"
+(gdb) x/s 0x5555555571f0
+0x5555555571f0 <array.0>: "maduiersnfotvbylSo you think you can stop the bomb with ctrl-c, do you?"
+(gdb)
+
To summarize the transformation process:
@@ -3951,115 +4013,118 @@ s -> g
Let us try out this answer:
-
...
-That's number 2. Keep going!
+
+
...
+That's number 2. Keep going!
Halfway there!
So you got that one. Try this one.
mfcdhg
-Breakpoint 1, 0x0000555555555830 in phase_5 ()
-(gdb) continue
+Breakpoint 1, 0x0000555555555830 in phase_5 ()
+(gdb)continue
Continuing.
Good work! On to the next...
@@ -4088,18 +4155,17 @@ End of assembler dump.
2.1. mov %r14,%r12: %r14 should be pointing to the location of the stack where the numbers were read into. This address is copied onto %r12
2.2. mov $0x1,%r15d: The value 1 is moved into %r15 register (probably acting like a counter)
2.3. mov %r14,%r13: The value is also copied to %r13
-
This checks if the value stored in %r15 is > 5, if it is then it jumps somewhere else. This validates our assumption that %r15 is acting as a counter.
+
+
-
0x00005555555559b3 <+282>: mov %r15,%rbx
+
This checks if the value stored in %r15 is > 5, if it is then it jumps somewhere else. This validates our assumption that %r15 is acting as a counter.
+
Since we also need to apply the transformation: 7 - x:
+
+
(7-2) -> (7-6) -> ... -> (7-4)
+
+
+
Final answer: 5 1 2 4 6 3
+
+
Let us try the answer:
+
+
...
+That's number 2. Keep going!
+Halfway there!
+So you got that one. Try this one.
+Good work! On to the next...
+5 1 2 4 6 3
+
+Breakpoint 1, 0x0000555555555899 in phase_6 ()
+(gdb) continue
+Continuing.
+Congratulations! You've defused the bomb!
+Your instructor has been notified and will verify your solution.
+[Inferior 1 (process 1754) exited normally]
+
Lab 2 for CSCI 2400 @ CU Boulder - Computer Systems
-
I like using objdump to disassemble the code and see a broad overview of what is happening.
+
+
The nefarious Dr. Evil has planted a slew of “binary bombs” on our class machines. A binary bomb is a program that consists of a sequence of phases. Each phase expects you to type a particular string on stdin. If you type the correct string, then the phase is defused and the bomb proceeds to the next phase. Otherwise, the bomb explodes by printing "BOOM!!!" and then terminating. The bomb is defused when every phase has been defused.
+
+
+
+
There are too many bombs for us to deal with, so we are giving each student a bomb to defuse. Your mission, which you have no choice but to accept, is to defuse your bomb before the due date. Good luck, and welcome to the bomb squad!
+
+
+
I like using objdump to disassemble the code and get a broad overview of what is happening before I start.
objdump -d bomb > dis.txt
+
Note: I am not sure about the history of the bomb lab. I think it started at CMU.
+
Phase 1
-
jovyan@jupyter-nach6988:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_1' -ex 'break explode_bomb' -ex 'run' ./bomb
-GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
-Copyright (C) 2022 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+
+
joxxxn@jupyter-nxxh6xx8:~/lab2-bomblab-navanchauhan/bombbomb$ gdb -ex 'break phase_1' -ex 'break explode_bomb' -ex 'run' ./bomb
+GNU gdb (Ubuntu 12.1-0ubuntu1~22.04)12.1
+Copyright (C)2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
-Type "show copying" and "show warranty" for details.
-This GDB was configured as "x86_64-linux-gnu".
-Type "show configuration" for configuration details.
+Type "show copying" and "show warranty"for details.
+This GDB was configured as "x86_64-linux-gnu".
+Type "show configuration"for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word"...
+For help, type"help".
+Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bomb...
-Breakpoint 1 at 0x15c7
-Breakpoint 2 at 0x1d4a
-Starting program: /home/jovyan/lab2-bomblab-navanchauhan/bombbomb/bomb
-[Thread debugging using libthread_db enabled]
-Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
-Welcome to my fiendish little bomb. You have 6 phases with
+Breakpoint 1 at 0x15c7
+Breakpoint 2 at 0x1d4a
+Starting program: /home/joxxxn/lab2-bomblab-navanchauhan/bombbomb/bomb
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+Welcome to my fiendish little bomb. You have 6 phases with
which to blow yourself up. Have a nice day!
-test string
-
-Breakpoint 1, 0x00005555555555c7 in phase_1 ()
-(gdb) dias phase_1
-Undefined command: "dias". Try "help".
-(gdb) disas phase_1
-Dump of assembler code for function phase_1:
-=> 0x00005555555555c7 <+0>: endbr64
- 0x00005555555555cb <+4>: sub $0x8,%rsp
- 0x00005555555555cf <+8>: lea 0x1b7a(%rip),%rsi # 0x555555557150
+test string
+
+Breakpoint 1, 0x00005555555555c7 in phase_1 ()
+(gdb) dias phase_1
+Undefined command: "dias". Try "help".
+(gdb) disas phase_1
+Dump of assembler code forfunction phase_1:
+=> 0x00005555555555c7 <+0>: endbr64
+ 0x00005555555555cb <+4>: sub $0x8,%rsp
+ 0x00005555555555cf <+8>: lea 0x1b7a(%rip),%rsi # 0x555555557150
0x00005555555555d6 <+15>: call 0x555555555b31 <strings_not_equal>
- 0x00005555555555db <+20>: test %eax,%eax
+ 0x00005555555555db <+20>: test %eax,%eax
0x00005555555555dd <+22>: jne 0x5555555555e4 <phase_1+29>
- 0x00005555555555df <+24>: add $0x8,%rsp
+ 0x00005555555555df <+24>: add $0x8,%rsp
0x00005555555555e3 <+28>: ret
0x00005555555555e4 <+29>: call 0x555555555d4a <explode_bomb>
0x00005555555555e9 <+34>: jmp 0x5555555555df <phase_1+24>
End of assembler dump.
-(gdb) print 0x555555557150
-$1 = 93824992244048
-(gdb) x/1s 0x555555557150
-0x555555557150: "Controlling complexity is the essence of computer programming."
-(gdb)
+(gdb) print 0x555555557150
+$1=93824992244048
+(gdb) x/1s 0x555555557150
+0x555555557150: "Controlling complexity is the essence of computer programming."
+(gdb)
+
Phase 2
-
Phase 1 defused. How about the next one?
-1 2 3 4 5 6
+
The program first compares if the first number is not 0. If the number is not 0, then the cmpl instruction returns a negative value. The js instruction stands for jump if sign -> causing a jump to the specified address if the sign bit is set. This would result in the explode_bomb function being called.
The program first compares if the first number is not 0. If the number is not 0, then the cmpl instruction returns a negative value. The js instruction stands for jump if sign -> causing a jump to the specified address if the sign bit is set. This would result in the explode_bomb function being called.
+
%rsp in x86-64 asm, is the stack pointer i.e. it points to the top of the current stack frame. Since the program just read six numbers, the top of the stack (%rsp) contains the address of the first number.
By executing mov %rsp,%rbp we are setting the base pointer (%rbp) to point to this address.
-
Now, for the second instruction mov $0x1,%ebx, we are initalising the %ebx register with the value 1. Based on the assembly code, you can see that this is being used as a counter/index for the loop.
Now, for the second instruction mov $0x1,%ebx, we are initalising the %ebx register with the value 1. Based on the assembly code, you can see that this is being used as a counter/index for the loop.
+
Here, the value from %ebx is copied to the %eax register. For this iteration, the value should be 1.
@@ -189,17 +208,18 @@ End of assembler dump.
cmp %eax,0x4(%rbp) - The instruction compares the value in %eax to the value at the memory address %rbp + 4. Since Integers in this context are stored using a word of memory of 4 bytes, this indicates it checks against the second number in the sequence.
-
je 0x555555555614 <phase_2+41> - The program will jump to phase_2+41 if the previous cmp instruction determined the values as equal.
Here, we can see that the program increments %ebx by 1, adds a 4 byte offset to %rbp (the number we will be matching now), and checks if %ebx is equal to 6. If it is, it breaks the loop and jumps to <phase_2+70> succesfully finishing this stage.
@@ -214,208 +234,223 @@ End of assembler dump.
6th number = 10 (prev value) + 5 = 15
-
...
-Phase 1 defused. How about the next one?
-0 1 3 6 10 15
+
+
...
+Phase 1 defused. How about the next one?
+01361015
-Breakpoint 1, 0x00005555555555eb in phase_2 ()
-(gdb) continue
+Breakpoint 1, 0x00005555555555eb in phase_2 ()
+(gdb)continue
Continuing.
-That's number 2. Keep going!
+That's number 2. Keep going!
We see that 0x64 (Decimal 100) is being stored in %eax. Then, the program compares 0x280 (Decimal 640) with memory address 0x8 bytes above the stack pointer (%rsp). If the values are equal, then it jumps to <phase_3+335>, otherwise explode_bomb is called.
We see that 0x64 (Decimal 100) is being stored in %eax. Then, the program compares 0x280 (Decimal 640) with memory address 0x8 bytes above the stack pointer (%rsp). If the values are equal, then it jumps to <phase_3+335>, otherwise explode_bomb is called.
+
Compare 0xe (14 in Decimal) and value stored at $rsp + 0xc bytes (Decimal 12). If this condition is met (<= 14), jump to <phase_4+52>. If not, then explode bomb.
This looks like a recursive function :( (I hate recursive functions)
Let's annotate the instructions.
-
endbr64
-sub $0x8,%rsp // subtract 8 bytes from the stack pointer
-mov %edx,%ecx // Move the value in register %edx to %ecx
-sub %esi,%ecx // Subtract the value in %esi from %ecx
-shr %ecx // Right shift the value in %ecx by one bit (dividing the value by 2)
-add %esi,%ecx // Add the value in %esi to %ecx
+
+
endbr64
+sub $0x8,%rsp // subtract 8 bytes from the stack pointer
+mov %edx,%ecx // Move the value in register %edx to %ecx
+sub %esi,%ecx // Subtract the value in %esi from %ecx
+shr %ecx // Right shift the value in %ecx by one bit (dividing the value by 2)
+add %esi,%ecx // Add the value in %esi to %ecx
cmp %edi,%ecx // Compare
ja 0x5555555557b9 <func4+32> // If %ecx > %edi -> jump to instruction at offset +32
-mov $0x0,%eax // Move 0 to %eax
+mov $0x0,%eax // Move 0 to %eax
jb 0x5555555557c5 <func4+44> // If %ecx < %edi -> jump to instruction at offset +44.
-add $0x8,%rsp // add 8 bytes to the stack pointer
-ret // return
-lea -0x1(%rcx),%edx // LEA of $rxc - 1 into $edx
+add $0x8,%rsp // add 8 bytes to the stack pointer
+ret // return
+lea -0x1(%rcx),%edx // LEA of $rxc - 1 into $edx
call 0x555555555799 <func4> // Call itself
-add %eax,%eax // Double the value in %eax
+add %eax,%eax // Double the value in %eax
jmp 0x5555555557b4 <func4+27> // jump to the instruction at offset +27
-lea 0x1(%rcx),%esi
+lea 0x1(%rcx),%esi
call 0x555555555799 <func4>
-lea 0x1(%rax,%rax,1),%eax // LEA of %rax * 2 + 1 into $eax
+lea 0x1(%rax,%rax,1),%eax // LEA of %rax * 2 + 1 into $eax
jmp 0x5555555557b4 <func4+27>
+
We can either try to compute the values by hand, or write a simple script in Python to get the answer.
Okay, so we know that the number needed to be passed to func4 is 5. But, what about the second digit?
-
If we go back to the code for <phase_4>, we can see that:
-
-
0x000055555555581f <+76>: cmpl $0x2,0x8(%rsp)
+
If we go back to the code for <phase_4>, we can see that:
+
+
0x000055555555581f <+76>: cmpl $0x2,0x8(%rsp)
0x0000555555555824 <+81>: je 0x55555555582b <phase_4+88>
-
+
+
The value at $rsp+8 should be equal to 2. So, let us try passing 5 2 as our input.
-
...
-Phase 1 defused. How about the next one?
-That's number 2. Keep going!
+
+
...
+Phase 1 defused. How about the next one?
+That's number 2. Keep going!
Halfway there!
-5 2
+52
-Breakpoint 1, 0x00005555555557d3 in phase_4 ()
-(gdb) continue
+Breakpoint 1, 0x00005555555557d3 in phase_4 ()
+(gdb)continue
Continuing.
So you got that one. Try this one.
First things first, these instructions check to make sure the passed string is of length 6, otherwise explode_bomb is called.
@@ -749,12 +809,14 @@ End of assembler dump.
We can check the reference string we need, which gdb has marked as # 0x5555555571bf, and the lookup table marked as # 0x5555555571f0 <array.0>
-
(gdb) x/s 0x5555555571bf
-0x5555555571bf: "bruins"
-(gdb) x/s 0x5555555571f0
-0x5555555571f0 <array.0>: "maduiersnfotvbylSo you think you can stop the bomb with ctrl-c, do you?"
-(gdb)
+
+
(gdb) x/s 0x5555555571bf
+0x5555555571bf: "bruins"
+(gdb) x/s 0x5555555571f0
+0x5555555571f0 <array.0>: "maduiersnfotvbylSo you think you can stop the bomb with ctrl-c, do you?"
+(gdb)
+
To summarize the transformation process:
@@ -786,115 +848,118 @@ s -> g
Let us try out this answer:
-
...
-That's number 2. Keep going!
+
+
...
+That's number 2. Keep going!
Halfway there!
So you got that one. Try this one.
mfcdhg
-Breakpoint 1, 0x0000555555555830 in phase_5 ()
-(gdb) continue
+Breakpoint 1, 0x0000555555555830 in phase_5 ()
+(gdb)continue
Continuing.
Good work! On to the next...
@@ -923,18 +990,17 @@ End of assembler dump.
2.1. mov %r14,%r12: %r14 should be pointing to the location of the stack where the numbers were read into. This address is copied onto %r12
2.2. mov $0x1,%r15d: The value 1 is moved into %r15 register (probably acting like a counter)
2.3. mov %r14,%r13: The value is also copied to %r13
-
This checks if the value stored in %r15 is > 5, if it is then it jumps somewhere else. This validates our assumption that %r15 is acting as a counter.
-
-
0x00005555555559b3 <+282>: mov %r15,%rbx
+
This checks if the value stored in %r15 is > 5, if it is then it jumps somewhere else. This validates our assumption that %r15 is acting as a counter.
+
Since we also need to apply the transformation: 7 - x:
+
+
(7-2) -> (7-6) -> ... -> (7-4)
+
+
+
Final answer: 5 1 2 4 6 3
+
+
Let us try the answer:
+
+
...
+That's number 2. Keep going!
+Halfway there!
+So you got that one. Try this one.
+Good work! On to the next...
+5 1 2 4 6 3
+
+Breakpoint 1, 0x0000555555555899 in phase_6 ()
+(gdb) continue
+Continuing.
+Congratulations! You've defused the bomb!
+Your instructor has been notified and will verify your solution.
+[Inferior 1 (process 1754) exited normally]
+
+
+
But, what about the secret phase?
If you have scrolled this far, consider subscribing to my mailing list here. You can subscribe to either a specific type of post you are interested in, or subscribe to everything with the "Everything" list.