Hey, this is a great series! Couple of things, 1. I didn't quiet understand the "xff/xe4" format. 2. Say I'm developing an exploit for a service, how do I find a module that works for my service? Does mona work for all services? 3. Is it a pre-requisite for all protections to be FALSE? What if a couple were TRUE, would the exploit still work with this approach?
To provide a better understanding, the pattern "\xff\xe4" represents the x86 assembly instruction for "JMP ESP". The command you provided instructs Immunity Debugger to search for occurrences of this specific assembly instruction within the memory space of the "essfunc.dll" module.(Chatgpt)
Awesome tutorial! But I encounter an issue. I have used python3 instead and I used the following lines since in Python3 it requires me to encode before sending: payload = "TRUN /.:/" + shellcode s.send(payload.encode()) However after running the Python script, the EIP is not 625011AF but 5011AFC2. Why's that?
Hi! I got the same output (also python3), no issue on previous parts but 'C2' was somehow being inserted into the shellcode. My host is a Win7 professional 64bit, patched. After some fuzzing (IE. offset*1996 + \x84\xaf\x11\x50\x62\xaf\x11\x50\x62\x84) it manages to get 625011AF into EBP, but again reproduced 5011AFC2 for the EIP... tried a mixture of chars, no idea why but it's sort of freaky :)
Hello, after watching the complete buffer overflow series,this is the only video that i didn't get. Like i don't even know why there was jump to ESP while we are already on EIP after 2003 byte. So why didn't we write our shellcode just after "A * 2003" ? Why do we have to jump to ESP? And where our shellcode is executing , is it on EIP or ESP?
The ESP we found is a specific return address that has the JMP register. That register will jump to our malicious shellcode. The EIP is a pointer. We pointed to a jump. We jumped to the malicious shellcode.
re-watch the introduction bruh, the ESP doesn't get filled with A's, it just contains the address of the next instruction or function call and the malicious shellcode is a function call that changes the execution flow of the software and gives us a shell. Hopefully, this will help
NOP spraying will steps in. By doing that you can achieve bypassing the ASLR protection. But it's not that easy to find the EIP. You'll make it by getting your hands dirty on that after a while. You can also disable ASLR while performing dynamic analysis.
If after running the python script, the EIP is showing "5011AFC2" instead of "625011AF", try changing the last part of your script as follows "except Exception as e: print("Error: %s" % str(e)) sys.exit()"
Hi. Really awesome tutorial. Could you please help me as whenever I set EIP address to the address of JMP ESP, the EIP content differs from the mentioned 0x625011af. I tried both big and little endian
@@chandureddy7130 i found out it only point to 0x625011af if i set the break point and check where EIP points. not sure why if i dont set the break point it cant return 625011af
Hi mate, thank you again for the wonderful tutorial...it is indeed a eye opener. Please, what can make my immunity debugger not find anything when I run "!mona find -s "\xff\xef" -m essfunc.dll" I only get "Found a total of 0 pointers" and nothing is listed...from the start to this point I never had any issues...all running smoothly till this point...
Hi, That's so weird. I've never seen 0 found before. My first suggestion would be to try and reboot, load everything up again, and retry it. The Mona Modules command showed you essfunc.dll though? Let me know if you figure it out!
yeah...solved now, in my case there are no addresses in the executable which can be used to redirect control to ESP. So it returned; "Found a total of 0 pointers" then I tried; "!mona.py jmp -r ESP -m essfunc.dll" and got the return address.
@@morounodebode I was in the same boat; couldn't really read the video, turns out I was typing 'f' at the end just as you were, if you change that to a 4 as is reported in NASM it will find the pointers.
Have a hunch this video is so outdated due to the change in Python from 2.7 to 3.x that the mona module no longer works. Really hard to see this video and what you are doing with the tiny fonts on a tiny display and low resolution video from youtube.
It's 8 months later, but I had the same issue, turns out you need to use/install the 32 bit x86 version of python in addition to the 64 bit x86_64 version. You can have multiple python versions installed using conda or miniconda (if your using for just setting enviroments i suggest miniconda), I have about 4 at this point. (latest python 3 for 32 and 64 bit and also latest python 2 for 32 and 64 bit)
I hope you enjoyed this video! If so, please consider dropping a like and subscribing.
Anyway, if someone can't read the command line because of the TH-cam timeline:
!mona find -s "\xff\xe4" -m essfunc.dll
Thank you!
LOL i knew someone was nice enough to post that in the comments, Thank you
thnx
@SimonsRadner you are welcome
Hey, this is a great series! Couple of things,
1. I didn't quiet understand the "xff/xe4" format.
2. Say I'm developing an exploit for a service, how do I find a module that works for my service? Does mona work for all services?
3. Is it a pre-requisite for all protections to be FALSE? What if a couple were TRUE, would the exploit still work with this approach?
To provide a better understanding, the pattern "\xff\xe4" represents the x86 assembly instruction for "JMP ESP". The command you provided instructs Immunity Debugger to search for occurrences of this specific assembly instruction within the memory space of the "essfunc.dll" module.(Chatgpt)
Awesome tutorial! But I encounter an issue.
I have used python3 instead and I used the following lines since in Python3 it requires me to encode before sending:
payload = "TRUN /.:/" + shellcode
s.send(payload.encode())
However after running the Python script, the EIP is not 625011AF but 5011AFC2.
Why's that?
What version of Windows are you attacking? Did you try to proceed with the return address anyways? It might work.
Hi! I got the same output (also python3), no issue on previous parts but 'C2' was somehow being inserted into the shellcode. My host is a Win7 professional 64bit, patched. After some fuzzing (IE. offset*1996 + \x84\xaf\x11\x50\x62\xaf\x11\x50\x62\x84) it manages to get 625011AF into EBP, but again reproduced 5011AFC2 for the EIP... tried a mixture of chars, no idea why but it's sort of freaky :)
@@Houses0nfirehey were u able to figure that out?
Hey did you figure it out?
Bro anyone got this??
Amazing!
Hello, after watching the complete buffer overflow series,this is the only video that i didn't get. Like i don't even know why there was jump to ESP while we are already on EIP after 2003 byte. So why didn't we write our shellcode just after "A * 2003" ?
Why do we have to jump to ESP?
And where our shellcode is executing , is it on EIP or ESP?
The ESP we found is a specific return address that has the JMP register. That register will jump to our malicious shellcode. The EIP is a pointer. We pointed to a jump. We jumped to the malicious shellcode.
re-watch the introduction bruh, the ESP doesn't get filled with A's, it just contains the address of the next instruction or function call
and the malicious shellcode is a function call that changes the execution flow of the software and gives us a shell.
Hopefully, this will help
I think vulnserver has been upgradeed this method not working with me anymore .
that's great can you make videos of each web application attack according to the OWASP top 10?
DUDE U R AWESOME
Thank you
Mine didn't work (EIP is not that return address, it's something else)
I wanna ask that what if we have ASLR true in the module, how we handle it and move further??
NOP spraying will steps in. By doing that you can achieve bypassing the ASLR protection. But it's not that easy to find the EIP. You'll make it by getting your hands dirty on that after a while. You can also disable ASLR while performing dynamic analysis.
If after running the python script, the EIP is showing "5011AFC2" instead of "625011AF", try changing the last part of your script as follows
"except Exception as e:
print("Error: %s" % str(e))
sys.exit()"
#!/usr/bin/python3
import sys
import socket
# Confirmed offset
offset = 2003
# Address to overwrite EIP (in reverse order for little-endian)
eip = "\xaf\x11\x50\x62"
# Construct the payload
junk = "A" * offset
nop_sled = "\x90" * 16 # Optional NOP sled for padding
padding = "C" * (2600 - offset - len(eip) - len(nop_sled))
buffer = junk + eip + nop_sled + padding
# Print diagnostic information
print("Offset:", offset)
print("EIP Overwrite (hex):", eip.encode('latin-1').hex())
print("Buffer Length:", len(buffer))
print("Buffer Content (hex):", buffer.encode('latin-1').hex())
# Ensure the buffer is exactly 2600 bytes
if len(buffer) != 2600:
print("Warning: Buffer length is not 2600 bytes")
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('192.168..change', 9999))
s.send(('TRUN /.:/' + buffer).encode('latin-1'))
s.close()
except Exception as e:
print("Exception: ", e)
sys.stdout.flush()
It's still showing the same thing
The !mona modules does not work on immunity debugger
love you cyber mentor
Can mon.py script be ran during the oscp?
yep
Hi. Really awesome tutorial. Could you please help me as whenever I set EIP address to the address of JMP ESP, the EIP content differs from the mentioned 0x625011af. I tried both big and little endian
Bro you got this? Please help me
@@chandureddy7130 i found out it only point to 0x625011af if i set the break point and check where EIP points. not sure why if i dont set the break point it cant return 625011af
Did you get it?@@chandureddy7130
Hi mate, thank you again for the wonderful tutorial...it is indeed a eye opener.
Please, what can make my immunity debugger not find anything when I run "!mona find -s "\xff\xef" -m essfunc.dll" I only get "Found a total of 0 pointers" and nothing is listed...from the start to this point I never had any issues...all running smoothly till this point...
Hi,
That's so weird. I've never seen 0 found before. My first suggestion would be to try and reboot, load everything up again, and retry it. The Mona Modules command showed you essfunc.dll though?
Let me know if you figure it out!
@@TCMSecurityAcademy sure...I will let you know... shortly
yeah...solved now, in my case there are no addresses in the executable which can be used to redirect control to ESP. So it returned; "Found a total of 0 pointers" then I tried; "!mona.py jmp -r ESP -m essfunc.dll"
and got the return address.
@@morounodebode I was in the same boat; couldn't really read the video, turns out I was typing 'f' at the end just as you were, if you change that to a 4 as is reported in NASM it will find the pointers.
Have a hunch this video is so outdated due to the change in Python from 2.7 to 3.x that the mona module no longer works. Really hard to see this video and what you are doing with the tiny fonts on a tiny display and low resolution video from youtube.
Are you using VGA Phone with 2G network? ;d
It's 8 months later, but I had the same issue, turns out you need to use/install the 32 bit x86 version of python in addition to the 64 bit x86_64 version. You can have multiple python versions installed using conda or miniconda (if your using for just setting enviroments i suggest miniconda), I have about 4 at this point. (latest python 3 for 32 and 64 bit and also latest python 2 for 32 and 64 bit)