ignore the errors google cloud shell have clang installed in default and well it is blind to which c++ i am using but i can build the files so i am okay to go.
worked to well or basically missed it, modern linux there are two systems PIE (position independent executable) and ASLR (Address Space layout randomization) which randomize the stack where the assembly code for our case is executed which is 0x5a38a5f1e009 but basically the runtime would have usually started from 0x00000000 or lower fixed number.
So basically in assembly the top of the stack is the lowest address and the bottom of the stack is the highest address
𓆣 𝔗̶𝔢̶𝔱̶𝔰̶𝔱̶𝔞̶𝔠̶𝔨̶ 𓆣
So basically in assembly the top of the stack is the lowest address and the bottom of the stack is the highest address
High Addresses (e.g., 0x7FFFFFF.....)
|
|--- [Stack Bottom] (Where the stack began)
| |
| | (Grows Downward as data is pushed)
| v
|--- [Stack Top] (Where %esp / %rsp points - LOWEST address in the stack)
|
| Unallocated Shared Memory Space
|
|--- [Heap Top] (Grows Upward as memory is malloc'd)
| ^
| |
|--- [Heap Bottom]
|
Low Addresses (e.g., 0x0000000.....)
𓆣 𝔗̶𝔢̶𝔱̶𝔰̶𝔱̶𝔞̶𝔠̶𝔨̶ 𓆣
worked to well or basically missed it, modern linux there are two systems PIE (position independent executable) and ASLR (Address Space layout randomization) which randomize the stack where the assembly code for our case is executed which is 0x5a38a5f1e009…
well because of the ASLR randomization i can't exactly get where the exact memory address of the shadow_stub so i used a 4KB alignment
when I call ptrace
the Linux kernel does not instantly freeze the process wherever it stands. Instead, it sends a
signal to the target process. The target process keeps running for a microsecond until it processes that signal, halts, and sends a
back to your supervisor's waitpid() call.
(PTRACE_ATTACH, pid, ...),
the Linux kernel does not instantly freeze the process wherever it stands. Instead, it sends a
SIGSTOP
signal to the target process. The target process keeps running for a microsecond until it processes that signal, halts, and sends a
SIGTRAP
back to your supervisor's waitpid() call.
minute ago the assembly file was running too fast for the tracer to catch now the tracer is too fast for the assembly
okay the address is repeating
003 , 006 and 009, so basically nothing is wrong with the assembly code or the tracer code the thing is the assembly code is running as it should in a loop those three address shows the CPU executing those three instruction and then bacl to start. Because these address falls inside the allowed segment, ZeroShadow thinks everything is fine and it is and keeps monitoring the loop. SO this is what is happening ZeroShadow is firing PTRACE_SINGLESTEP then checking the RIP, it looks at it and confirms it's safe then repeat. so now what my code is missing is as the stack is safe it never hit the error logic and because it's a loop it never exits. so it is just monitoring the heartbeat that never change. SO I will add a heartbeat or escape logic.I messed up in the calculation, i forgot that when the c++ zeroshadow jumps in the way and because it uses ptrace it is going at approximately 10,000 ptrace steps per second. If according to the iteration i submitted which is
0x1FFFFFFFFF WHICH IS ABOUT 137 BILLION iteration, the assembly would have finished about maybe 30 sec, but because of that ptrace it would have took 60 days before it reaches the hijacker.