Browse Source

Fix syntax for gogs

Giulio 4 years ago
parent
commit
294fc5b460
1 changed files with 11 additions and 3 deletions
  1. 11 3
      Readme.md

+ 11 - 3
Readme.md

@@ -20,10 +20,12 @@ Flag: `ptm{L4t3x_1nj3ct10n_1s_c00l}`
 - The profile need to be moved in the right path(/volatility/volatility/plugins/overlays/linux) before start volatility.
 
 - In order to find the correct profile name you can use this command:
+
 ```
 	python vol.py --info | grep -i mint
 ```
 - After that, we have started to analyze dump; in this case the memory dump is made from a Linux system, and the command set from volatility to analyze Linux memory dump is a little bit restricted than Windows memory analysis command-set.
+
 ```
 	root@kali:python vol.py -f /root/Downloads/memory.dmp --profile=LinuxMint173x64 linux_pslist
 	Volatility Foundation Volatility Framework 2.6.1
@@ -39,6 +41,7 @@ Flag: `ptm{L4t3x_1nj3ct10n_1s_c00l}`
 ```
 - Between system processes and other useless stuff, we can find a Thunderbird istance; Thunderbird execution is fairly automated. 
 - We can try to use linux_bash to see the history of used command and find something about Thunderbird.
+
 ```
 	root@kali: python vol.py -f /root/Downloads/memory.dmp --profile=LinuxMint173x64 linux_bash
 	Volatility Foundation Volatility Framework 2.6.1
@@ -56,6 +59,7 @@ Flag: `ptm{L4t3x_1nj3ct10n_1s_c00l}`
 	-- trim --
 ```
 - Intresting, we can find 4 different .eml files opened with Thunderbird. In linux memory dump analysis, we need to find the correct inode value and send it to linux_find_file with -i and -O options to extract every single file.
+
 ```
 	root@kali: python vol.py -f /root/Downloads/memory.dmp --profile=LinuxMint173x64 linux_find_file -F "/home/hackermaster/emails/Your_filename_here.eml"
 	Volatility Foundation Volatility Framework 2.6.1
@@ -181,6 +185,7 @@ Flag: `ptm{5up3r_f457_1n_c4rD_6Am3s}`
     - The program reads some `a`, `b` and `p` from the `./params` file.
     - Reads the flag from file and encrypts it by using the `encrypt` function
     - The encrypt function behave like the following C++/Pseudocode
+
 ```c
 __int64 encrypt(__int64 a1, vector<unsigned int> *message)
 {
@@ -335,6 +340,7 @@ signed __int64 __fastcall sub_400B14(__int64 a1, __int64 a2, __int64 a3)
 - We're gonna trigger the vulnerability a second time to hijack the execution to `system("/bin/sh")`
 
 ### Exploit
+
 ```python
 def brute_payload(proof, pay):
 	def md5(data):
@@ -396,6 +402,7 @@ p.close()
 ```
 
 ### Output (local run)
+
 ```
 $ python exploit.py     
 [INFO]:  Opening binary ./libc.so.6
@@ -490,7 +497,7 @@ The vulnerability lies in the "Edit hash" functionality and is a classic off-by-
 Since the allocated buffers are 0x100 (256) bytes in size, the NULL byte overflow allows to change the 'size' field of an adjacent allocated chunk, moving it from the allocated state (0x101 - 0x1 Present flag) to the free state (0x100).
 P.4 allows to control the last 16 bytes of a buffer, which translates into controlling the prev_size field of a (fake in our case) free buffer.
 
-Through the control of the Present flag + the prev_size field and since we control the contents of the buffers that we load, it is possible to completely create a fake chunk and desynchronize the heap. Once the heap is desynchronized, we can force the allocation of new buffers that overlap with existing ones and allow control of the R/W primitive through P.2. P.2 is used both to infoleak the base address of libc and to overwrite the contents of __free_hook with a onegadget from the provided libc.so, therefore leading to arbitrary code execution.
+Through the control of the Present flag + the prev_size field and since we control the contents of the buffers that we load, it is possible to completely create a fake chunk and desynchronize the heap. Once the heap is desynchronized, we can force the allocation of new buffers that overlap with existing ones and allow control of the R/W primitive through P.2. P.2 is used both to infoleak the base address of libc and to overwrite the contents of `__free_hook` with a onegadget from the provided libc.so, therefore leading to arbitrary code execution.
 
 Let's detail the steps for exploitation:
 
@@ -535,9 +542,9 @@ At this point, all the necessary fake structures are in place.
 
 8) Use P.2 through B1 to read the address in the GOT and extract the libc base
 
-9) Free B5 and reallocate it. In this case, in the payload, store at B5 + 32 the address of __free_hook.
+9) Free B5 and reallocate it. In this case, in the payload, store at B5 + 32 the address of `__free_hook`.
 
-10) Use P.2 through B1 to write to __free_hook the address of the libc one-gadget
+10) Use P.2 through B1 to write to `__free_hook` the address of the libc one-gadget
 
 11) Use P.4 over the dummy buffer allocated at the start to trigger the shell and enjoying the party.
 
@@ -545,6 +552,7 @@ Exploit (dirty python written by a C developer and gloriously uncommented) follo
 
 
 ### Exploit
+
 ```python
 from pwn import *