Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defeating a 40-year-old copy protection dongle

dmitrybrant.com

Post reply on HN
Print view View original

181–190 of 302 posts

Re: Defeating a 40-year-old copy protection dongle

#181

Post by GuB-42 »

ryandrake wrote: post #61
GuB-42 wrote: post #31

Earlier quoted context omitted.

Having to put a physical device on your parallel port at the back of the computer is kind of annoying, especially if every software you use has one. More common for games was to use the media itself for copy protection, using a variety of tricks to make copy more difficult. Other techniques involve printing some keys you have to enter using colors that don't render well in photocopies, or have you look at words a cer…

Makes me sad how many person-years of effort have been wasted over the years on futile dongle-engineering, copy-protection and DRM. They're pretty much all cracked. And the industry keeps insisting on trying!

The industry doesn't want to make software crack proof, they just want to make money. Typically, in the case of games, is is about "when", not "if", they know it will be cracked eventually, but they want to hold long enough to secure their launch sales, which is where they make most of the money. It is even common to remove DRM after a few months, because it is not worth it.

As for enterprise software, pros usually don't want the potential legal trouble associated with cracked software, and dongles are just about not making is easy to violate the licence by accident.

Re: Defeating a 40-year-old copy protection dongle

#182

Post by harph »

jeffwass wrote: post #163
ruleryak wrote: post #7

Many a crack back in the day was even more simple still, we'd just find and alter the right JE or JNE into a JMP and we're off to the races. As the author found, the tough part is just finding and interpreting where and how the protection was implemented. If throwing the exe in a hex editor gave you access to String Data References (not always the case, but more common than not) then you'd just fail the check you wer…

I was wondering this actually, why not just skip past the check entirely instead of going through the effort to pass the check without the dongle?

Because sometimes skipping is not enough: https://mrwint.github.io/winter/writeup/writeup.html

Re: Defeating a 40-year-old copy protection dongle

#183

Post by nu11ptr »

> If we look at segment 0800, we see the smoking gun: in and out instructions, meaning that the copy-protection routine is definitely here, and best of all, the entire code segment is a mere 0x90 bytes, which suggests that the entire routine should be pretty easy to unravel and understand. For some reason, Reko was not able to decompile this code into a C representation, but it still produced a disassembly, which will work just fine for our purposes. Maybe this was a primitive form of obfuscation from those early days, which is now confusing Reko and preventing it from associating this chunk of code with the rest of the program… who knows.

in/out instructions wouldn't have a C equivalent. My assumption would be it only translates instructions that a C compiler would typically create.

Re: Defeating a 40-year-old copy protection dongle

#184

Post by Someone »

anyfoo wrote: post #56
antonvs wrote: post #36

Earlier quoted context omitted.

> Many a crack back in the day was even more simple still, we'd just find and alter the right JE or JNE into a JMP and we're off to the races. I did that with dBASE III, which used ProLok "laser protection" from Vault Corporation - a signature burned onto the diskette with a laser. Back then, I found it amazing that Ashton-Tate actually spent money to contract with a copy protection company for something that could b…

Was ist ever confirmed that it was in fact a laser? I wanted to make a trivia question out of this ProLok protection, because “lasers for copy protection” sounds just weird enough to potentially be a nonsense answer without context, but I couldn’t confirm that the holes were indeed made with lasers, and not with other means.

Their patent (https://patents.google.com/patent/US4785361A/en) doesn’t mention a laser, but of course that doesn’t imply it wasn’t a laser.

I would guess (more or less) identically damaging multiple floppy disks in the same way would be easier with a laser than with something mechanical (e.g. a knife or a drill) (it is fairly easy to control power and duration of a burn), so it might well have been a laser.

On the other hand, disk tracks weren’t exactly tiny at that time in history.

Re: Defeating a 40-year-old copy protection dongle

#185

Post by notpushkin »

giamma wrote: post #143

This reminds me the old days of Windows 95 when I found a software to burn CDs that had a trial version which was limited to 150MB of data or so. If you tried to create a CD bigger than that it would refuse to burn and it would instead open a popup and tell you that the image exceeded the limit of XYZ blocks allowed by the trial version. So I first decompressed the executable program (Windows executable were often pa…

My grandma used to be playing casual games from a certain publisher on her PC. They were all trial versions, though, limited to 30 minutes or so. Turns out, the time left was stored in the registry, and didn’t have any validation – so when a 10 y.o. me made a quick edit, she was left with 4294967295 minutes of trial left.

Re: Defeating a 40-year-old copy protection dongle

#186

Post by davidwritesbugs »

notpushkin wrote: post #185
giamma wrote: post #143

This reminds me the old days of Windows 95 when I found a software to burn CDs that had a trial version which was limited to 150MB of data or so. If you tried to create a CD bigger than that it would refuse to burn and it would instead open a popup and tell you that the image exceeded the limit of XYZ blocks allowed by the trial version. So I first decompressed the executable program (Windows executable were often pa…

My grandma used to be playing casual games from a certain publisher on her PC. They were all trial versions, though, limited to 30 minutes or so. Turns out, the time left was stored in the registry, and didn’t have any validation – so when a 10 y.o. me made a quick edit, she was left with 4294967295 minutes of trial left.

Hope she knows she still only has 3million trial days left

Re: Defeating a 40-year-old copy protection dongle

#187

Post by Thorrez »

miki123211 wrote: post #164
ruleryak wrote: post #7

Many a crack back in the day was even more simple still, we'd just find and alter the right JE or JNE into a JMP and we're off to the races. As the author found, the tough part is just finding and interpreting where and how the protection was implemented. If throwing the exe in a hex editor gave you access to String Data References (not always the case, but more common than not) then you'd just fail the check you wer…

Another method (much more common for software that asks for two pieces of information, like a name and a key) is to take a memdump of the process at the "your key is invalid" dialog, find the invalid key you just typed, and hope that a valid key is somewhere nearby in memory. Unlike the assembly trick, this requires 0 programming expertise beyond the ability to type `strings` on the command line. This works because s…

The proper thing to do is not to zeroize the correct string memory before comparing. The proper thing is to only store the hash in the binary in the first place, not the correct string. (Although having a 2nd layer of hashing before comparing might also be a good idea, and in that case you would want to zeroize the 1st hash before comparing the 2nd hash.)

Re: Defeating a 40-year-old copy protection dongle

#188

Post by sintax »

sedatk wrote: post #108

Of course it used to be simple in the earlier days. It got way better and fast with HASP and alike in the mid 90’s. I specifically remember software that kept a portion of its data in the dongle memory with good anti-debugging techniques too. But even the hardest protection would take a week to break at most.

Out of curiosity googled for Sentinel (which was one of the other dongles back then), seems somebody is now providing a bypass/emulation service: https://sentineldongle.com/ (not affiliated with this, just googled Sentinel like 5 minutes ago and this showed up).

Re: Defeating a 40-year-old copy protection dongle

#189

Post by kevincox »

nu11ptr wrote: post #183

> If we look at segment 0800, we see the smoking gun: in and out instructions, meaning that the copy-protection routine is definitely here, and best of all, the entire code segment is a mere 0x90 bytes, which suggests that the entire routine should be pretty easy to unravel and understand. For some reason, Reko was not able to decompile this code into a C representation, but it still produced a disassembly, which wil…

I would still hope for it to translate most of the code with a couple of asm blocks. But maybe the density of them was too high and some heuristic decided against it?

Re: Defeating a 40-year-old copy protection dongle

#190

Post by Joel_Mckay »

samplatt wrote: post #144
IshKebab wrote: post #135

Earlier quoted context omitted.

Yeah case in point - how many people actually pay for Visual Studio? You're supposed to if you're using it for commercial purposes but I don't think I've ever seen a commercial license used (though I don't do a lot of Windows work tbf).

VS is actually one of the cheaper tools in our stack; Unity (the game engine) is probably the most expensive one at the moment, and it's going to get much more so with their recent changes to licensing structure for embedded hardware.

Unity has always had janky shaders, the fact people still use it over Unreal Engine or even Godot is completely baffling.

Unity is getting way too cheeky considering how they started out. =3

Post reply on HN