Following the wake of the previous post, here is Practical Binary Analysislevel 7 CTF walkthrough.As we pay attention to the oracle’s hint, we begin to suspect that this level might be two-staged: $ ./oracle 0fa355cbec64a05f7a5d050e836b1a1f -h Find out what I expect, then trace me for a hint If we try to open the level7 file 1.$ ./lvl7 -bash: ./lvl7: cannot execute binary file: Exec format error $ file lvl7 lvl7: gzip compressed data, last modified: Sat Dec 1 17:30:15 2018, from Unix We can see it’s a gzip format, so we need to decompress it first.
Before yesterdayMatteo Malvica
During the last month I have been busy reading this awesome book by Dennis Andriesse, which quickly became one of my favourite reads on the subject: it does an excellent job on covering the foundation about Linux’s binary analysis and also going above and beyond by providing the reader with all the necessary techniques to be highly proficient and effective when dealing with such alchemical matter. Chapter 5 has the purpose of illustrating all these different tools of the trade which culminates with an intriguing CTF, whose goal is to challenge the reader to put in practice all the skills&tricks gained up to this point.
As I am spending slices of my time refreshing some Malware Analysis theory, I thought was valuable (at least to my future amnesiac self) writing down a simple ‘custom base64 alphabet translator.’ This can/should be extended to support CLI/WebApp i ntegration. So, here is the skeleton: UPDATE: added interactive mode below and also found this great tool which is already doing what I aimed for and much more. import string import base64 # custom encoding function def EncodeCustomBase64(stringToBeEncoded,custom_b64): standard_b64 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=' encoded = base64.
Hot on the heels of the latest post, I have decided to port to linux another lab example from Intermediate x86 class. This time I will talk about the RedPill paper by Joanna Rutkowska. This test is expected to work on single-core CPUs only The main purpose of this test code is to call the SIDT instruction and save its return value inside an array: this value will tell us whether we are running it inside a vm or not.
I was about to finish the Intermediate x86 class from OpenSecTraining, when I thought was worthwhile porting to Linux this interesting exercise about software breakpoints. Whenever we send a software breakpoint on GDB or any other debugger, the debugger swaps the first instruction byte with the double C (0xCC) instruction and keeps track of each and every breakpoint/replaced-instruction via the breakpoint table and thus, leaving the code section of the executable altered.
Something that once was done with heavy and expensive serial cables, can now be achieved in a matter of seconds through virtual machines. I am of course speaking about kernel debugging, what else? Recently I have been following the exceptionally great Intermediate x86 training lead by Xeno Kovah where, in order to keep up with the labs, I had to setup a WinXP-to-WinXP kernel debugging setup. So after a few moments of bewilderment I reached a full working environment with the following steps.
As as a seventh and last assignment of the 32-bit Securitytube Linux Assembly Expert, I have been tasked to create a custom shellcode crypter. The idea behind a crypter, is to encode the shellcode beforehand and decode it at runtime. This process will make the shellcode looks like random values, and thus aiming to bypass AV and IDS detection. When it comes to cryptography, it is a well-known wise approach to not try to reinvent the wheel and instead use what is available and well tested: this is done to prevent any new weakness or bug to be introduced in a a freshly written crypto-algorithm.
As a sixth assignment of the 32-bit Securitytube Linux Assembly Expert, I had to create three different polymorphic version of shellcodes taken from ShellStorm. Here is my selection: Linux x86 execve(“/bin/sh”) - 28 bytes. Linux x86 iptables flush - 43 bytes. Linux x86 ASLR deactivation - 83 bytes. Polymorphism means that we can mutate shellcode, so while keeping the same functionality the signature is different.