Programming Forums
User Name Password Register
 

RSS Feed
FORUM INDEX | TODAY'S POSTS | UNANSWERED THREADS | ADVANCED SEARCH

Reply
 
Thread Tools Display Modes
Old Jun 16th, 2005, 6:11 PM   #1
mitakeet
Programmer
 
mitakeet's Avatar
 
Join Date: Jun 2005
Location: Maryland, USA
Posts: 59
Rep Power: 10 mitakeet is on a distinguished road
Self modifying code, pipelining and interrupts

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)
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?
__________________

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
mitakeet is offline   Reply With Quote
Old Jun 16th, 2005, 7:21 PM   #2
earl
Newbie
 
Join Date: Jun 2005
Posts: 18
Rep Power: 0 earl is on a distinguished road
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
earl is offline   Reply With Quote
Old Jun 16th, 2005, 7:56 PM   #3
DaWei
Resident Grouch
 
DaWei's Avatar
 
Join Date: Jun 2005
Posts: 8,368
Rep Power: 19 DaWei will become famous soon enoughDaWei will become famous soon enough
"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.
__________________
Contributor's Corner:
Politically Incorrect
DaWei on Pointers
DaWei is offline   Reply With Quote
Old Jun 16th, 2005, 8:05 PM   #4
Scorpions4ever
Programmer
 
Join Date: Jun 2005
Posts: 86
Rep Power: 10 Scorpions4ever is on a distinguished road
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 .
Scorpions4ever is offline   Reply With Quote
Old Jun 17th, 2005, 6:11 AM   #5
mitakeet
Programmer
 
mitakeet's Avatar
 
Join Date: Jun 2005
Location: Maryland, USA
Posts: 59
Rep Power: 10 mitakeet is on a distinguished road
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
mitakeet is offline   Reply With Quote
Old Jun 17th, 2005, 7:03 AM   #6
DaWei
Resident Grouch
 
DaWei's Avatar
 
Join Date: Jun 2005
Posts: 8,368
Rep Power: 19 DaWei will become famous soon enoughDaWei will become famous soon enough
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.
__________________
Contributor's Corner:
Politically Incorrect
DaWei on Pointers
DaWei is offline   Reply With Quote
Old 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: 10 lostcauz is on a distinguished road
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!
lostcauz is offline   Reply With Quote
Old Jun 17th, 2005, 9:18 AM   #8
mitakeet
Programmer
 
mitakeet's Avatar
 
Join Date: Jun 2005
Location: Maryland, USA
Posts: 59
Rep Power: 10 mitakeet is on a distinguished road
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
mitakeet is offline   Reply With Quote
Old Jun 17th, 2005, 9:19 AM   #9
DaWei
Resident Grouch
 
DaWei's Avatar
 
Join Date: Jun 2005
Posts: 8,368
Rep Power: 19 DaWei will become famous soon enoughDaWei will become famous soon enough
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.
__________________
Contributor's Corner:
Politically Incorrect
DaWei on Pointers
DaWei is offline   Reply With Quote
Old 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: 10 lostcauz is on a distinguished road
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!
lostcauz is offline   Reply With Quote
Reply

Bookmarks

« Previous Thread in Forum | Next Thread in Forum »

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump




DaniWeb IT Discussion Community
All times are GMT -5. The time now is 11:55 AM.

Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC