User Tools
session:04
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
session:04 [2019/06/24 15:24] Razvan Deaconescu |
session:04 [2020/07/19 12:49] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | = 0x04. Static Analysis | + | ====== 0x03. Static Analysis |
| - | == Resources | + | ===== Resources |
| - | {{https:// | + | [[https:// |
| - | {{:session: | + | /*[[https:// |
| - | == Setup | + | / |
| + | |||
| + | Get the tasks by cloning [[https:// | ||
| + | |||
| + | ===== Setup ===== | ||
| For the tutorial and tasks below we will use GDB with [[https:// | For the tutorial and tasks below we will use GDB with [[https:// | ||
| Line 15: | Line 19: | ||
| Download [[https:// | Download [[https:// | ||
| - | == Initial | + | ===== Initial |
| After obtaining a malicious binary, it isn't such a good idea to run it without prior inspection of what harm it can do. Therefore, you have to extract as much information as possible about the program without actually executing it. This technique is called //binary static analysis// and can be used to gather a lot of useful details about what the program does and detect potential vulnerabilities. This session describes how a binary executable can be statically reverse engineered by disassembling it, analyzing and annotating the assembly code in order to partially restore its source code. | After obtaining a malicious binary, it isn't such a good idea to run it without prior inspection of what harm it can do. Therefore, you have to extract as much information as possible about the program without actually executing it. This technique is called //binary static analysis// and can be used to gather a lot of useful details about what the program does and detect potential vulnerabilities. This session describes how a binary executable can be statically reverse engineered by disassembling it, analyzing and annotating the assembly code in order to partially restore its source code. | ||
| Line 34: | Line 38: | ||
| This is very useful information because it helps the '' | This is very useful information because it helps the '' | ||
| - | === 01. Disassemble methods | + | ==== 01. Disassemble methods |
| Although machine code and assembly is a one-to-one mapping, binary disassembly is not always an easy task. There are several tools that try to generate accurate assembly code starting from a binary. Based on the method they use, we can narrow down two approaches: //linear sweep// and //recursive traversal// | Although machine code and assembly is a one-to-one mapping, binary disassembly is not always an easy task. There are several tools that try to generate accurate assembly code starting from a binary. Based on the method they use, we can narrow down two approaches: //linear sweep// and //recursive traversal// | ||
| Line 41: | Line 45: | ||
| A detailed description of disassemble methods is presented in [[http:// | A detailed description of disassemble methods is presented in [[http:// | ||
| </ | </ | ||
| - | ==== Linear Sweep | + | === Linear Sweep === |
| Let's strip the debugging symbols and see how '' | Let's strip the debugging symbols and see how '' | ||
| Line 115: | Line 119: | ||
| It is clear now that the //linear sweep// does not always satisfy our requirements, | It is clear now that the //linear sweep// does not always satisfy our requirements, | ||
| - | ==== Recursive Traversal | + | === Recursive Traversal |
| The Recursive Disassembling Algorithm is a technique that combines //linear sweep// with control flow analysis. Basically what it does is to start from the entry point of the program and disassembles instructions in a linear fashion until it finds an instruction that changes the flow of the program (e.g. branches, function calls). At this point it stops disassembling the next instructions and follows the address pointed by the branch instruction, | The Recursive Disassembling Algorithm is a technique that combines //linear sweep// with control flow analysis. Basically what it does is to start from the entry point of the program and disassembles instructions in a linear fashion until it finds an instruction that changes the flow of the program (e.g. branches, function calls). At this point it stops disassembling the next instructions and follows the address pointed by the branch instruction, | ||
| Line 121: | Line 125: | ||
| Now let's see how [[https:// | Now let's see how [[https:// | ||
| - | * Open '' | + | |
| - | * Go to address (Jump -> Jump to address / press G) '' | + | * Go to address (Jump -> Jump to address / press G) '' |
| You should see something like this: | You should see something like this: | ||
| Line 133: | Line 137: | ||
| Although recursive traversal is less susceptible to overlapping instructions, | Although recursive traversal is less susceptible to overlapping instructions, | ||
| - | === 02. Stop, IDA time! | + | ==== 02. Stop, IDA time! ==== |
| <note important> | <note important> | ||
| Line 233: | Line 237: | ||
| * If you want to write comments next to an instruction or a function press '':'' | * If you want to write comments next to an instruction or a function press '':'' | ||
| - | === 03. C++ executables | + | ==== 03. C++ executables |
| Many binaries now come from C++ source code. It is important to understand the concepts and paradigm shift that comes with C++ binaries. | Many binaries now come from C++ source code. It is important to understand the concepts and paradigm shift that comes with C++ binaries. | ||
| Line 300: | Line 304: | ||
| /* | /* | ||
| - | === warm-up: stripped | + | ==== warm-up: stripped |
| Someone has given us a stripped binary called stripped. Let's run it and give it a brief view: | Someone has given us a stripped binary called stripped. Let's run it and give it a brief view: | ||
| Line 329: | Line 333: | ||
| */ | */ | ||
| - | === 04. hyp3rs3rv3r | + | ==== 04. crypto_crackme ==== |
| - | | + | The '' |
| + | |||
| + | | ||
| + | * Next, it looks like the program tries to verify if the secret provided is correct. Where is the secret stored? Is it stored in plain text? Find out what the validation algorithm is. | ||
| + | * Now break it and retrieve the message! | ||
| <note tip> | <note tip> | ||
| - | You can use IDA to reverse engineer this binary. | + | Unfortunately, |
| + | |||
| + | Use the library files in the task archive and run the executable using: | ||
| + | < | ||
| + | LD_LIBRARY_PATH=. ./ | ||
| + | </ | ||
| </ | </ | ||
| <note tip> | <note tip> | ||
| - | In order to exploit the vulnerability in Ubuntu, you should use netcat-traditional. | + | You can break password hashes (including SHA1) on [[https://crackstation.net/|CrackStation]]. |
| </ | </ | ||
| + | ==== 05. broken ==== | ||
| - | === 05. crypto_crackme | + | The '' |
| - | The '' | ||
| - | * Open the binary | + | ==== 06. hyp3rs3rv3r ==== |
| - | * Next, it looks like the program tries to verify if the secret provided is correct. Where is the secret stored? Is it stored in plain text? Find out what the validation algorithm is. | + | |
| - | * Now break it and retrieve the message! | + | |
| <note tip> | <note tip> | ||
| - | Unfortunately, | + | You can use IDA to reverse engineer this binary. |
| </ | </ | ||
| <note tip> | <note tip> | ||
| - | You can break password hashes (including SHA1) on [[https://crackstation.net/|CrackStation]]. | + | In order to exploit the vulnerability in Ubuntu, you should use netcat-traditional. |
| </ | </ | ||
| - | === 06. broken | ||
| - | |||
| - | The '' | ||
| - | |||
| - | === 07. matryoshka | ||
| - | |||
| - | The '' | ||
session/04.1561379053.txt.gz · Last modified: 2019/06/24 15:24 by Razvan Deaconescu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
