Floppy Disk Preservation Project
PirateBusters, Inc.

Interview done by Kevin M. in Oct-Nov 2008

The following is an interview of the 3 guys behind PirateBusters Inc:
Kevin P. Pickell, Brian R. Niessen, and Kris Hatlelid.

They did copy protection for C64 software, and also were involved in game
development (think Test Drive, Gran Prix Circuit, Frantic Freddie etc)

The interview was done via email and compiled as shown below. For some topics I
asked follow-up questions, or questions to certain individuals (i.e "To ______"
prefixes the question). Any of my comments or additional notes are enclosed with
< >.

Keep in mind that considerable time has passed since these guys did C64 stuff,
but they were all gracious enough to respond to my questions. I would like to
say "thank you" to Brian, Kris and Kevin for helping me preserve a little bit of
computing history. - Kevin M.


What led you to C64 software development? (instead of other systems like Apple,
Atari, IBM etc?)

BRIAN:
My first computer in 1976 was the Commodore PET, then the Commodore VIC-20. I
beta tested the C64 (Mine first one was in a VIC-20 case).

KRIS:
We had PET computers in the schools, so it was kind of brand recognition.
Additionally, I had a Vic-20.


How did you do software development for the C64? Were there any cross
development systems or special hardware used?

BRIAN:
Originally I used the 'off the shelf' tools, but then Kevin Pickell and I
created a system called "TSDS - Total Software Development System" that included
an editor, assembler, sprite editor, etc.

KRIS:
Sysres, TSDS, later an amiga cross assembler system.

KEVIN P:
We used a 6502 macro assembler that I wrote originally on the Pet and then over
to the C64 (it was called TSDS, for Total Software Development System). During
the DSI/EA time I converted it to run on the Macintosh and we used Macs for C64,
Apple and Atari development.



What made you get involved with disk drive stuff (disk utilities, etc)?

BRIAN:
Curiosity and need - When I had my PET, I had the 8250 floppy drive (1 MB of
storage on a floppy in 1978 or 1979), and one day the power went out as I was
writing a file. It destroyed the directory track on the floppy, and to recover
the months of work, I had to learn how to rebuild the directory track by hand.
That was the beginning of realizing the "power" of the external floppies - they
had multiple CPU's, etc.

KRIS:
I wrote a game and wanted to protect it (Frantic Freddie). Greg Larson actually
was instrumental in that, and with me being a programmer in general.

KEVIN P:
I was always interested in speeding up things and since the disk drive was so
slow I was very interested in speeding access up.


How did you learn about the inner workings of the 1541 (did you refer to books
like "Inside Commodore DOS" etc or just spent a lot of time hacking?)

BRIAN:
Lots of books, but a LOT MORE time disassembling. One weekend in about 1983 I
invited a bunch of hackers to the University of Victoria where I rented a room,
and we disassembled the entire 1541 ROM set and determined how it all worked.

KRIS:
Rom disassembly mostly. Started with the 4040 drive, and moved into the 1541.

KEVIN P:
Through a friend who worked with Commodore on a few projects I was able to get a
printout of the source code for the 4040 disk drive (this was a Commodore PET
drive). The 1541 code is very similar and by reading the code I was able to
understand a lot about how the drive worked.


How did you become involved with copy protection for the C64? (How did your
involvement with Piratebusters Inc start/end etc?)

BRIAN:
PirateBusters was Kevin and I initially, then we invited Kris Hatlelid into the
fray. How it started - Kevin and I were known "breakers" who thought that there
was a better way.

KRIS:
I wrote some stuff to protect Frantic Freddie. Later, I theorized about a
protection system with Brian Niessen at a trade show in Toronto, and I joined he
and Kevin a little while later.

KEVIN P:
Pirate busters was Brian Niessen, Kris Hatlelid and myself. Kris and I had few
different ideas for copy protection that we had done for some of our own games
and Brian was our "Sales Guy". We decided to shop it around and it was installed
on a half dozen or so games.


How many games were protected with PirateBusters? (I know "Beach Head 2" by
Access has that nice piracy message screen that came up on a copy).

BRIAN:
How many - Honestly, don't remember - we licensed to EA, Access, and a couple
other companies and can't remember which games anymore - I know that it was also
used on .... what was the name, the one where you had the miners on Mars or
something. I saw it in a local used-computer-store here the other day
actually. I should go buy it.

KRIS:
Dunno, sorry. ;-)

KEVIN P:
I think we did a couple of games for Sydney Development and a few for EA, and I
guess a few for Access but I don't remember.


How many versions of PirateBusters were there? (BH2 displays "Protected by
PirateBusters 1.0FL" (Additionally you wouldn't happen to have any source code
or work disks lying around, would you? ;-)

BRIAN:
I don't recall. Don't have any code anymore.

KRIS:
I don't know. Sadly, I don't have any of my old source code. I did find the
cartoon that I wrote for PirateSlayer though, that was hillarious <Note: see
further on below for more info from Brian on the "cartoons">

KEVIN P:
I don't remember.


What were the sorts of technical things you did or checked with your protection
schemes? (Bad GCR, gap bytes, no-sync tracks etc). What did you do to discourage
prying eyes? (encryption or other tricks)

BRIAN:
We did things like spiral tracking (like a CD) on the floppy drive. We also did
load-under schemes, where we loaded code under the roms, and then when the
loading wrapped around $FFFF and hit $0000 it kicked out the roms, and started
our code (which was right under the ROM load code) - this was Kevin's piece' de
resistance ;)

KRIS:
Mostly it was no sync variations and track alignment variations.

KEVIN P:
The one I remember the best was we had our own "wide track" with custom sector
format. The track was from 36-38 so it was actually 3 tracks wide and we would
make the code randomly check by seeking anywhere from 36, 36.5, 37, 37.5, 38 and
then looking for our data there. The sector on that track was our own 1024 byte
format ( normal sectors are 256 bytes ) with our own custom non-standard sync
header. The unique thing though about this protection was that we didn't just
check for it's existence, but we actually loaded code from that sector and that
code was integral to the startup process.

As for stopping prying eyes, the one thing I did was to use the 6526 timer chip.
I would have a loop of code that turned on the chip to start counting, then I
would read the values from the chip as they were changing (they incremented
every cycle) and exclusive or'ed them with the code directly following my loop.
Once the code had finished exclusive or'ing the code it continued to execute the
code that it just un-encrypted and it did the same process all over again about
8 or 9 times before the final code would be un encrypted and executed. The idea
was to stop two things, first, if they used a debugger and placed any
breakpoints then the values from the chip would continue incrementing and there
would not be a match and the unencrypted code would be garbage. Second, they
could not put a breakpoint at the first instruction after the loop since that
value was changed by the decrypt code and would no longer be a break
instruction. It would certainly stop an amateur hacker but not someone who was
an expert. The other thing we did was use a bunch of the undocumented opcodes
that did give consistent results and this would also slow down someone trying to
read the code.


Did you ever disassemble copy programs to figure out their limitations in
devising protection schemes? (Or evaluate other hardware tools like parallel
drive copying tools (Burst Nibbler, 21 second backup etc) or drive ram expansion
(RAMBOard/Supercard etc)

BRIAN:
Definitely.

KRIS:
No, just tried them. I did discover later that some people actually used
debugging hardware to figure out copying methodology, which was kind of
annoying. ;-)

KEVIN P:
Nope.


(To Brian/Kris):
In "Beach Head 2" the piracy screen mentions "Kevin P. Pickell" and "Brian R.
Niessen". What was your role in PB Inc?

BRIAN:
Kevin and I coordinated on the design and implementation - Kris usually did the
graphics for the "you got caught" cartoons. Kevin would write the code for the
protection, and I'd write the code to "create" the disks (fat tracks, spiral
tracks, etc). We would use Pet 4040 drives to do the duplication usually.

KRIS:
I came on later, and eventually took over doing the EA protection.


Any secret messages you put into your code? (I seem to recall a message like
"Hello hacker what are you doing in my code?" in some disk but I'm not sure if
it was one of yours)

BRIAN:
Always ;) We put the "honeypot" code that we expected to be broken, then we'd
put in a cartoon or message telling them it was broken, THEN there would be the
layers of real protection.

KRIS:
Yeah, had quite a few. Don't remember much about them now though.

KEVIN P:
I do remember putting in messages but I don't recall what they were.


What was the effect of piracy on the market back then? How much time did copy
protection buy before cracked copies started circulating?

BRIAN:
Nothing close to what it is now - no Internet, etc, do it was usually localized
copying and/or BBS systems. Also, with 300 and 1200 baud modems, it took a long
time to upload/download 170K. My estimate, it didn't make a lot of difference
though, since the people who cracked or shared cracked programs wouldn't
necessarily buy them anyway.

KRIS:
Depended on the game. The reality is I don't think protection ever buys you
more than a few months, but for a game that can be enough time to make your
money back.

KEVIN P:
I don't know, it was probably one a month or so before most games were cracked.


Harald Seeley (guy who did V-MAX copy protection) mentioned once that software
companies used to view V-MAX cracked copies as a preview copies, as the 1541
drive was so slow and V-MAX had a fastloader (the cracked copies would load at
slow 1541 speeds). Was this the view of other companies as well?

BRIAN:
No idea - but as part of PirateBusters, we included a high-speed loader.

KRIS:
Not that I know of.

KEVIN P:
I don't know about that.


About the financial side of "Piratebusters Inc" was it a successful venture? How
profitable was supplying anti-piracy services to EA and other companies? (If
you'd rather not discuss specifics that's OK)

BRIAN:
It paid the rent and bought Slurpees at 7-11, but none of us became rich over
it.

KRIS:
Not really profitable. It was kind of a side venture. The good news is that I
got into the game industry, which turned out to be a pretty decent career.

KEVIN P:
It paid the rent for a few months but was not really worth our effort so that is
why we switched to writing games.


Any memorable or funny stories from the C64 days?

BRIAN:
Millions, but let's fast-forward a bit - here we are in 2008, and I have a C64
emulator on my Sony-Ericsson P910 phone, so I can relive it anytime, any place.

One of them, I guess, is that one way on the ferry to Vancouver Island, there
was Kevin and I and a couple other friends. Kevin and I had the SX64 luggable
and were playing games. Two kids came up and said "Hey, Kevin Pickell said
you'd give us some games for free."... I pointed at Kevin and said "That's
Kevin"... the kids went red, and one said "No, no, it was Brian Niessen who said
that"... Kevin pointed at me... the kids hightailed it out of there with a "Ahh,
we gotta go..."

KRIS:
When I wrote Frantic Freddie, I remember having to cool the 1541 drives in the
fridge between assemblies, because I'd melted a couple in the summer. Most of
my really good memories are around writing music for the games, and developing a
midi system that allowed you to play the C64 or nintendo, or whatever using a
midi sequencer / keyboard. I think it was significantly before anyone else had
done anything like it.

Well, Brian and I kind of drove Kevin and his wife crazy. I feel bad about it
now, but back then we thought it was funny. Things like having a modem dial the
house at random times and hang up, putting shoes in the freezer, kidnapping
prized dolls from his wife's collection and demanding ransom. I remember
driving down to EA the first time with Kevin from Vancouver to San Francisco and
trying to deal with all the disk duplicator problems with no sleep. I blame all
the craziness on Brian.

(Subsequent comment by Brian when I asked him about it):
BRIAN:
Comment - Hmmm, IT'S ALL TRUE!!!

Putting his fiance's shoes in the freezer cost me being Kevin's best man at his
wedding.

KEVIN P:
Not that I can recall.


If you could do it all over again, what about the c64 days would you change?

BRIAN:
Not much - it was a great time.

KRIS:
Ha! Not much. The kind of things I'd change just come from the wisdom of being
old now. I can still code 6502 in hex from my Pet/Vic-20/C64, which isn't super
useful, but it did help me be a much better debugger even today. The protection
thing on the C64 eventually took me to a large company in the pacific northwest
where I manage developers doing security technology, so I guess I've done ok
from it. ;-)

KEVIN P:
At the time I was very young and probably too trusting. We got ripped off by a
few people who never paid us for work done and in hindsight I would have focused
more on the business and contacts side of things.


(To Brian)
Kris Hatlelid did "PirateSlayer" protection that was used on late EA games. Know
anything about this protection?

BRIAN:
Kris and Kevin went to work at EA, so it's possible. I went in other
directions, doing coding for Amiga.

(To Kris)
You did "PirateSlayer" protection that was used on late EA games. Could you talk
a bit about it? What were things that you did/checked? How did you make it
difficult for crackers? (Checksums, self modifying code etc).

KRIS:
Yes. Not much to talk about, Kevin and I basically wrote a complex wrapper of
goo that left breadcrumbs around the system dealing with protection state, some
obvious, some non obvious. The most interesting thing about it was that we had
N layers deep of self decrypting self modifying code that was timing dependent,
meaning if you tried to debug it, it probably wouldn't work. It was actually a
two step process to prepare, and that made it difficult for developers using it.
Some of the interesting breadcrumbs were timer state and SID state that you
couldn't actually read and restore.

(To Kris)
Since you (and Kevin) worked for EA, do you know why most EA games didn't have
built-in fastloaders?

KRIS:
The ones I protected did as I recall.


(To Brian)
Attached is a screenshot of the Beach Head 2 "piracy" screen, the following is
the text that's scrolled: (does it bring back any memories?).

Once upon a time in a far away place some smart people got together and created
a device called a computer. The main reasons that they created computers were
for military purposes. But then computers were made smaller and cheaper, and
became more commonplace in business environments running accounting and database
software. Computers soon became so inexpensive that they were named "Home
computers". Now computers were used for playing games and teaching. Once
computers were in the home, many individuals saw that computers needed good
software. They decided to write programs (including games) to run on the
computers. They wrote up manuals for the programs and designed some neat
packaging and invested a lot of time and effort into the package. But then the
hard part came. They had to present their ideas to a company, and hopefully the
company would agree to sell their product. If there was no such company around
then they had to start one of their own up. This required capital, time and
business acquaintances that would represent the product to stores etc. After all
this is done the program must be good enough so that the public will recognize
its potential and buy it. The public usually recognized the potential of a good
product, but the number of people that buy the product is usually a lot lower
than the number of people that have a working copy of the program. you may ask,
how do they get a working copy of the program without buying it? Well they find
somebody (a friend?) who bought a copy of the program and they try to copy it.
The main ways for software companies to protect their software is to write out
information on the diskette in a non-standard format. Then when a copy program
looks on the disk for the information stored in the normal format it doesn't
find it all and misses some vital information that the program requires to
function. Most programs when run usually check for information on the diskette
and if it is not there they assume that the diskette is a copy and come up with
a message like: ** Copy Detected, Loading Aborted ** Others load up the program
but they don't let the program function properly. Well finally others programs
like this one just tell you the facts about piracy, and hope that your
conscience does the rest. Welcome to the wide world of piracy. Yours truly,
Kevin P. Pickell and Brian R. Niessen, Piratebusters Inc.

Nine out of ten pirates go blind trying to copy our software.
The other one gets committed!!!

BRIAN:
haha, Now I remember - hilarious.

That was in response to [Access] saying out "Graphic Cartoon" was too "graphic"
(We had blood and gore, killing pirates...)

Mike J Henry was the hacker we killed in the Cartoon.
[Note by Kevin M: Mike J. Henry is probably best known for authoring the "Fast
Hack'em" copy program]


(To Brian)
Was there competition between you and Kevin (and later Kris) in terms of writing
code or alternatively trying to break code written by them? (i.e. trying to
"one-up" the other in terms of ideas or implementation).

BRIAN:
Competition between us, not really - but a good "teamwork" to get the best
thing.

With the three of us, we lived together, so it was a 24x7 brainstorm. Lots of
Coke (cola) and Rootbeer and 3AM walks to 7-11.


(To Brian)
The program that would create the originals on the 4040, was it protected? ;-)

BRIAN:
The program to create the originals on the 4040 was in our possession only -
we'd send a master to ACCESS/EA usually, and they'd use imagers to write the
whole disk.

...And that's it!
Thanks again for the interview guys!
---
Apple ][ Registry Stats
Total Registered: 98

Top 5 Earliest Serials
Douglas Ward: A2s1-A2S1-4714
Unknown: A2S1-0001
Jef Raskin: A2S1-0002
Bob Bishop: A2S1-0013
Achim BaquƩ: A2S1-0025

Latest Serial
Paul Hagstrom:
A2S2-1497165

Register Yours Today!
C64 Registry Stats
Total Registered: 2509

Top 5 Earliest Serials
Unknown: 0019
Charles Lynch: 0021
John Justice: s00001281
c64web.com: S00001390
Matteo Caccia: S00001576

Latest Serial
Sos:
HB41651823E

Register Yours Today!
Disk Database Stats
Titles archived: 3532
Titles verified: 1348

View/Query Database
User Account
Greetings, Guest.

Login
Reset Password
Create New Account

Browser cookies are required for these functions.
Facebook
Find me on Facebook
All content copyright (c) 1971- by Peter Rittwage. All programs mentioned are copyrighted by their respective owners.