summaryrefslogtreecommitdiff
path: root/Content/posts/2023-10-04-bomb-lab.md
diff options
context:
space:
mode:
Diffstat (limited to 'Content/posts/2023-10-04-bomb-lab.md')
-rw-r--r--Content/posts/2023-10-04-bomb-lab.md153
1 files changed, 102 insertions, 51 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 <http://gnu.org/licenses/gpl.html>
@@ -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 <phase_2+34>
...
@@ -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 <phase_2+53>
```
The program now jumps to <phase_2+53>
-```
+```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 <phase_2+41>` - 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 <phase_3>:
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 <phase_3+0x155>
```
-```
+```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 <http://gnu.org/licenses/gpl.html>
@@ -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 <phase_3+77>
...
@@ -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 <phase_3+325>
...
@@ -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 `<phase_3+186>` (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 <phase_3+335>
@@ -422,7 +428,7 @@ We can see that this makes us jump to `<phase_3+186>` (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 `<phase_3+335>`, otherwise `explode_bomb` is called.
-```
+```shell
0x0000555555555787 <+335>: cmp %al,0x7(%rsp)
0x000055555555578b <+339>: jne 0x555555555792 <phase_3+346>
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 <http://gnu.org/licenses/gpl.html>
@@ -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 <phase_4+47>
```
Checks if there were 2 values read from calling `scanf`, if not -> jump to `<phase_4+47>` which calls `<explode_bomb>`.
-```
+```shell
0x00005555555557fb <+40>: cmpl $0xe,0xc(%rsp)
0x0000555555555800 <+45>: jbe 0x555555555807 <phase_4+52>
```
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.
-```
+```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 `<phase_4>`, we can see that:
-```
+```shell
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.
-```
+```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 <string_length>
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 <array.0>`
-```
+```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 <read_six_numbers>
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 <phase_6+96>
```
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 <phase_6+79>
```
Let us jump to +79
-```
+```shell
0x00005555555558e8 <+79>: mov 0x0(%r13,%rbx,4),%eax
0x00005555555558ed <+84>: cmp %eax,0x0(%rbp)
0x00005555555558f0 <+87>: jne 0x5555555558db <phase_6+66>
@@ -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 <phase_6+246> // 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 <node1>` is:
-```
+```shell
(gdb) x/30wx 0x555555559630
0x555555559630 <node1>: 0x000000d9 0x00000001 0x55559640 0x00005555
0x555555559640 <node2>: 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