Way back when monetized flash games were a thing, there was a problem of ad piracy (people who would decompile your game and then upload and monetize it as their own). The conventional wisdom at the time was that piracy could only be delayed, not prevented. The reasoning was that a piracy check has to read the sites URL at some point and the hacker can just search for the only command in all of actionscript which does that.
My game contained a very standard check url type protection. This was not the real protection. This was the piece of code which the hacker was supposed to notice and remove. Early on in the game there was a function call to get the total number of bytes in the file and then divide it by the number of expected bytes. Ostensibly this was to calculate the size of the loading bar. I stored this information in a forgettable global variable. On the surface this looks like the sloppy coding one expects from flash devs. But the real purpose was so that I could later check if this number was not 1.0 and trigger the true copy protection. Long story short if the number of bytes were incorrect then the game becomes unplayable after a few levels. I thought that was a nice touch since these hackers usually didn't play though enough of the game to test if their hack worked.
This reminds me of the write-up I saw about the Spyro games for Playstation. It has a similar result where a copied game would progressively become harder and impossible to beat. They had the same reasoning, most people pirating/patching the game won't play it all the way through before releasing their results.
Its all very clever. Till it doesn't work. A long time ago, we got EA's "seven cities of gold" from my parents for apple.
My brothers and I were all excited but it would start to load then the drive would make a strange sound and it didn't work. We exchanged at the local software store, the next one did the same thing.. We tried on a friends apple //c and it worked there. Our //e drives must have been slightly out of spec.
It was bitter disappointment. But a valuable lesson.
They're now imaging floppies into new formats so the copy protected disk can still run in emulation:
My favorite copy protection was on some games I had (I want to say they were Microprose games? But I could be wrong) where they would cut the hole in the disk just slightly bigger, and then take advantage of the fact that in DOS you could talk directly to the hardware to convince the read head to go just a little too far. Then it could read the magic 41st track to load the game, but no disk copy program could copy it.
My favorite one is the spiral tracks on the Apple II, which were possible because all phases of the stepper motor were directly accessible on the controller, so you could move the stepper motor in quarter tracks.
Impossible to copy unless you reproduce the head movements at the right time.
Some of the "floppy extender" programs used more than the usual number of tracks, so unless the 41st was hidden somehow so that its existence was a secret, it would be no harder to copy than all the others.
Of course, that may well be why it was so successful --- the extra track wasn't well known, and information travelled much slower back then.
Well, it was 30 plus years ago, but what I remember is that at first it was just the games that were doing it, and then people figured it out and made those other programs, making the copy protection useless.
There was a similar situation with CDs where you could overprovision data that existed past the technical limit of useable range. I think that's was utilized in NINs Year Zero ARG experiment.
Who recalls the provenance of this old legend about the fellow who challenged his pal to decode a certain floppy?
It was a bog-standard DOS boot disk (IIRC) that he could put in his machine and boot normally. But his pal put it in his computer and... nothing doing, no boot. Analysis of the floppy availed not. The challenge went unmet.
What did our hero do to make the floppy?
.esrever ni nups evird eht os ytiralop etisoppo htiw meht dehcattaer dna ,rotom eldnips evird eht ot seriw rewop eht deredlosed ,evird ksid eht denepo eH
My father bought a 386 for his work to replace a 286 which only had a 5.25 floppy drive. The 386 had both a 3.5 and 5.25 floppy drive so he quickly switched to the more sturdy 3.5 disks and moved a lot of work to the 3.5's.
Everything was working great until he got a second similarly spec'd 386. For some reason the machines couldn't read each others 3.5" disks. So he called his programmer friend who stopped by and did some testing. Both machines could format/read/write their respective disks no problem. So he formats and writes a test file to a disk from each machine and takes them home with him.
My father gets a call from him the next day: "call the vendor and have them give you a new 3.5 drive in the original machine" Turns out the heads in the original machines 3.5 drive were slightly misaligned mechanically to the tracks. This caused the disk to be perfectly workable in the bad drive but fail to read in any other machine.
Somewhat related, but as 800k floppies got harder and harder to find, it became common to just cover one hole on a 1.44 mb floppy so the computers that used them (mostly old compact macs) would treat them as 800k disks. This is fine in the short term but since the tracks and what not don't line up quite right it'll usually degrade over time.
This remembered me when I had a ZX Spectrum +3 as child. At some point, a belt broken and my father replaced with a different belt. So, it can't read anymore my old floppies. I can only use the floppies if I formatted again.
I didn't want to make up details. I'm asking if anyone recalls the origin ("provenance") of the original story.
IIRC, the friend did various things to the disk to try to figure out what was up.
Think how crazy this magic trick was: you can literally watch it boot a machine, but then put it in another machine and it's just garbage, that should be impossible...
> He opened the disk drive, desoldered the power wires to the drive spindle motor, and reattached them with opposite polarity so the drive spun in reverse
It'd take some doing. You wouldn't be able to burn a CD-R backwards without some extra steps; a "blank" CD-R contains some data in the pregroove to identify it as a recordable disc and specify some parameters to the burner. A reverse-rotating drive wouldn't be able to read that data, since it'd be backwards. :)
Presumably if you'd also flip the phases on the head stepper and move any relevant endstops around you might be able to convince the drive to read disks inside-out.
Fairly sure it'd immediately give up due to pregroove shenanigans but it's an amusing idea.
Slightly off-topic, but since when were floppies referred to as "disc", as opposed to "disk"? I thought it was from Diskette?
Is it a language / region thing?
Optical discs were "disc", but at least growing up in the UK in the 80s/90s with DOS/Windows, I'm pretty certain I remember them always being "disk" for floppies?
1947 Math. Tables & Other Aids Computation 2 229 The program of the Symposium was as follows:..4. ‘Magnetic and phosphor coated disks’ by Dr. B. L. Moore.
1952 Electr. Engin. (U.S.) Aug. 745/2 When the heads are in position, the disk is rotated past them while information, in the form of coded magnetic pulses, is recorded or read out.
1964 T. W. McRae Impact Computers on Accounting i. 8 48 disks were stored one above the other.
1972 Computer Jrnl. 15 290/1 Engineering information files set up on disc by Hawker Siddeley Aviation Ltd..form the data base for a fully integrated production control system.
1982 What's New in Computing Nov. 12/4 Back up for the discs is provided on a tape streamer, tape cartridge or floppy.
1990 G. Gilder Life after Television (1992) iii. 63 A computer with a hard-disk memory, together with a compact disc read-only memory.
The last one has K for magnetic disks and C for optical discs.
> The last one has K for magnetic disks and C for optical discs.
The Wikipedia article affirms this convention as well, which begs the question: solid state disk drive? solid state disc drive? solid state brick drive?
I read somewhere a long time ago (I forget where) that it was (or tended to be) "disc" where the format came from the audio world, and "disk" otherwise. So, "Compact Disc", but "hard disk". No idea if this is rubbish or not but maybe it jogs someone's memory.
The way I was taught was that "disk" is when you don't touch it directly (disk drive, floppy disk) and "disc" is when you can (compact disc, frisbee disc).
> But then if floppies are diskettes, what's the non-'ette' disk referring to
Fixed disks (which were also quite large at the time.) Floppies were removable disks, like cassettes; disk + cassette = diskettes, also disk + dimunitive -ette = diskette.
Yeah, it's probably relative, I've rarely used disks larger than the 8" floppies so would never call them diskettes, the 5 1/4" were commonly called that in my circles. In IBM circles of the time they'd have a different default scale.
Like I remember being surprised the first time I heard someone refer to AA batteries as the big kind.
We also used hard disk/floppy disk here in Europe (NL). My recollection is as the GP says, "disc" was only consistently used for optical discs (CD, DVD, BR).
It may still be that "disc" is European in origin -- the original CD came from Philips (NL) and Sony (JP) -- but for computer components, I've never seen it spelled "disc".
This is so off topic and/but (currently) still the top comment.
Since when would anyone remember how to properly write something, when the representation he has is the phonetics in his head?
Nobody thinks "It's disk, because it comes from diskette."
Why do people argue as if anyone would think like that? - Though I don't doubt that it's the origin. Are we supposed to know the origin of (every)thing(s)? - We mostly don't.
To then write it "disc" makes sense, except you are from Germany.
To then pseudo-intellectually pretend that people know whatever and what not and don't rather go by guts feel (what it sounds like) is blatantly dishonest.
20 posts in two years and you use 21 to complain this is still off topic post is still #1. Drop a parent level post if you have something better to discuss, don't reply on this post saying this doesn't meet your standards
Modern copy protection techniques are often based on this same principle. For example, the GameCube and Wii do a very similar thing. Since they use optical media, that doesn't have tracks but instead a single spiral groove, what they do is use a laser to burn little scratches into the disc (which you can see against a light). After mastering and lasering, the disc is checked to see what sectors the marks damaged. Error correction ensures the data is undamaged, but the drive can find these drop-outs. Then a table containing the sector locations is encoded and burned with the same laser into the "burst cut area", effectively a standard barcode format in the inner ring of the disc (this part is standard, many normal drives can read BCAs).
This all works because the specific angular position of any given sector is unpredictable during optical disc mastering. The groove is continuous, and never lines up in exactly the same way. So, just like the floppy trick, this is "fingerprinting" the natural variation in write speeds of different disc mastering/burning systems. This scheme is undefeatable using off the shelf burners, but one trick that Datel used to master compatible unofficial discs is to rip the encrypted BCA table off of a real game (so they didn't have to crack the encryption, though that was possible later since it's symnetric) and, instead of burning marks into the disc, just turning off the mastering laser writing the disc track at the exact same points in each track. Those discs don't have any holes, but they have a pattern of sector damage that is indistinguishable to the drive (even though the angular positions no longer match), and they work. I believe the same trick should work with a lightly modified standard burner, if you can manage to find a way to burn the BCA (and you need other firmware patches for some other data-level changes to the disc, but those are easier).
Xbox (360 and One discs at least I believe) also do this IIRC, but instead of intentional damage the drive has the ability to compute angular relationships between sectors I believe, though I'm not familiar with the details of that scheme.
Back in the 1980's I think there were a lot of interesting schemes.
The solution was to just get an updated version of copy2pc or copywrite and they would have a fix.
But I remember a few schemes that were interesting workarounds.
One was the hole in the disk, one was a laser-burned dot on the disk.
I recall with the hole in the disk - the software would try to read and if it succeeded it was a copy.
The second one was slightly different and I believe the software would write to it, and read it back, and if it could read it back it was a copy.
However the best of all was either the scratch-n-sniff card from Leather Godesses of Phobos, or the Age Verification of Leisure Suit Larry.
example:
"Gone With The Wind" is about
a. outer space.
b. a bank robbery.
c. four hours long.
d. dust.
or
President Ford prescribed _____ for dealing with economic problems.
a. tranquilizers
b. employment
c. that everyone wear a WIN button
d. that everyone should have a nice day
It's also quite funny that Quaid (who made copywrite) was sued by a protection vendor... but won!
"We hold that: (1) Quaid did not infringe Vault's exclusive right to reproduce its program in copies under § 106(1); (2) Quaid's advertisement and sale of RAMKEY does not constitute contributory infringement; (3) RAMKEY does not constitute a derivative work of Vault's program under § 106(2); and (4) the provision in Vault's license agreement, which prohibits the decompilation or disassembly of its program, is unenforceable."
I played the modern version (Leisure Suit Larry Reloaded) a bit but couldn't complete the age verification because it relied on the American history and pop culture too much. Had to shamefully google the answers.
99% of the time when you got "random questions" like this in a game it was an anti-piracy trait. The idea was that people might be able to copy your disc, but they would be unable to play the game unless they could answer your questions - which would require the manual to be used.
(Bearing in mind that photocopiers were uncommon at the time.)
In the case of Leisure Suit Larry the opening questions were actually designed as an age-test. The intention was that "children" wouldn't know the answers and would be unable to play the "risqué" game.
At the time the game was released, the internet might be available in a modem that would go at the blazing fast speeds of a thousand bits per second. And of course, tie up your phone line in the process. The WWW hadn't been invented yet, let alone search engines.
Having been a kid during the formative years of the Internet, I can tell you that the notion of "you can find everything on the internet" doesn't really start coming into play until the early 2000s. In the late 90s, having to do research generally meant schlepping yourself to the library and finding encyclopedias or other research materials. Or, if you were lucky, maybe you had something like Microsoft Encarta, an encyclopedia on a CD-ROM!
If you got the software from pirate BBS, you would meditate on its file list to check for presence of notes, hints, FAQs and release info files if that information was not attached. Newsgroups/echomail could have it posted, too, routinely, or as an answer to someone's question.
That was a bit later, though. In the age of physical disk swapping, you would ask friends, or prepare for an audience with That One Guy Who Has Everything And Knows Everything.
I never did BBC Micro, but in the early PC days there were "Copy II PC" add in ISA cards that the floppy cable passed through on the way to the drive. With their software most any floppy disk could be copied with a standard PC drive; and with a bit of hacking you could do things like read Victor 9000 floppies.
There was only one floppy I could never get, a licensed Scrabble game that insisted on writing scores to its game disc. My mom loved that game and we had to buy it twice. It was humiliating, I had this special hardware and I never did figure that one out.
The "Copy II PC Option Board", yeah. I knew a guy who had one, and it definitely could handle a lot of stuff that you normally couldn't. Interestingly, you really wanted an early-era board because they were forced to water down the later revisions so they couldn't copy newer protection schemes.
My fuzzy recollection is that the option board could read the entire track at once, raw - not MFM decoded, where the typical controller in a PC had a high level interface that only gave you sectors.
One copy protection system that I remember was a track that had a mix of long and short sectors with the short sectors embedded in the middle of the longer ones. (Sectors header/footers were marked by special bytes that were illegal MFM coding.) If a program tried to copy the the track with a normal floppy controller, they would have more sectors than would fit on a track.
The original company got bought out by Central Point, they'd been running for a bit before then. They were not quite totally opaque in "API" then, there were like maybe 3 asm examples floating around BBS and net.* era usenet.
I remember my tech-savvy uncle was used to PCs which could read double-sided floppy disks. His jaw about dropped out of his skull when he saw me do the 0.5 second floppy-disk-flip that Apple IIc gamers got used to doing, because they could only read from a single side of the disk.
I remember a similar "easy to write, easy to read, hard to recreate" approach being touted for credit-card security a while ago. The idea was to embed bits of glitter in a clear epoxy matrix, and collect a "fingerprint" of the result when read from different angles. It would be nearly impossible to recreate the glitter pattern. I really liked the idea, but apparently they never solved the alignment problem well enough to make the "easy to read" part a reality.
IIRC, Quaid software's Copywrite on the PC was able to reliably duplicate weak bits, and had a companion called "zerodisk" which would -- in cooperation with marks left by Copywrite -- emulate laser holes.
I remember at least one copy protection system I analyzed, which get "free reign" into writing tracks, by configuring the drive to write just one huge sector per track (which ended up being longer than the track), end encoding the sector gaps "in band" which later became "out of band" because the main track header was overwritten (and an "in band" one became out-of-band).
It was interesting, but I have no nostalgia for that.
1. I love how half the comments here are about disc/disk, which was just a passing comment in the article.
2. I really like reading these sorts of stories where modern hackers figure out the tricks used in vintage technology. They're interesting, and makes me feel a little better that all the clever hackers haven't died off yet. Sometimes I feel like the power of modern computers has made people lazy and we're going to lose our ability for clever solutions. But maybe the clever people are still there.
3. If you like reading about copy protection and (I can't believe I'm about to call the PS1 vintage) vintage tech, you might like this story about the copy protection for Spyro on the PS1. It wasn't so much copy protection as it was punishment after the copying. https://www.youtube.com/watch?v=4GYSeXLr5sY
The other thing this scheme gives you is a unique image per customer, so you could use it to trace illegal copies.
When I worked on some expensive emulator software 22 years ago, floppy protection wasn't appropriate but I suggested to the boss that we use the order of linker symbols in the main executable to encode the customer's serial number.
I guess it was a No because they wanted to use a standard duplicator, but also piracy was pretty well deterred by the 486 daughter board you needed to run it :)
This reminded me of back in the day with Xbox 360 and the cat and mouse we played with MS. MS started making their games I believe 4.8gb in size and all the pirates could only buy DVDs which were smaller as nothing bigger was actually available. The first thing pirates did was truncate the games and removed some padding so they could fit all the security features the disc required to play and remain stealth. Then MS found a way to detect truncated discs and many people were banned. Then one of the 360 main hackers came out with a genius idea to take the discs we could buy and modify the firmware to a certain brand and model of DVD burner to allow the burner to burn right to the outer edge of the DVD. This was possible because all dvds are actually slightly larger then their listed size but standard DVD burners could not burn to the extreme edge. Some burns didn’t write perfect and sometimes you had to burn it a few times before it was stealth. They also had a program to see if the stealth worked and the disc passed or failed. I never did receive a ban and eventually moved to another mod on my 360 that didn’t require discs at all. What a flashback reading this article.
I don't recall how my friends and I figured this out, if we discovered it or just heard about it, but it became standard practice to carefully insert a finger into the disc drive and slow the spinning disc when loading up a copied disc in order to defeat any complaints from the OS. Not sure why this worked but it always did :)
I have always understood "disk" to mean a floppy disk or hard disk (as short for diskette), and "disc" to refer to circular discs like CDs. (Yes, disks have discs inside them but they are squareish to hold)
Seeing people refer to floppy disks as discs really bugs me for some reason.
We had to build our own copy protection after dongles were hacked and too fussy. Weak bits were copyable using the CopyIIPC option board.
So what we resorted to is using a needle scratching the inner most tracks of the floppy on random locations. Writing those tracks with a pattern and record where the pattern was broken. While executing the program it did write that track and read that track, the locations where the pattern was broken (two tracks, begin and end) was the key that was used to decrypt some parts of the further into the program.
To my knowledge it was never hacked and every disk was unique, we kept the keys for each customer (was part of the serial) so if it was hacked we could trace it to the leaker.
Not the Beeb but this copy protection was common even quite early on the Apple II. We we ran our disk drives with the cases off so we could adjust the speed screw to match track lengths. We had software that would visually feedback the track length so you could get it spot on.
I don't think it was mentioned, but I wonder if the mains power fluctuation (voltage or hz) would affect drive sector length / rpm also? So even the same drive couldn't produce a high fidelity copy of one of these discs if the power input was different.
I'm not sure how good the power supplies were back then, but ideally you'd have no idea what the mains power was at the drive since the power supply converts everything to DC. Now of course rectification isnt perfect so there were probably some artifacts, but enough to detect on the disk? Seems unlikely.
I'm curious what tricks people use nowadays for software copy protection? Are dongles still a thing? Have people given up on the idea of software protection? (SaaS is probably the best kind of protection if you don't take it too literally)
License keys, software phones home to verify the license key, refuses to run if license key not verified. You could hack the software to remove this protection, and for popular software packages people have done this (Windows, Photoshop, etc).
I'm just halfway of the text and I'm already tippy-tapping like an excited toddler waiting for candy! This has the same hackish aura as the "story of Mel"
I seem to remember the only software that would copy any disk you pointed it at, was in fact the source code listed in the official Acorn DFS manual. With the drawback that it copied one sector at a time, so without a double drive, that was a lot of swapping for a 40 track disk, let alone an 80 track one.
I'm talking about understanding how it works on a code level. You don't need to write the special disk out if you're patching the code, like this article does.
Yeah but you'll have to hunt for and fix the code wherever it is on every disk, which could be subtly or completely different between applications. "Recalculate track 9" is a simple program that would have worked on any Western Security DRM disk.
You're assuming it's always in track 9 in the same spot. What if it isn't? And what if different applications use slightly different obfuscation?
If we're assuming Western Security DRM is always in the same spot using the exact same method, why not compare it against some other type of copy protection that always puts the exact same checking code in the same spot? It would actually be easier to blot out the other type's code with NOPs than to recalculate obfuscated Western Security track-length tables.
Although the GPs suggestion would stand a chance of creating a generic copier for disks protected using this method, rather than having to individually crack each title.
Only if they use the same obfuscation and put the data in the same spot. So it's like any kind of copy protection, you can make a "generic" copier/patcher if and only if a bunch of titles implement it the same way.
Not the Beeb but this copy protection was also used on the Apple II for example which is why we ran with the cases off so we could adjust the speed screw to match track lengths. There was software that would visually feedback the track length so you could get it spot on.
Fully online, streaming gaming a la Stadia, will be the ultimate in copy and cheat protection. Since you don't have access the the actual code, you won't be able to modify or hack it to either cheat or bypass protection.
I understand that this is horrible for unbreakable DRM, but in my case, I only play multiplayer online games (MMOs) - there is nothing to pirate. I'd happily take game streaming in exchange for getting rid of invasive, useless, data-collecting (including clipboard contents, uploading files on disk, etc.) rootkit anticheats starting at boot being "mandatory" to play.
There's another benefit here that I haven't seen yet. Suddenly it becomes potentially reasonable to fully trust "clients". That enables much better anti-latency schemes which, combined with the clients probably being on the same low latency cloud network as each other, could potentially produce some really fantastic results. But you'd probably have to design the game engine around it.
Very clever and great article! But it sounds pretty easy to write a cracker for it: Just rewrite the machine code to jump over the check. Or did I miss anything?
Edit: Guess it depends on the details and amount of "obfuscation" that he mentions.
>Very clever and great article! But it sounds pretty easy to write a cracker for it: Just rewrite the machine code to jump over the check. Or did I miss anything?
Nope, you did not miss anything. Many of these old DOS game floppy protections could be bypassed by a single byte change to the exe (or com, depending on the game) file. The time consuming part was working out exactly which byte to change.
Source: I cracked most of my DOS games back in the day, using nothing more than DOS's supplied 'debug' tool, so I did not have to go find, and insert, the floppy in order to play the game. On many of them, changing a single JC to JNC or a single JE to JZ (or the reverse) was all it took to bypass the copy protection. A few others took a few more bytes worth of patching, one had to convert a conditional into an unconditional branch or otherwise nop out a small code segment. The one that required the most effort was MicroProse's Apache helicopter simulator. They used the "weak sector trick" but the contents of the "weak sector" was also a small bit of the overall game code. So for that one I created a loader that hooked the disk interrupt and when it detected the weak sector read, it returned the sector data and the proper "disk read error" state for the rest of the game to work with.
> Just rewrite the machine code to jump over the check
Sure. It's even easier today: not only we have specialized software for cracking things, but we can even dump the memory contents and inspect them, patch up while the program is paused, and then rewind and try again from the same location. If we mess up, we can quite easily restart, just run the program again from our fast NVME drives(it will probably come straight from the OS cache). Heck, in some cases we can "fuzz" the program and let the computer try to figure out the winning combination! We can do this in parallel with our multiple cores.
Now think about the context back in the day. For the most part, people were trying to crack the copy protection using the same machine that ran the software. In the case of the BBC Micro, you could have anywhere from 16 to 128KB, depending on the model. In that era, it was often the case that you couldn't even run a debugger, because it wouldn't fit alongside the program you were debugging. And even if you could, their capabilities were nowhere close to what we have today and - depending on the hardware - some breakpoints you couldn't even reach (inside code that disabled interruptions - which was often the case for software that accesses disks).
It could be incredibly hard to find exactly what "jump" you had to change. If you messed up, this could mean a machine lockup. Now you have to reboot and load your stuff again from slow floppy media.
I did basically everything you mention, back in the day, although on a C64.
In many ways, things were much easier back then: Direct access to most of the hardware, flat memory layout, smaller and vastly simpler ISAs, smaller programs (meaning shorter disassemblies to wade through), no protected mode so you could overwrite anything in RAM and so on. And you wouldn't even have to do it live in-memory, just disassemble the program piecewise from disk. People did extraordinary things back then, and you vastly underestimate their capabilities. Sure, you had to write a lot of tooling yourself, but it was simpler times.
I am not trying to detract from the copy protection mechanism, which truly is ingenious. I was just genuinely curious whether I was misunderstanding anything from the article.
Or... what I also encountered and found to be the hardest to reverse engineer, having a block decode in the interrupt vector table using all registers including stack pointers as decode keys.
That meant that making a mistake would result in a tedious re-iteration.
Copying one of my old comments from slashdot... it sounds similar to Sierra's "cpc.com". While I was reading the article I wondered if the equivalent of this process for the 6502 (BRK/COP interrupt table?) would work.
Back in the 1980s Sierra On-Line used to copy protect their adventure games with a copy protection system which involved strangely formatted sectors on the original disk which were impossible to duplicate exactly using standard PC hardware.
The loader "sierra.com" used to call a copy-protection program "cpc.com" which loaded data from the disk to decrypt the main program and run it. cpc.com had some of the most obscure, twisty, awful code ever written to prevent debugging and it constantly used different methods to thwart stepping through the program using INT 3 (these were the days before Soft-Ice).
But the solution (or "crack") was just dead simple. Just fire up debug, step to the beginning of cpc.com, and copy the vector from INT 3 into the INT 13 vector - then cpc.com stops right at the point where the data from the disk is being loaded, so it can be copied.
Despite all the incredibly complex code, cpc.com had to read the data off the disk so there was no way the Sierra programmers could thwart this method.
My thoughts exactly. I spent a good amount of time learning about and cracking various schemes. It was never about distribution but about bragging rights and the different ways code was obfuscated. Most were disappointingly simple, others had more layers, very rarely found ones that needed special effort beyond say a person-day or two to solve.
My game contained a very standard check url type protection. This was not the real protection. This was the piece of code which the hacker was supposed to notice and remove. Early on in the game there was a function call to get the total number of bytes in the file and then divide it by the number of expected bytes. Ostensibly this was to calculate the size of the loading bar. I stored this information in a forgettable global variable. On the surface this looks like the sloppy coding one expects from flash devs. But the real purpose was so that I could later check if this number was not 1.0 and trigger the true copy protection. Long story short if the number of bytes were incorrect then the game becomes unplayable after a few levels. I thought that was a nice touch since these hackers usually didn't play though enough of the game to test if their hack worked.