A Simple Hex Hack

by Zarathustra

This is a pretty simple spoof on a date value stored in the Windows Registry and is written as simply as possible which is a pretty weak hack, but when I was just getting into the scene, I would have loved to have found an article like this, partially as a good example of how to proceed, but mostly as a confidence booster.

Doing the hack yourself makes you understand what's actually going on and gives you the confidence that you can succeed.  The key is that it's so simple to do that you don't need to understand assembly language or how the V-table is set up, nor do you need any specialized software so there are no roadblocks to keep you from doing this.

Hex Workshop's Registry Based "Security"

Hex Workshop is a hex-editing program for Windows 95 from BreakPoint Software.

When I downloaded the trial version of Hex Workshop v2.54 (not the newest one because it can fit on a floppy), and installed it (no EBCDIC support), it told me that I have a 90-day trial edition of this software.  Fair enough.

The next time I ran it, five seconds later, it told me that I had used up my 90-day trial, and that I had 14 days to register.

Next, it told me that I have totally expired my trial and that I had to buy the software.  This really raised my interest as to how this product was calculating time, and so, assuming that my clock being set to May 11, 1980 was a root of the problem, I started to investigate.

Hex Workshop has two different security mechanisms built in: the first one is so that you can insert your serial number in order to enable the full version, and the second is to disable the product once you've used it for more than 90 days.  This article focuses on the second.  

The great thing about cracking non-network enabled software is that you have the entire puzzle in front of you, and all you have to do is understand what's happening.  If you don't understand what's going on you have no hope of ever cracking it.

Because this program is time limited, it must have a date stored somewhere.  If you can find where the date is stored and how, you'll be a lot more successful modifying that than trying to directly modify code.

Good targets are small, suspicious files in the program directory and the Windows Registry.  In this case, running REGEDIT, and looking at HKEY_LOCAL_MACHINE/SOFTWARE/BreakPoint/Hex Workshop/2.50 reveals the keys Major and Minor.

Taking a wild guess, I erased them, then ran Hex Workshop which told me that this was the first time I had run the product.  Bingo!

The next time I ran Hex Workshop, it told me that I had 14 days left to register and the next time it told me that I had used up all of my time.  This was obviously the pertinent data.  It was starting to look like there wouldn't too many pieces to this puzzle.

After much experimentation with changing the windows system date and seeing the effect on the keys, I learned that:

The Minor key had to do with what step of the security process you were at:

Minor Value     Means
00000000        Still Free
AA000000        14 Days Left to Register
BB0000000       Locked Out!

When the program hit the 14 day point, it changed the Major key, which I ended up never bothering to explore.

If the date is set to before January 1, 1990 then running Hex Workshop advanced the Minor value by one each time.  If the date is set to after Jan 18, 2038 then Hex Workshop crashed every time.

Advancing the date by one decremented the fourth bit by one.  Advancing the month by one decremented the second bit by one.  Advancing the year by one decremented the last bit by one.  Deciphering what I assumed would be an encrypted date was starting to look a lot simpler that I had thought.

O.K., so here's the Major key formula:

MMDDYYYY

YYYY             Means      DD          Means         MM       Means
F843             1980       E0          31            FB       Jan.
F842             1981       E1          30            FA       Feb.
F841             1982       E2          29            F9       Mar.
.
.
.
F839             1990       EF          16            F6       Jun.
.
.
.
F810             2037       FD          02            FD       Nov.
F809             2038       FE          01            FC       Dec. 

Which means that date and month are 0xFF (hex) minus the MM or DD, then converted to decimal, and year is 0xFFFF - 0xDDDD converted to decimal.  Other than the sneaky month thing this could be a Windows default encoding.

Although one could easily write a program to write yesterday's date to the Major value using RegOpenKeyEx, it turns out that writing 0x000AAAAA to the Major key and 0 to the Minor will always avoid the date check problem.

Unfortunately, it doesn't stop the program from crashing after January 18, 2038 or from resetting the Registry values if used before January 1, but in order to fix that we'd have to debug other people's code, which is beyond the scope of this article.

I hope that this was an interesting introduction to the exciting world of cracking software.

Although this was definitely beginner level and most projects are a lot more complicated, the same basic techniques can be applied to a lot of software.  The key is to be able to recognize when to switch from modifying data to modifying code.  With an increasing emphasis on modular software development, software tends to have lower cohesion, making it way easier to modify with no side effects.

With super-high pressure on programmers, a lot of shoddy code gets released.So if a product has encrypted data you might as well check the binaries for security holes.  In addition, you'll find that as you trace through more software, you'll develop a greater appreciation for why and how Windows works.

Return to $2600 Index