MOV EDI, EDI

[baltoro]

This may be a bit controversial for the Campus (I don't think so), but,...
Being a HUGE RAYMOND CHEN fan,...I read his blog almost every day,...and. today's post has me somewhat confused. Maybe some of you assembly geek geniuses can enlighten me. The blog entry is here: Why Do Windows Functions All Begin With a Pointless MOV EDI, EDI Instruction?
The explanation that Mr. Chen provides is that the MOV EDI, EDI instruction (equivalent to two nops) is a hot patch point,...
That I understand. What I don't understand is: Isn't this also a HUGE security hole ???

What d'ya think ???

As Mr. Chen points out: "Hot-patching is not an application feature. It's an OS internal feature for servicing. Who are these people who keep trying to patch code they didn't write?!" And,..."Sorry. It's just that I see soooo many people trying to do crazy patching, I have no idea what they're trying to accomplish. They just seem to loooooove patching. And code injection."

This phenomena has already been discussed here on the MASM Forum: WHY in a Lot of API's There is "MOV EDI, EDI"

[bozo]

why do you feel it's a security hole? even without the 2 extra bytes, you can hook functions and those are easily detected nowadays with various tools.

[hutch--]

 :bg

there is a solution in your own code, don't make patching easy at all. this is in fact something that the 32 bit version of CL does well in that it both removes the stack frame on many procedures AND staggers the register preservations required for the procedure and that tends to give you a scruffy looking mess near the front of the procedure that is not easy to directly patch unless you patch the entire procedure and then it must fit into the byte space of the one being patched.

You can get around it but its not kiddies stuff.

[baltoro]

...this is in fact something that the 32 bit version of CL does well in that it both removes the stack frame on many procedures AND staggers the register preservations required for the procedure and that tends to give you a scruffy looking mess near the front of the procedure that is not easy to directly patch unless you patch the entire procedure and then it must fit into the byte space of the one being patched,...

I had no idea. This is the normal action of the compiler ??? Just goes to show you what a fetus I am when it comes to assembly language programming.
Thanks for the info, hutch.