Does your shellcode have enough room to decode? Could be you need to add some more nops at the beginning of your buffer to let it breathe, or perform some stack adjustment. Then again, I may not know what I'm talking about![]()
So I am working with a vulnerability and trying to get it to work. It is a client-side activeX vulnerability. So right now I have it in a .wsf file and am working on just getting it to work using cscript.exe before moving it over to Internet Explorer and dealing with its permanent DEP.
It is a SEH overwrite. Where I am at currently is I am able to pivot the stack to where my shellcode is so that ESP points to a JMP ESP and is followed by a NOP slide into my shellcode. I've watched in the debugger and can see that my shellcode begins to execute properly, but along the way I get an exception for an Access Violation because it manipulates one of the registers to a invalid memory location.
This particular application has many bad characters that I had to work around when generating the shellcode. Because of this, I don't have many encoding options that work, but the few that do work copy over correctly onto the stack.
Now, obviously I am not expecting specific help regarding why the particular shellcode or exploit I am working with isn't working because I haven't given you enough information to help me in that respect. However, if it is possible, I'd like maybe a few possibilities on why the shellcode wouldn't work. Bad characters have been accounted for. I generated the shellcode and encoded it with the latest Metasploit version. The shellcode begins to execute properly as I can see it executing in the debugger. I am executing it in a .wsf file using cscript.exe on a Windows XP SP3 box with no software DEP on that process.
I've really just been soaking up as much info as possible and I've made a ton of progress lately, but can't figure this out. Any help would be appreciated.
Does your shellcode have enough room to decode? Could be you need to add some more nops at the beginning of your buffer to let it breathe, or perform some stack adjustment. Then again, I may not know what I'm talking about![]()
Maybe add some xor(all exept esp,ebp) at the start of the shellcode.
If you have ruled out mangling due to bad characters, and the exploit reaches the point where the CPU actually starts to execute your encoded shellcode, Id tend to agree with f1guref0ur and say that the problem lies in the decoding process. Try the same encoded shellcode in another simple exploit and watch how it decodes in a debugger - this should give you an idea of how the decoding works and where the problem may lie.
Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".
The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.
Thanks for the replies. This is what I've tried so far. I added plenty of room to allow for decoding, so there really isn't much of an issue there. I have 80 bytes of NOPs prior to my shellcode on the stack and the shellcode decoding process never really gets to the point where it runs into any of that. I've also added the following before my shellcode to zero out the 2 registers that have values in them when the shellcode starts executing:
33 c9 xor ecx, ecx
33 d2 xor edx, edx
That didn't work either.
I don't know. Maybe there is an issue with the shellcode that I have generated due to the number of bad characters. I will try encoding it again and see if I get the same results. I'll post back how it goes.
So... Did you get it to work?
Try zeroing out the stack space, say a sub 40h esp is used for some function make sure all that space is zeroed, the function migh expect it to be zero with a normal function programI don't know. Maybe there is an issue with the shellcode that I have generated due to the number of bad characters. I will try encoding it again and see if I get the same results. I'll post back how it goes.
Last edited by compaq; 09-05-2010 at 06:00 AM.
Still haven't gotten the shellcode to execute properly on the stack without any exceptions. Like I said, it does start to execute, but I always get an exception midway through. I haven't tried zeroing out the stack space. But, I am beginning to realize why the original exploit used a JIT Spray method to load the shellcode into a different place in memory.
The original exploit is here: SigPlus Pro v3.74 ActiveX LCDWriteString() Remote BoF JIT Spray - aslr/dep bypass
I tried using a Heap Spray method, but I am trying to get the exploit to work under IE8 and I don't know any techniques of spraying the heap under IE8's memory protection.
It looks like interpreter exploitation techniques are the best way under IE8, but I haven't found a good JIT Spray tutorial after searching the internet far and wide. If anyone knows of any, let me know. Thanks for all the help!
Check this out http://www.dsecrg.com/files/pub/pdf/...d%20profit.pdf
Thanks Cryptik. Ya, I originally looked at that document when trying to learn about JIT Spray. It was about the only JIT spray doc I could find. I downloaded the scripts they had posted on dsecrg.com and was able to generate the Action Script and compile it to a SWF file. The only trouble I have with the process is determining the return address into the JIT stage-0 shellcode. The process is a bit above me at the moment. I'll have to read up on it several more times for it to make sense.
Thanks again.