I believe you are just being pedantic about my use of the word "debugging" to include things like unpacking, static analysis, and a variety of tools and processes used.
So when you say
> 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's just not true.
You just debug in a system without these protections turned on then.
Like, can you give an example of a debugging task you have carried out that requires reading the code segment of the running process?
Made easier by? Most everything ever loaded in a debugger.
You can't just scan the IAT/PLT. You are going to have to find load points or manually step through, and maybe calculate function offsets in the library. Not impossible at all.
It is however something you could have just quickly glanced at and found otherwise.
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.