For those who are trying to leak an address, there is no need to do so. Have a look at the binary protections ;-). There is a well-known technique that can be used here to jump to a certain address. For those who, even so, still have troubles with the total bytes available to write a working shellcode, think that you can almost “split” the thing more or less in two halves.
For those who are trying to leak an address, there is no need to do so. Have a look at the binary protections ;-). There is a well-known technique that can be used here to jump to a certain address. For those who, even so, still have troubles with the total bytes available to write a working shellcode, think that you can almost “split” the thing more or less in two halves.
Cheers, good luck.
This can become much more complicated. There’s another way if you know what to do. I’d say go with easier side to this.
For those who are trying to leak an address, there is no need to do so. Have a look at the binary protections ;-). There is a well-known technique that can be used here to jump to a certain address. For those who, even so, still have troubles with the total bytes available to write a working shellcode, think that you can almost “split” the thing more or less in two halves.
Cheers, good luck.
This can become much more complicated. There’s another way if you know what to do. I’d say go with easier side to this.
For those who are trying to leak an address, there is no need to do so. Have a look at the binary protections ;-). There is a well-known technique that can be used here to jump to a certain address. For those who, even so, still have troubles with the total bytes available to write a working shellcode, think that you can almost “split” the thing more or less in two halves.
Cheers, good luck.
This can become much more complicated. There’s another way if you know what to do. I’d say go with easier side to this.
But my way is way more fun
huh? what do you mean by more fun, a solve is a solve. Spltting the shellcode is just way overkill.
Would anybody be able to help me out a bit here? My shellcode works fine locally, but not on the remote service, and I have no clue what could be going wrong. Hate it when this happens…
Would anybody be able to help me out a bit here? My shellcode works fine locally, but not on the remote service, and I have no clue what could be going wrong. Hate it when this happens…
There is multiple ways to solve this one, you need to explain more on what you have done.
It can be the execution env for example, or something else.
Would anybody be able to help me out a bit here? My shellcode works fine locally, but not on the remote service, and I have no clue what could be going wrong. Hate it when this happens…
This mainly happens due to some type of stack misalignment error. At least what I have face in the past. But nothing much can be said without looking at the payload that you’re sending.
hi i’m stuck. I can rewrite $eip to any value, but it doesn’t give much result.
I can’t use ret2leb, because I don’t know the “libc” address.
maybe i should focus on plt and got sections. I need a hint.
tell me what strategy should i follow?
or write to me in HP with a more detailed explanation.
hi i’m currently stuck. I do have kind of control of eip what the various things i tried do either only work locally or dont work at all. could someone please give me a hint on how to proceed or pm me for more details.
thx
Finally managed to solve it ( I guess ) is the intended way, but not sure about that. If someone can pm me regarding the rop approach that would be awsome.
EDIT: ok after a mess I figured it out. I used to Sp**t my shellcode. Looking for someone to compare my solution to check if I solved it the intended way.
My exploit only works on gdb. I’ve also turned off address randomization and unsetted gdb env var.
Can anybody give me a nudge on what I’m missing?
I have split the shellcode into 2 seperate parts. After lots of experimenting I got it to work in gdb. However, when running it outside of gdb, I get a segmentation fault. I think this is because the kernel pushes things like enviroment variables, params etc to the stack, and thus invalidating any hardcoded adresses in the exploit. Did anyone get around this?
If someone did it the way it was supposed to be done please PM me, I need some help, can’t understand how all functions work together and how the stack works in this case. the variable in vuln is 10bytes long but 0x14 (20) bytes are allocated instead…