Name : Vol 404 .
Level : very Hard (3zab).
PTS : 1500
Description : we need an advanced memory forensics investigator, we were under attack, and tried to take a memory dump from the machine but the APT corrupted the dump then wiped all the data from our system, hopefully, our new software dumped part of PAGE TABLE ENTRY. we lost our business, the only hope for us is to find this APT G, the only hope is this corrupted memory dump.
Link : challenge link
Files : vol404.tar.gz .
Hash : 8be5f0e0d2f83782277b3df4ef86307e
1 - the main reason for this challenge is to publish this write up.
2 - in a real case of a memory corrupted memory dump, you will need to fix the dump then you can analyse it, if you follow this solution in a real case you will not solve it because the pointers will point to invalid locations but here I edited the memory.
3 - the main technical reason for this challenge is to know how to walk through a memory without volatility, imagine having a case with a new Windows Kernel version that has new structs (thread, process, file, .., etc), will you wait for a volatility update ??
When you extract the tar.gz file you will find 2 files, chall.vmem which is a memory dump, and pagetable.backup which contains part of the page table entry.
Once we have a memory dump we will directly use volatility.
I’m using volatility 2 so I will start by getting the memory suggested profiles.
and it’s windows 7 64 bit .
time to check running processes, using pslist plugin.
but , no thing found voltility couldent follow the KDOM double linked list to find the running processes.
The description said that the dump is corrupted, not encrypted, so if we could do a brute force search for the EPROCESS header bytes regardless of the pages we could find the present process on the system.
so psscan shold give us some output .
As expected, psscan did the mission.
and its clear from the process named FOLLOWMYHEAP that the flag is on its heap .
but where to find the process heap and heaps !
in process Peb structure we can find a pointer to process heap.
and peb is part of EPROCESS struct .
but we can’t use volatility shell to work with the internals because the dump is corrupted, the only way for us is to use a hex-editor.
Walk through internals
we will not start from point 0, because we got important information from psscan which is the physical address of the target process , which is 0xf51fd50
you can start by jumping to this location.
now we are standing on the start byte of the target eprocess struct.
the next step we need to know the kenel verion of this mechine , we can do it in 2 wayes .
the first is to search for windows7 kernel verion.
windows 7 version is 6.1 .
the second way is to use the process id and search for it in the struct, once you find its location you can search for which version PID will be in this position.
you will find that pid location is 0x180 , search for pid with location 0x180 in eprocess struct.
we need to find the location of Peb in version 6.1.
And peb location in process address space is 0x338 .
now we will jump to a Peb location <process_physical address_location+Peb_location> which is 0xf520088
once we jump to the peb location , we will fin the 8 byte pointer.
pointer value is : 0x40212220
Peb pointer points to a virtual memory location so we need to get the physical memory address from this virtual memory.
To calculate the physical memory from the virtual memory in a 64-bit system we need to parse the 64 pointer bits to page directory pointer, page directory, page table, page table entry, physical page offset.
we can do it using a small python script
import sys v_mem = int(sys.argv,16) bin_holder = (bin(v_mem)[2:])[::-1] while len(bin_holder) < 48 : bin_holder += "0" Page_Offset = hex(int(bin_holder[:12][::-1], 2)) PTE = str(int(bin_holder[12:21][::-1], 2)) PT = str(int(bin_holder[21:30][::-1], 2)) PD = str(int(bin_holder[30:39][::-1], 2)) PDP = str(int(bin_holder[39:][::-1], 2)) print("page directory pointer : " + PDP +"\npage directory : " + PD +"\npage table : " + PT + "\npage table entry : " + PTE + "\nphysical page offset : " + Page_Offset )
when we use the peb pointer as an input
we have all information to get the last part of the physical address, we just need to search the pagetable file using the page pointers we got from the script.
now concatenate the number we got from the page table and the physical page offset to get the physical address.
the physical address of peb is 0x2761220
the last thing to do is to get the heap pointer from peb, once the description said process heap so we need only to jump to the heap pointer and no need to parse the heap’s table pointer and go through each one.
NOTE: heap is real memory will point to address in process address space, but here I modified the pointer to point to a physical address so you will not have to vtop again.
so we need to jump to 0x2761250
the last jump will be to 0x2c9220
and not a completely bingooo , you just need to reorganize the flag.
collect the flag bytes and locations from the heap.
ues a scaript get the flag
import base64 flag = 'VP0FQJkdUMMNSF97cMHQCF1T0FlRk9IRFOVQXFZNFDyfCBVL' newfl= '' flo = [5, 24, 34, 15, 13, 23 ,35 ,07 ,32 ,11 ,17 ,03 ,42 ,28 ,48 ,8 ,25, 41, 22, 01, 10, 43, 36, 46, 06 ,30 ,47 ,21, 12 ,31 ,45, 29, 26, 44, 02 ,9 ,37, 39, 16, 33, 18, 04, 38, 20, 14, 27, 19, 40 ] for i in range(len(flo)) : ind = flo.index(i+1) newfl += flag[ind] print(base64.b64decode(newfl))