Noggin' Cracking

by Fidel Castro

     I'm not some kind of stinking C programmer.  At best, I can be called a
scripter, and compilers give me the willies.  To top it all off, I'm a Mac
user.  This places me square in the middle of the "non-cracking bozo" 
demographic.

     Bullshit.

     This brief article will explain the principals of "Noggin' Cracking" -
the process of breaking certain kinds of software protection using nothing
(much) besides the gray stuff underneath your hair.

     I'm going to dispense with all the specious rationalizations for cracking
software.  Software developers work hard, deserve recompense for their labors,
and so on and yakketa yaketta.  Who gives a shit?

     Let's take an example:

     A shareware fax program for the Mac - ValueFax - is shipped over the net
as an expire-ware package.  You send 20 faxes and bang, it shuts down.

     Here's how I cracked it:

     I reasoned that ValueFax must be altering a file somewhere on my hard
drive every time I sent a fax, and that file must be queried every time a new
fax was queued so that the fax driver could make sure that I hadn't used up my
20 fax free ride.  So my first task was to uncover the name and location of that
file.

     I queued and canceled a fax transmission (I knew from experience that 
ValueFax checked the file before the fax was sent, since the "Pay your
shareware fee, you asshole" warning came up before the modem started to squeal).
Then I flipped back to the Finder and opened up my hard drive icon.

     By sorting the list of items by data, I was told which folder the most-
recently modified file lived in.  Turned out, it was the System Folder.  This
is the favored home for all kinds of useful files - the file with the serial
number for your copy of PhotoSlop, your MagicCookie file from Nutscrape, and
so on - and should be studied and worked with by the devoted Noggin' Cracker.

     Opening the System Folder and sorting it by date told me that the most-
recently modified lived in the ValueFax Folder.  Opening it and sorting it by
date told me that the most-recently modified file on my disk was my ValueFax
PhoneNumbers.

     Ponder on that for a moment.  You PhoneNumber file is the one 
indispensable component of a fax program.  If you're a fax junkie, re-entering
a couple of hundred phone numbers is a flaming pain in the colon.  A smart
place to hide the faxes-sent counter.

     I pulled the PhoneNumber file out of the ValueFax Folder and stashed it
on the desktop.  From the Finder, I faxed and canceled the contents of an
empty folder - the fastest way to spool a document for a print device - 20 
times, and the software let me.

     Bingo.  I had found the fax counter, and found how to reset it to zero.

     However, there is a civilian casualty in this solution.  Trashing your
PhoneNumbers database to reset your counter is a Pyrrhic victory at best.

     I trashed the new PhoneNumber file and sent a single fax.  I moved it to
a new folder, and renamed it "One."  Then I sent two faxes, moved the
PhoneNumbers file to the same folder and called it "Two."  I did that a bunch
of times and generated files at ten, fifteen, and twenty.

     Now I tried opening these files up with BBEdit Lite, a shitkickin' text
editor (www.barebones.com) and used the built-in "Find Differences" 
utility to find the differences between each file.  There were none.

     I began to doubt my sanity.  I knew that the faxes-sent counter lived 
somewhere in the PhoneNumbers files, but a one-sent, 10-sent, and 20-send
version of that file seemed identical.  Then I remembered the resource fork.
Mac files have two components: a data fork and a resource fork.  Usually, 
data forks are used to store data, and resource forks are used for common
Mac resources: icons, sounds, pictures, video, and so on.

     So I opened the files up with ResEdit, the free utility from Apple for
editing resource forks.

     Bingo.  There was a resource for each file that varied from file-to-file.
The data in the resource was encrypted - nothing as simple as the numeral 20
in the "20" file - but who gives a shit?  I had the resource value for one in
the "one" file.  I copied it and pasted it into the "20" file, then replaced
the PhoneNumbers file with it.

     Sure enough, I was able to send 19 more faxes.

     I used ResEdit to change the creator of the PhoneBooks file to ResEdit -
this means that double-clicking the file would open it in ResEdit.  This I 
copied the "one" resource and stashed it in my Scrapbook - where it would be
easy to get to - and put an alias of the PhoneNumbers file in my Apple Menu 
Items folder.  Since then, whenever I hit 20 faxes out, I open the PhoneNumbers
file from my Apple menu, pop up the Scrapbook, copy, paste, and save.

     The principles that can be extracted from this are universally useful,
and will work on any platform.

     First of all, think about where the protection that you want to remove
must live.  This is especially easy to find with expire-ware, especially
time expire-ware.  Set your clock ahead by a couple of days and see which
file changes.

     Secondly, make multiple copies of that target file, at different stages
of expiry.

     Thirdly, compare these files to discover how the expiry date is being
calculated.

     Lastly, remember that you don't need to undertake lengthy decryption to
figure out what scheme is being used to calculate the expiry condition - it is
sufficient to transplant the initial value in an unexpired copy into an
expired copy.

     Happy cracking, kids, and viva Cuba libre!