Everytime I use the adblocker on the whole internet, but when you make these awesome videos, I watch them with my adblocker off. Keep up the good work (y)
That was quite a bit of efford. If you have troubles, try to: - restart immunity debugger and vulnsever.exe (important: run as administrator!) - don't forget to start the immunity debugger - turn off the firewall of windows 10 - it can sometimes take a few seconds to get a crash - be very careful about the correct python script. I think that's the most critical point if you stuck --> whitespaces does matter in python. I had forgotten the space between "TRUN" and "/.:/" - the functions "s.send" and "s.connect" are needing double brackets ((...)) So nice explained
Depending on which version of python you're running, the script for 1.py might not work. You can set the script to use python 2 (which will work) by replacing the first line of code with “#!/usr/bin/python2”. This fixed an issue I had with the command line throwing a fit about print syntax (it wanted an extra set of parentheses that aren't in the code, and if you add them it breaks the code).
this comment was a life savor. I had no idea how i was writing that script wrong. Could u please explain why i need to use python 2 instead of python? is it cause the creator and I are on different versions of python?? and is it python from the immunity debugger, or kali linux python that its referring to?
Any explanation on how you arrive at "TRUN /.:/" for the prefix to the buffer string? A typical ncat session only requires "TRUN [string]" so what are those additional characters for?
I did some captures with Wireshark and compared generic_send_tcp to manual attempts with netcat. As you pointed out, netcat captures only showed "TRUN [string]" as expected. What I found was that the "/.:/" string was first observed in the second fuzzing attempt by generic_send_tcp and seems to be nothing special other than it happened to be included in the first of the attempts that had a longer string of A's (the length being what crashes vulnserver). The first fuzzing attempt was simply "TRUN 0" and since it didn't cause a crash, wasn't seen in the register upon inspection. The third attempt (captured by Wireshark but never made it to vulnserver because of the crash) was "TRUN /.../" followed by numerous A's. The fourth attempt was "TRUN /.../.../.../.../.../" with no A's. With limited insight into how generic_send_tcp works, I'm going to take a wild guess that the "/.:/" was just a part of the first fuzzing permutation that caused a crash (which was actually related to the length of the string moreso than the contents) and that it has no significance to the BOF. I imagine that modifying the script to just use "TRUN AAAAAAAAA..." would produce the same results. I'll test this tomorrow but it's getting late here. :)
Finally got around to testing this and I couldn't get it to crash without "/.:/". There's something magical about those characters but I'm not sure what it is yet...
@@mattbogenberger This is what I worry about in testing for OSCP, is that there will be some "magical" characters or some other type of magical string and I just want to try and understand how to identify these things. I'm at the sophistication level of .... this argument is vulnerable. throw a big string of A's and proceed as normal. Anything tricky like this will definitely screw me if I don't know what i'm looking for or why i'm looking for it.
shnosifaj I actually ended up looking at the source code (vulnserver.c) and found out why it’s doing that. There’s a line where it’s looking specifically for the “.” character in the string. The line is: if ((char)RecvBuf[i] == '.') {
hey heath I don't understand why I'm getting crashed at 100 bytes, I have tried both your python script but the result is same. Please help me in solving this issue. please!!!!!
@@TCMSecurityAcademy Hi Cyber mentor, on this question, how would you have found those extra symbols without having immunity running on the vulnerable server?
@@daviobalburdia Bro I have reviewed my script thoroughly and everything seems to be in order but I still get the same issue.....crashes at 100 bytes, vulnserver receives no connections and immunity doesn't pause.
Hi Cyber Mentor. I am getting an error in the 1.py python script. everything is correct "“bad interpreter: Too many levels of symbolic links”. any help would be helpful
Hi mentor ! awesome tuts, we really enjoy them, huge thnx for ur time and effort got one question why do we need to run immunity and vulnserver in windows side? regards Kuan
When i attach the process to immunity and press that "play" button, it actually freezes the process, but when i run the server without it, my python scripts runs well. Please help
Hello Dear Mentor, First of all I really like your videos, keep up the good work!! Is there a reason you chose spike instead of python script such as you did after? (i can create dict of all commands and check each one of it with the script to get the same result). Also wondering in case my target is chrome/firefox some other app which doesn't request commands/inputs and throws outputs... How to we approach to it's buffers inputs ? Thanks in advance!
Hi Cyber Mentor, I have an issue regarding immunity debugger. When i run fuzzing script, instead of giving me an access violation error, the immunity debugger returns me below error. Thread 0000XXXX terminated, exit code 0 Can you please guide me what kind of mistake i'm doing?
I am a new bee for the security and having little knowledge in python and when I am using python3, fuzzing script is not working, do anyone have python3 script?
I hope you enjoyed this video! If so, please consider dropping a like and subscribing.
Everytime I use the adblocker on the whole internet, but when you make these awesome videos, I watch them with my adblocker off. Keep up the good work (y)
Thank you for the support! It helps a ton
That was quite a bit of efford. If you have troubles, try to:
- restart immunity debugger and vulnsever.exe (important: run as administrator!)
- don't forget to start the immunity debugger
- turn off the firewall of windows 10
- it can sometimes take a few seconds to get a crash
- be very careful about the correct python script. I think that's the most critical point if you stuck --> whitespaces does matter in python. I had forgotten the space between "TRUN" and "/.:/"
- the functions "s.send" and "s.connect" are needing double brackets ((...))
So nice explained
Your name is hilarious
@@TurdFurgeson275 thank you sir
Depending on which version of python you're running, the script for 1.py might not work. You can set the script to use python 2 (which will work) by replacing the first line of code with “#!/usr/bin/python2”. This fixed an issue I had with the command line throwing a fit about print syntax (it wanted an extra set of parentheses that aren't in the code, and if you add them it breaks the code).
this comment was a life savor. I had no idea how i was writing that script wrong. Could u please explain why i need to use python 2 instead of python? is it cause the creator and I are on different versions of python?? and is it python from the immunity debugger, or kali linux python that its referring to?
Buffer Overflow scares me, but with your videos, I'm starting to grasp the concept. Thank you very much for the awesome content you create.
You're very good at explaining things thank you for the quality content . Have a nice day :)
Thank you :)
Any explanation on how you arrive at "TRUN /.:/" for the prefix to the buffer string? A typical ncat session only requires "TRUN [string]" so what are those additional characters for?
I did some captures with Wireshark and compared generic_send_tcp to manual attempts with netcat. As you pointed out, netcat captures only showed "TRUN [string]" as expected. What I found was that the "/.:/" string was first observed in the second fuzzing attempt by generic_send_tcp and seems to be nothing special other than it happened to be included in the first of the attempts that had a longer string of A's (the length being what crashes vulnserver). The first fuzzing attempt was simply "TRUN 0" and since it didn't cause a crash, wasn't seen in the register upon inspection. The third attempt (captured by Wireshark but never made it to vulnserver because of the crash) was "TRUN /.../" followed by numerous A's. The fourth attempt was "TRUN /.../.../.../.../.../" with no A's. With limited insight into how generic_send_tcp works, I'm going to take a wild guess that the "/.:/" was just a part of the first fuzzing permutation that caused a crash (which was actually related to the length of the string moreso than the contents) and that it has no significance to the BOF. I imagine that modifying the script to just use "TRUN AAAAAAAAA..." would produce the same results. I'll test this tomorrow but it's getting late here. :)
Finally got around to testing this and I couldn't get it to crash without "/.:/". There's something magical about those characters but I'm not sure what it is yet...
I was able to get this to work with "TRUN ." + buffer. There's something about the period...
@@mattbogenberger This is what I worry about in testing for OSCP, is that there will be some "magical" characters or some other type of magical string and I just want to try and understand how to identify these things. I'm at the sophistication level of .... this argument is vulnerable. throw a big string of A's and proceed as normal. Anything tricky like this will definitely screw me if I don't know what i'm looking for or why i'm looking for it.
shnosifaj I actually ended up looking at the source code (vulnserver.c) and found out why it’s doing that. There’s a line where it’s looking specifically for the “.” character in the string. The line is: if ((char)RecvBuf[i] == '.') {
Script stops with: Fuzzing crashes at 100 bytes. And on server i get : Recv failed with error: 10053. Any suggestions?
I had the same issue, turns out I put a . instead of a , in between the AF_INET and socket.SOCK_STREAM
@@maxregister9210 yes, I fixed my also. But for me it works whet i completely reload Debbuger and vulnserv)
hey heath I don't understand why I'm getting crashed at 100 bytes, I have tried both your python script but the result is same. Please help me in solving this issue. please!!!!!
@Abdur Rahman Bikash but it is not connecting to my vulnserver also
it is just crashing can you tell me or suggest any improvement in the code
super well explained , i still dont get what is the use of the symbols that we added after the "TRUN" though , appreciate all your efforts
We captured this in the spiking section. Look at the spike of TRUN in Immunity and you'll see it
@@TCMSecurityAcademy Hi Cyber mentor, on this question, how would you have found those extra symbols without having immunity running on the vulnerable server?
@@ithinkv I think you need to have a sample "exe" that you can test locally.
I crashed at 100 bytes, and i do not see anything through immunity, even if I reset everything
same problem. Please help cyber mentor
@@daviobalburdia Bro I have reviewed my script thoroughly and everything seems to be in order but I still get the same issue.....crashes at 100 bytes, vulnserver receives no connections and immunity doesn't pause.
@@kellyorjiude did anyone ever figure this out
@@thelegacygaming4982 it is because of a syntext error
For me, i found my mistake which is located:
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
where I type a '.' instead of ','
fuzzing script in not working...
what should i do ????
Hi Cyber Mentor. I am getting an error in the 1.py python script. everything is correct "“bad interpreter: Too many levels of symbolic links”. any help would be helpful
I found the issue
@@steveshawcross855 tell me bro you can save my life 😂
Can you please put the python code in the link cause I keep getting errors
Hi mentor !
awesome tuts, we really enjoy them, huge thnx for ur time and effort
got one question why do we need to run immunity and vulnserver in windows side?
regards Kuan
Is this enough practice for the OSCP, i did many buffer overflow practice and got shell but still failed the OSCP buffer overflow?
are you telling or asking?
Thanks for the video!
When i attach the process to immunity and press that "play" button, it actually freezes the process, but when i run the server without it, my python scripts runs well. Please help
Hello Dear Mentor,
First of all I really like your videos, keep up the good work!!
Is there a reason you chose spike instead of python script such as you did after? (i can create dict of all commands and check each one of it with the script to get the same result).
Also wondering in case my target is chrome/firefox some other app which doesn't request commands/inputs and throws outputs... How to we approach to it's buffers inputs ?
Thanks in advance!
Thank you for the nice words :). Spike is the easiest way to teach it. You could definitely create your own Python script to do the same thing!
Hi Cyber Mentor,
I have an issue regarding immunity debugger.
When i run fuzzing script, instead of giving me an access violation error, the immunity debugger returns me below error.
Thread 0000XXXX terminated, exit code 0
Can you please guide me what kind of mistake i'm doing?
SOCK_STREAM does not mean port, it means it is TCP socket.
I first time i got crash at 3500 and second time it is at 5100 why this difference
And i was send 3500 A's then not crashed
I'm unsure to be honest?
@@TCMSecurityAcademy mine crashing at 100 everytime but it shows running in immunity debugger
@@harjotsaini1038 Did you figured out the issue? I have reviewed the code multiple times and I get "Fuzzing crashed at 100 bytes"
@@jgaldi1615 yes bro I don't remember the line number but I was using . Insted of this ,
I am a new bee for the security and having little knowledge in python and when I am using python3, fuzzing script is not working, do anyone have python3 script?
Immunity debugger cannot get a hit and doesnot stop. Can someone help?
I cant still understand what does that /.:/ part does
Yeah but how would you know the extra stuff on the TRUN command if you didn't already have access to the victim's machine? huh???
Because you dont exploit it on the victims machine until you build an exploit out through research and development. That's why these tools exist.
script is not working for me what should i do , File "./1.py", line 6
try:
^
IndentationError: expected an indented block
the error is telling you the issue. check your indentation. python uses tabs
You have an unexpected indent (tab) spacing in your program. Line 6 of your code contains the problem.
The screen resolution is very high. I can't see the code very well on my cellphone. Thanks.
I like it like this. I think most people do. You shouldn't be following along on your phone anyways, where are your VMs setup?