Re: Can't Preventing exploitation with rebasing

All difficulties posed by such a "rebasing" technique can be conquered.
The only difficulty it presents is getting back to your shellcode. This
can be overcome easily unless you're remapping kernel memory as well.
The kernel holds secrets to finding loadlibrary and getprocaddress, and a
jmp esp which is all you need to make your shellcode dance.

DIGRESSION:
Dave Litchfield says you can call esp. I don't know Dave's
relationships with his registers but this doesn't work if I want
to get my eip on top of my shellcode. Always starts executing a
memory address for me. Maybe if I took esp out to dinner more
often then I could call it instead of having to jump on top of it.
Dave, any suggestions for the wine list?
END DIGRESSION.

There's no silver bullet for security. Security is in a fluid state
always, and will always be so.

-Jove

> Brian Hatch <bugtraq@ifokr.org> wrote:
> > People keep saying "but it won't stop everything", and that's true.

> This takes the security versus obscurity argument from the realm of
> personal opinion to one of quantitative statements. We should have a
> similar goal for this discussion.

[David Litchfield]

Going back to exe image files and rebasing. Surely they can be rebased even
without a .reloc section? All I need to do is edit the image base in the PE
header then parse the assembly looking for absolute addresses such as
function addresses, static variables etc and modify these addresses, too.

For example assume an image base for an exe is 0x00400000 and the c code
does

printf("hello");

This will generate something like

push 0x0042001C // push pointer to hello
call 0x00401060 // call printf

If I then make the image base 0x00410000 and I also change

push 0x0042001C
call 0x00401060

to become

push 0x0043001C
call 0x00411060

then the exe should still run (as long as you get all the absolute
addresses) and it has been rebased.

?
David