Programming Forums > Application Development > C++

mitakeet · Jun 16th, 2005, 6:11 PM

This is a follow up question to an old thread I happened to come across on DevShed: http://forums.devshed.com/showpost.p...9&postcount=18. In it, Scorpions4ever uses some tricks to detect if a program is running in a debugger:

Quote:

(pseudo-asm code)

(Toggle Plain Text)

MOV AX, 4Ch
MOV [someaddr], AX
MOV AH, 30h
INT 21
CMP AL, 5

Now looking at this code, the last three instructions appear to be getting the DOS version and checking if the major version # is 5 (Int 21h with AH set as 30h returns DOS version). The code's not so innocent after all though. The first two instructions move the value 4c into some specific memory location. In fact, the first two instructions change the value of the third instruction so it reads:
MOV AH, 4Ch
Now what does calling INT 21h with AH=4Ch do? This is the DOS function to terminate a program and return to the command interpreter.

Ok, so now we're getting cute. If the program merely terminates itself, what's the purpose of all this code, you ask? Here's where the true voodoo takes place. A Pentium chip pipelines its instructions to improve performance. So the first two instructions end up overwriting some area of memory, but the instruction that is occupying that area of memory is already loaded into the pipeline and hence it executes as:
MOV AH, 30h
whereas the memory where the instruction resided now reads:
MOV AH, 4Ch

So, the program gets the DOS version and merrily goes along its way, exactly as it appears to do.

Now comes the real tricky part -- if your cracker is running the program through a debugger, the debugger puts the CPU in single-step mode (i.e.) it does NOT pipeline the instructions. Hence, when the CPU gets to the third instruction and sees:
MOV AH, 4Ch
and then runs INT 21 and terminates the program!

I am reading a hardware book on pipelining and am in a section that deals with the logic of interrupts and it seems to me that if there is an interrupt during the execution of these instructions that the program will restart after pulling the changed instructions from memory and promptly terminate (just like what would be expected to happen if a debugger were running). I suppose this would be a low probability event, but certainly not a no probability event. Have I analyzed this correctly or am I still too new to hardware pipelining?

earl · Jun 16th, 2005, 7:21 PM

Don't know much about pipelining, but I'm curious about that snippet you posted.

How exactly do the first two instructions change the value of the 3rd instruction? Looks to me like you store a value in a register, store that value in memory, store a value in a separate register, and somehow that last value you stored is different..? I've got to be missing something here. :p

DaWei · Jun 16th, 2005, 7:56 PM

"someaddr" is the address where the 30H is. I think you'd need AL, though. If the instruction memory is not write protected or in ROM, there's nothing to prevent one's changing it on the fly.

Mitakeet, you're gonna make me brush up, aincha :p ? In days of yore, an interrupt would have negated the things in the pipeline and it would have behaved the same as if one were in debug single-step.

Scorpions4ever · Jun 16th, 2005, 8:05 PM

Quote:

Originally Posted by earl

How exactly do the first two instructions change the value of the 3rd instruction? Looks to me like you store a value in a register, store that value in memory, store a value in a separate register, and somehow that last value you stored is different..? I've got to be missing something here. :p

That's because [someaddr] is carefully chosen to point to the memory location where 30h is stored. So, when you store that value in memory, you're changing the next instruction

. That's how the voodoo is pulled off.

mitakeet: You could always toss CLI and STI instructions before and after that chunk, so interrupts are temporarily disabled. In fact, another nice trick is to disable the keyboard and the mouse and re-enable them a few instructions later. People running the code in a debugger suddenly find that they can no longer single step

.

mitakeet · Jun 17th, 2005, 6:11 AM

CLI and STI are privledged mode instructions, aren't they? Ordinary user processes can't use them if I am interpreting Intel's docs correctly.

As I recall, presuming you have de-protected your instruction page(s), you would still have to execute an instruction cache flush in order to retrieve the changed instructions, so it seems that there is plenty of room for mayhem. I suppose that depends on whether the debugger reads instructions directly from main memory or if it is actually reading instructions from cache (totally hardware dependant, I presume).

Dissabling keyboard and mouse should be within the user's purview, wouldn't it? That would be a nice trick as it might take a sharp-eyed cracker to notice that the 'single step' was actually a handful of instructions.

DaWei · Jun 17th, 2005, 7:03 AM

CLI and STI are privileged. Back to your original question, a hyper-threading processor with appropriately constructed cache mechanisms could be built so that an interrupt would "switch" to a different cache and thus not invalidate the "normal" cache. A cursory inspection around the Google Tree last night revealed no definitive answer.

lostcauz · Jun 17th, 2005, 7:57 AM

Interesting stuff. I just woke up so maybe I'm missing something too. Couldn't the cracker simply nop those instructions or jump past them?

mitakeet · Jun 17th, 2005, 9:18 AM

Sure, but he has to locate them amongst the millions of identical looking instructions. Being a good cracker is all about being able to find the 10-20 instructions that are critical out of the massive pile of irrelevant instructions. Even decent dissassemblers are prone to make mistakes when presented with binaries that have been deliberately tuned to make dissassembling problematic.

DaWei · Jun 17th, 2005, 9:19 AM

Sure. Might take him a while to catch on that that's the place to do it. The safe hasn't been built that a dedicated cracker can't get into, the idea is to discourage those with less than the necessary dedication.

lostcauz · Jun 17th, 2005, 10:39 AM

Agreed. Actually I attempted a reversing challenge and of the 11 programs only 2 eluded me. Both involved smc. I gave up fairly quickly from boredom but then again I'm not a cracker.

I reckon this supports the point concerning dedication. I use Olly daily when writing/debugging assembler programs but I view cracking others programs to circumvent protections as akin to my stereotypical feelings concerning used car salesmen and attorneys.

Jun 16th, 2005, 7:56 PM	#3
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	"someaddr" is the address where the 30H is. I think you'd need AL, though. If the instruction memory is not write protected or in ROM, there's nothing to prevent one's changing it on the fly. Mitakeet, you're gonna make me brush up, aincha :p ? In days of yore, an interrupt would have negated the things in the pipeline and it would have behaved the same as if one were in debug single-step. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Jun 17th, 2005, 6:11 AM	#5
mitakeet Programmer Join Date: Jun 2005 Location: Maryland, USA Posts: 59 Rep Power: 4	CLI and STI are privledged mode instructions, aren't they? Ordinary user processes can't use them if I am interpreting Intel's docs correctly. As I recall, presuming you have de-protected your instruction page(s), you would still have to execute an instruction cache flush in order to retrieve the changed instructions, so it seems that there is plenty of room for mayhem. I suppose that depends on whether the debugger reads instructions directly from main memory or if it is actually reading instructions from cache (totally hardware dependant, I presume). Dissabling keyboard and mouse should be within the user's purview, wouldn't it? That would be a nice trick as it might take a sharp-eyed cracker to notice that the 'single step' was actually a handful of instructions. __________________ Free code: http://sol-biotech.com/code/. It is not that old programmers are any smarter or code better, it is just that they have made the same stupid mistake so many times that it is second nature to fix it. --Mitakeet The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. --George Bernard Shaw

Jun 17th, 2005, 7:03 AM	#6
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	CLI and STI are privileged. Back to your original question, a hyper-threading processor with appropriately constructed cache mechanisms could be built so that an interrupt would "switch" to a different cache and thus not invalidate the "normal" cache. A cursory inspection around the Google Tree last night revealed no definitive answer. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Jun 17th, 2005, 7:57 AM	#7
lostcauz Hobbyist Programmer Join Date: Nov 2004 Location: 1691 miles East of L.A. Posts: 159 Rep Power: 4	Interesting stuff. I just woke up so maybe I'm missing something too. Couldn't the cracker simply nop those instructions or jump past them? __________________ -- lostcauz Stepped in what?... Behind whose barn?... I didn't even know they had a cow!

Jun 17th, 2005, 9:18 AM	#8
mitakeet Programmer Join Date: Jun 2005 Location: Maryland, USA Posts: 59 Rep Power: 4	Sure, but he has to locate them amongst the millions of identical looking instructions. Being a good cracker is all about being able to find the 10-20 instructions that are critical out of the massive pile of irrelevant instructions. Even decent dissassemblers are prone to make mistakes when presented with binaries that have been deliberately tuned to make dissassembling problematic. __________________ Free code: http://sol-biotech.com/code/. It is not that old programmers are any smarter or code better, it is just that they have made the same stupid mistake so many times that it is second nature to fix it. --Mitakeet The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. --George Bernard Shaw

Jun 16th, 2005, 7:21 PM	#2
earl Newbie Join Date: Jun 2005 Posts: 18 Rep Power: 0	Don't know much about pipelining, but I'm curious about that snippet you posted. How exactly do the first two instructions change the value of the 3rd instruction? Looks to me like you store a value in a register, store that value in memory, store a value in a separate register, and somehow that last value you stored is different..? I've got to be missing something here. :p

Jun 17th, 2005, 9:19 AM	#9
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Sure. Might take him a while to catch on that that's the place to do it. The safe hasn't been built that a dedicated cracker can't get into, the idea is to discourage those with less than the necessary dedication. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Jun 17th, 2005, 10:39 AM	#10
lostcauz Hobbyist Programmer Join Date: Nov 2004 Location: 1691 miles East of L.A. Posts: 159 Rep Power: 4	Agreed. Actually I attempted a reversing challenge and of the 11 programs only 2 eluded me. Both involved smc. I gave up fairly quickly from boredom but then again I'm not a cracker. I reckon this supports the point concerning dedication. I use Olly daily when writing/debugging assembler programs but I view cracking others programs to circumvent protections as akin to my stereotypical feelings concerning used car salesmen and attorneys. __________________ -- lostcauz Stepped in what?... Behind whose barn?... I didn't even know they had a cow!

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Programming Forums > Application Development > C++

Self modifying code, pipelining and interrupts