[hleach]

This looks like it goes way beyond ASLR.

There are a series of different protections they are doing. It's not clear if they intend them to be uniquely switchable or if they were just separating them to indicate which attack techniques require which protections.

For example it appears to combat ROP they are additionally encrypting the code segment of the program and decrypting on an as needed basis. I am absolutely sure this would make debugging more difficult. It wouldn't be used on a debug build though so I guess the question is how often would you find yourself debugging a production executable.

I admit I didn't read it in depth and may have missed something but I wonder if they are doing something similar for dynamic libraries or if it relies on the code being available at compile time. If not then I'm sure someone clever will still get around it with ROP.

[monocasa]

The debugger doesn't really rely on the code segment being readable generally.

[hleach]

You are conflating the act of debugging with the operation of a "debugger".

Sure you can start at 0 and step forward one instruction at a time, but how often do you do that without at least looking at the code?

Not being able to look ahead or behind but only within what is actively on the stack is certainly a limiting factor in debugging.

It is of course a problem that has been solved before. Someone would develop an unpacker/decrypter for it at some point and make this trivial, but that would still be an added level of complexity.