Bypassing Protec

by Michael Wilson

I've been reading 2600 for just over two and a half years, and I've collected about 35 megs of hacking texts which I just about know by heart, and over the last ten years, I've been able to apply about one-fifth of the information that I've acquired.  I have learned one thing well: by the time information on a backdoor trickles down to you, it's usually closed.  And no matter how many poorly written text files you have, nobody can learn a thought process without discovering it themselves.  You've usually got to reinvent the wheel every time you try something new in order to understand what's going on.  If you don't understand what's going on after applying a cookbook answer to a hacking question, it was a useless venture.

So here are the details about my experience with Bo Krohn's Protec, and hopefully enough explanation so you understand what's going on in addition to what the procedure is.  I have only discussed this with one person since these events transpired, so you're getting it from the horse's mouth, as it were:

Some years ago, I attended a particular community college that we affectionately call "Harvard on the Hudson" (not to be confused with Columbia).  Anyway, they have about sixty i386-33's for free student use, and quite a bit of software.  They also have a very annoying little piece of software called Protec.  Protec is a hard drive security program that I don't think was ever debugged by the original authors.  You might think that means that they have all kinds of backdoors that they never thought of closing.  Well, it's true.  But what's more interesting, is that every once in a while, Protec decides that it doesn't like the 3500 line program you're working on and decides, when you try to save it, that you're attempting an illegal file copy and erases your program.  Now, this tends to make a programmer very very pissed off.  So I set out to do something about it.

As to how exactly Protec works, well, I'm not sure.  I've got a theory, which I'll posit here, because I think it will help you to understand how I came about my "solution" to the Protec problem.  Protec is composed of about five parts, near as I can tell.  There is boot sector specific code and four device drivers.

Let's say, for arguments sake, that what we're working with is a UNISYS 386DX-25 with a 1.44 MB floppy as drive A, a 1.2 MB as drive B, and an unknown number of hard drive partitions.

When you put a bootable 1.44 floppy in, and do a 8 finger salute (or a cold-boot, doesn't matter), you get what is, for all purposes, control of the machine.

But for all intensive high-level purposes, there are no hard drives, they just don't seem to exist.  In fact, if you install a VDISK (virtual RAM disk, or even something a little more exotic), it will install as C.  If you are trying to circumvent Protec, however, I don't really recommend any ram disks.  They are unnecessary and cause grand headaches.  Now, the astute reader will have caught the reference to "high-level" above and has probably already figured out how I've done this.  Well, keep reading - it's not that simple.

So let's suppose you have Norton Utilities (if you don't, no big deal, you'll see).  Load it up and go to choose item, Drive.  Only drives A and B are listed at all.  What?  You mean Norton doesn't even acknowledge them?

Well, yes and no.  If you go to choose item, absolute disk sectors, Norton will ask you to pick a drive and, lo and behold, the hard drives are sitting there, with their flies open.  So you can look at the drives sector by sector, big deal.  But wait.  What's the difference?  Why was one menu showing the hard drives C and D and the other menu just showing the floppies?  The answer to a DOS programmer is trite, but to someone not fluent in DOS internals and ROM BIOS of an 80x86 system, it could be quite perplexing.  Let me explain.

We're all familiar with interrupt 21h, that's the DOS function call that handles disk access on a relative sector and file level.  The specific function (load, save, delete, etc.) is determined by the register settings at the time of the interrupt call.  21h is a software-based interrupt.  That means it is installed by DOS when you boot up your computer.  But how is it loaded off the disk?  Theoretically, it would need routines similar to the ones it provides (reading, writing, etc.) in order to load the OS.  Well, those routines are built into the ROM BIOS (Basic Input/Output System).  Beautiful, so what?

This means that because the software interrupts are in RAM, they can be endlessly played with.  This is how all self-respecting software based computer security works on the 80x86 machines; it redirects the calls to these routines so that the call is passed through a third-party routine that checks the parameters being passed into the actual functions to make sure the user isn't trying to do anything mean and nasty.  If he/she is doing something nasty, this is when the bells and whistles are set off and all kinds of crap.  If the call is a "valid" one then control is passed to the original routine, as if nothing had happened except for a time lag.

Basically, Protec uses this procedure to filter out calls to the protected drives.  So how do we get by this?  Allow me to throw out some ideas and show you why some are and some are not practical.

1. We could find the address of the original routine and restore the interrupt vector table to its original state.
2. We could use the BIOS routines to get to the disk, thereby not even using the altered functions.
3. We could somehow prevent the original interrupt 21h function from being altered in the first place.

O.K., Number 1.  The simple question is, how.  Once you are in the system, protection has been loaded somehow.  The table that stores the addresses to all interrupt routines (called the interrupt vector table) is located at the bottom of memory, and is very easy to access.  However, we must assume that the table is altered before we can possibly get to it to find what the true address is (this is indeed the case).

What about Number 2?  Theoretically, this would work.  You could use Interrupt 13h to get any sector on the disk and it would basically ignore Protec all together.  But all the information and procedures needed to interpret directory trees and logical sector numbers is contained within the diseased software interrupts.  We would have to have a DOS technical reference, and we would basically have to rewrite the operating system from scratch.  No fun, I can tell you.  (But I am working on a BIOS-based XTree-type program.  It's hard work, but it will make things like this easy work someday.)

That leaves Number 3 (plus a number of very stupid ideas I haven't put here and a number of brilliant ones that I just haven't thought of).  We have to stop Protec from ever being loaded.  So how the hell do you do that?  Once you're in, it's in too, isn't it?  Yes, but remember, we can stop it from being loaded in again, can't we?  Look up a few paragraphs.

What's the root of Protec's scheme?  Redirecting interrupts before you can get to them.  When would it have to do that?  During the boot procedure.  How can we change the boot procedure so that it doesn't load Protec?  A couple of thoughts: we could alter the CONFIG.SYS and AUTOEXEC.BAT files.  But we can't get to them, we don't know where on the disk they are (remember, we have no access to the file system as such, just the absolute disk sectors themselves).  That leaves the boot sector.  It turns out that all you have to do is replace the boot sector with a "normal" one.

What you have to do is run a program (like the one below) that will save a plain normal boot sector (preferably from a hard drive) to a file, boot up the protected computer (from floppy) and run the program again, this time saving the boot sector of their hard drive to a file and replacing the boot sector with the one you've previously saved, then reboot the computer from their hard drive, reversing the procedure when you're done.

Something has just occurred to me.  I am assuming that all of the operating systems are similar.  They have to be the same manufacturer (I hate to think what would happen if you tried to replace an MS-DOS boot sector with a DR-DOS one.  Blechh.), and I would expect, a similar version (i.e., same major version number).  You might have a bit of flexibility with the version numbers.  I'm not sure because I've had no problems with this procedure at all.  But I no longer have access to machines with Protec so I can't test the limits of compatibility.  I'll leave it up to you.

Now, the way I figure it, some of you will be smiling and rubbing your hands together, reaching for your favorite compiler.  But, as fate would have it, Bill Gates and the rest of those cyber-imperialists at Microsoft have given us all the ability to do this on our standard DOS disks.  It's called DEBUG.  You can use DEBUG to load in the boot sector, save it to a file and load a pre-saved "normal" boot sector and insert it in place, replacing them when done (or not, but I recommend it highly.  Cover your tracks.).  A friend of mine who has one of the greatest natural talents for hacking I've ever seen did it exactly this way.  I looked through the DOS manual and decided to write the program in Turbo Pascal.

I've included the source code for a cute little program I came up with to save a boot sector to a 512 byte file.  It will also load a 512 byte file and save it over the top of a boot sector.  There is nothing really strange within the source code.  But I'll go through it for the sake of completeness.  This version of the program compiles to about 6k under Turbo Pascal 5.5.

The basic menu procedure is simple enough, it just repeats until a valid entry is made.  The first option prompts you for a drive number (remember 0 = A, 1 = B, etc.) and a file name to save the boot sector to.  The second option prompts you for similar information, but it loads a file into the buffer and overwrites the boot sector of the chosen drive with that buffer.

The sector reads and writes load a copy of the registers with the correct information to read or write where applicable, as well as including the track, head, and relative sector numbers.  They then call interrupt 13h with this register set-up.  I pulled these out of a low-level DOS unit I've been writing, so they are general purpose functions that you could use elsewhere.  The only things that might look strange are the ex := seg (sectorbuffer) type functions.  All they do is load the EX register with the segment portion of the address of the buffer and load the BX register with the offset portion of the address of the buffer.  Aside from that, this program should be easily translatable into your favorite language and compiler.

Well, now you've seen the basics of dealing with PC security.  There are many other topics and approaches.  This one is a true brute-force, zero subtlety type approach, and not very high on the scale of elegance.  As I'm sure you know, a security system is only as secure as its weakest link.  I believe this is Protec's weakest link.  It is certainly the most simple way in.  If SophCo were to somehow make this an impossible solution, there are other ways in.  The computers I was using had compilers on them, which means you could write a program that you would be able to run while Protec was loaded.  Combining this fact with some truly artful programming, you could probably gain access to the security system enough to copy it out and set it up in a safe place to hack at it at your leisure, rather than risk being caught, which is always stupid if it can be avoided.

The information contained within this article was not meant for use in a destructive application, merely for the satisfaction of curiosity and entertainment.  Lord knows, those are the only two reasons I've ever done this!

Have a marvelous time.

boot-saver.pas:

Program Saveboot; Uses DOS, CRT; type sectortype = array[0. .511] of byte; var sectorbuffer:sectortype; filename:string; bootfile:file of byte; regs:registers; x, option, drivenum:integer; continue:boolean; Function Sector_Read (D, T, H, S : integer):byte; begin with regs do begin es:= seg(sectorbuffer); bx:= ofs(sectorbuffer); ch:= t; cl:= s; dh:= h; dl:= d; ah:= 2; al:= 1; intr (19, regs); end; SECTOR_READ:= regs.ah; end; Function Sector_Write (D, T, H, S : integer):byte; begin with regs do begin es:= seg(sectorbuffer); bx:= ofs(sectorbuffer); ch:= t; cl:= s; dh:= h; dl:= d; ah:= 3; al:= 1; intr (19, regs); end; SECTOR_WRITE:= regs.ah; end; begin fillchar (regs, sizeof(regs), 0); repeat repeat clrscr; writeln; writeln ('Boot Saver 1.0'); writeln; writeln ('1) Read and save boot sector'); writeln ('2) Load file and overwrite boot sector'); writeln ('3) Quit'); writeln; write ('Enter Option: '); readln (option); until ((option > 0) and (option < 4)); if option = 1 then begin writeln ('Enter drive to load Boot sector from (0=a, 1=b...)'); write (' : '); readln (drivenum); write ('Enter filename to save to: '); readln (filename); assign (bootfile, filename); rewrite (bootfile); if Sector_Read (drivenum, 0, 0, 1) = 0 then for x:= 0 to 511 do write (bootfile, sectorbuffer[x]); close (bootfile); end; if option = 2 then begin write ('Enter file name to load from to: '); readln (filename); writeln ('Enter drive to overwrite Boot sector on (0=a,1=b)'); write (' : '); readln (drivenum); assign (bootfile, filename); reset (bootfile); for x:= 0 to 511 do read (bootfile, sectorbuffer[x]); close (bootfile); if Sector_Write (drivenum, 0, 0, 1) = 0 then writeln ('OK, all done.'); end; until option = 3 end.

Code: boot-saver.pas