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.
https://www.gamasutra.com/view/feature/131439/keeping_the_pi...
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:
Things like the "Woz" format https://applesaucefdc.com/woz/reference1/
Impossible to copy unless you reproduce the head movements at the right time.
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.
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.
It's not a very good puzzle if the only clue is "I dunno he looked at it real squinty and it didn't help."
Apparently any alternate formatting would have tripped up the friend.
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?
Am I misremembering?
The OED includes these references:
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 Wikipedia article affirms this convention as well, which begs the question: solid state disk drive? solid state disc drive? solid state brick drive?
https://oldcomputers.net/bbc-micro.html
The User manual contains more language. For example, 'program' for computer program (vs 'programme' which would be used for TV)
DASD Direct-access storage device[0]
Disk Pack[1] perhaps?
Answer seems to be the 8" floppy disk[2] which only IBM called "Diskette-1" and 5-1/4" ones called mini-diskettes, floppy diskettes, etc.
[0] https://en.wikipedia.org/wiki/Direct-access_storage_device
[1] https://en.wikipedia.org/wiki/Disk_pack
[2] https://en.wikipedia.org/wiki/Floppy_disk#8-inch_floppy_disk
Fixed disks (which were also quite large at the time.) Floppies were removable disks, like cassettes; disk + cassette = diskettes, also disk + dimunitive -ette = diskette.
https://www.ibm.com/ibm/history/exhibits/vintage/vintage_450...
I’d say IBM called floppy disks diskettes by opposition to hard disks, which were huge at that time:
https://www.computerhistory.org/storageengine/winchester-pio...
(btw, diskette comes from disk)
I have absolutely no evidence for or against this though.
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".
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.
uh ? that's pretty much how I think all the time when writing words for which I'm not sure of the spelling
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.
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.
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"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."
in https://cyber.harvard.edu/ilaw/Contract/vault.htm
Edit: there is a Wikipedia page for that https://en.wikipedia.org/wiki/Vault_Corp._v._Quaid_Software_.... (there is a dot at the end of the URL but HN parser does not treat it correctly)
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.
(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.
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.
* found one: https://www.biocomp.net/o62799.htm
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.
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
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 :)
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.
Yes, more or less. https://en.wikipedia.org/wiki/Spelling_of_disc
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.
(For example, "RAM DISK" which isn't at all cylindrical.)
And that's how I learned 6502.
So it's "trivial" after you do the hard part. The clever thing is that it forces you to do the hard part without special hardware.
Edit: Guess it depends on the details and amount of "obfuscation" that he mentions.
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.
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.
It was difficult.
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.
That meant that making a mistake would result in a tedious re-iteration.
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.
The copy protection of Ocean games was much easier to crack. They had a “IsOkToRun” type of function which returned 1 in the A register.