h a l f b a k e r yFutility is persistent.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
(Not the same as the classic copy protection dongle, so don't call "baked" until you read further.)
Copy protection systems normally rely on software which runs on hardware under the user's control and are therefore pretty well doomed to be cracked in a matter of time; obfuscation can only delay
the inevitable. This is true even if the copy protection looks for a physical key (such as a classic copy protection dongle), since you just have to reverse-engineer the code and bypass the test.
More protection is possible if the software and the CPU that runs it are physically protected, but that means shipping a computer along with the software to be protected, which is really expensive (you'd like to sell a game for $40 but the computer needed to run it costs $2000).
Lame, slow computers are really cheap, though. And it's widely recognized that "90%" of the running time of a program is spent in "10%" of the code, in the so called "hot spots" or "inner loops".
So, build a really cheap "computer", load the "slow" 90% of the code onto it, and have it run as a peripheral (probably a USB dongle or something). The code is locked up in the dongle with as much physical security as you can manage. The dongle's CPU is slow and cheap, but that doesn't matter. The performance-critical 10% of the code runs on the user's high-performance system. The 90% and the 10% can be separated automatically by profiling analysis.
Copy protection crackers are foiled because they only have direct access to a mishmash of inner loop code with none of the overall control logic. Unless they break the physical security of the dongle and translate the code in it into something that can run on the main CPU, they're SOL.
Physical security isn't perfect, of course, but it does raise the bar.
(Leave aside your views on the ethics and economics of intellectual property enforcement for the moment. Put on your "evil freedom foundation" hat if that helps.)
dongle
http://wombat.doc.i...c/foldoc.cgi?dongle
[phoenix, Oct 04 2004, last modified Oct 05 2004]
The Adventures of Don Gall
http://www.pericose....com/news/simon.htm
[phoenix, Oct 04 2004, last modified Oct 05 2004]
Microchip PIC16C745
http://www.microchi...es/16c745/index.htm
Integrated CPU/memory/USB chip for less than $3 [scad mientist, Oct 04 2004, last modified Oct 05 2004]
Encrypting not the software
http://www.geek.com...e20021220017857.htm
...but the data with a hardware token. [DrCurry, Oct 04 2004, last modified Oct 05 2004]
[link]
|
| |
I don't see how this is different than copying a game cartridge. The software running in the 'dongle' (anyone else know about Don Gall aka Don Gless?) has to be stored somewhere. When I gain access to it, I can copy it. |
|
| |
But it only takes one bad apple to spoil the bunch (so to speak). Once the memory of the said device can be interrogated, it can be stored on another device (like a disk or RAM). That copy can then be distributed, together with a patch that will make the "high-power 10%" look to the new copied destination instead of the dongle port. |
|
| |
It would be more convoluted and difficult to do than usual dongle-breaking though so I'm tempted to give you pastry... |
|
| |
"Dongle" in this sense, [bliss], is also known as a "hardware key," a physical device that you must install on one of the connectors of your computer in order to run a protected piece of software. |
|
| |
//I don't see how this is different than copying a game cartridge//
[phoe], It's similar, except the games usually only have a program, not a built-in PC. It’s more like the cartridges that have extra circuitry and even controllers [link] inside them. Even with the original code, it's just not the same. Emulators never seem to get it right.
One “mostly-baked” example is a video-conference camera. The data and processing is in the “dongle” USB camera. Your PC requests an image and gets a picture back. It doesn't matter that the dongle's processor uses a special operating system all its own. But if you copy it the camera's code, you’ve got to emulate its hardware and software. |
|
| |
[phoenix, Jinbish]: A game cartridge exists to let the console read out its entire memory, so anyone can duplicate the cartridge using its normal interface. These dongles are designed never to allow the code to be read, so you have to actually crack the chips open, which is substantially more different and requires specialized equipment. I think that's something. |
|
| |
It moves the problem from one of code obfuscation, which is hopeless, to one of physical chip security. It's true that once someone, somewhere "chips" the dongle you're done for, but I can't see how to avoid that. |
|
| |
[egnor] Fair enough. That tempting pastry is being nudged in your direction. |
|
| |
The hardware necessary to do this (at least to a large extent) is available (See link to Microchip. There are other companies with similar products). These are microcontrollers with memory and CPU in the same chip. Once programmed, the memory can't be read. Theoretically it might be possible to read the memory by cutting the chip open and probing the traces to the memory bank, but considering the size of traces on modern IC's, I suspect that would be nearly impossible. |
|
| |
These chips also have built in serial and/or USB interfaces, so the part count on the dongle would be very low. The specific chip in the link costs less than $3 in quantities of 100, so dongles might cost less than $5 to produce. That may be pushing the limits of practicality, but the cost might be pushed down more in large quantities. |
|
| |
These chips couldn't be used to bake this idea exacly as stated by [egnor]. For most applications, 90% of the code couldn't possible fit in the 14KB program memory, but 14KB would be big enough to put enough of the code so that designing a software "patch" without the code would be nearly impossible. You'd also need to be careful about how often the two CPUs need to communicate to avoid hurting performance. |
|
| |
So to bake this, just build a facility to fabricate the dongles and offer a (optional) pre-programming service. Then create a development tool package to make it very easy for developers to use this without a huge learning curve. You might also want to secure a source for really cheap unpowered USB hubs as a service to your customers' customers. |
|
| |
Another approach for those with somewhat largish program needs would be to use an interpreted 'language' which decrypted code from a an external serial EEPROM and ran it internally. If using this approach, however, it would be imperative that the encryption be performed on blocks of at least four bytes each. The DS5001 (Dallas Semiconductor) can encrypt the address and data busses going out to memory, but because every byte is encrypted independently someone who hacks the hardware enough to single-step the processor while injecting code onto the data bus can crack the encryption pretty easily. |
|
| |
You might not even need external EEPROM, just load the encrypted code from the host CPU's memory. That way you can download new versions of the software (encrypted, naturally) from the vendor without having to replace the dongle. |
|
| |
My point is that 90% exists inside a PC. Where? I'm guessing it's on a hard drive, though the author doesn't spell it out. How many low-level drive copying utilities exist? That's what I meant when I likened the idea to cartridge copying. |
|
| |
[scad mientist]'s solution is closest to unbreakable but (despite the claim otherwise) I suspect a unit complete with code would cost significantly more than $3. |
|
| |
[scad mientist]'s solution is an implementation of exactly what I'm proposing. |
|
| |
I fail to understand [phoenix]'s objections. If the 90% is on the user's hard drive, it will only be in encrypted form, which can be duplicated but wouldn't run on anyone else's dongle (they each have a unique key). Otherwise it's sealed up in the dongle itself using tamper-resistant hardware, which can't be easily duplicated. |
|
| |
[phoenix] For pricing, go to the "Microchip PIC16C745" link and click on the "Free Samples & Purchase Options" button. I could buy 100 of these chips for $2.82 each. The $11.43 version are erasable and wouldn't be used in production dongles. I have a $150 dollar hobby grade programmer that can write the code to these chip in less than a minute ($0.133 each at $8 per hour). With a larger capital investment, the programming cost per unit would drop a lot. |
|
| |
The cheap price may not be so surprising to you when you realize that this chip has less processing power than the the original IBM PC. It runs at 6MHz and is so simple that it doesn't have a built in instruction for multiply or divide. This chip does have extra I/O ports and A/D converters that wouldn't be used inthis application, so a better chip without the extra I/O and a cheaper price might be available from another company. I just happen to have experience with Microchip products, so it came to mind when I saw this idea. |
|
| |
The $5 estimate for the finished dongle is more suspect since I have no experience with electronics manufacturing. Does anyone have a clue what it would cost to mount a chip, crystal, a couple resistors, a couple capacitors, and a USB plug on a circuit board and encase it with plastic? Luckily the chips are "in circuit programmable", so it should be possible to do large manufactuing runs of blank dongles, then program them in smaller batches for individual pieces of software. |
|
| |
I imagine, then, that you can install the software on as many PCs as you like, but only use it on one machine at a time. Very useful for people who take their work home with them. |
|
| |
Also, I propose a small RAM section on the dongle, onto which user preferences could be written (keyboard setups for gamers, or example). |
|
| |
"If the 90% is on the user's hard drive, it will only be in encrypted form,..."
Until it gets to the CPU?
"...which can be duplicated but wouldn't run on anyone else's dongle (they each have a unique key).
Stored where? Why can't I retreive it? Why can't I decode the source? |
|
| |
"For pricing, go to the "Microchip PIC16C745" link..."
So the dongle costs $5 to build (sans profit). Now you have to write the 90% of the code that will run on it. And since the $5 dongle comes with 256(K?) of memory I guess the total size of the application won't exceed 300K. The spec. sheet I see says the device runs at 24MHz - faster than the 6MHz you note, but still awfully slow for 90% of the code. |
|
| |
I'm not trying to be outright argumentative. I remember when dongles first came out and I know why they've largely disappeared since then. Dongles break, get misplaced (unlikely with the PCDongle [egnor] proposes) and become obsolete. I'm trying to understand how/why this is a better approach is all. |
|
| |
If this is a solution, then it is a solution for only two or three companies. Anyone coming along after that finds all the dongle sockets have been used up. |
|
| |
Also, how do you upgrade the software next year? |
|
| |
[phoenix]: The code is decrypted and run on the dongle's CPU, which you cannot program, cannot read, and generally cannot control without physically penetrating the silicon, because that's how it was built. |
|
| |
[dalek]: USB can support up to 255 devices, and USB hubs are cheap. Software upgrades can be done by the distribution of encrypted code which only the dongle can decrypt. |
|
| |
The biggest difficulty in designing a copy-protection dongle is making perform a function which varies in an unpredictable way with user data, but which is essential to a program's operation, and yet which does not require use of too large a data set. |
|
| |
Unfortunately, most programs cannot be so easily partitioned. While they spend most of their time running 10% of the code, there aren't very many important parts of the program which don't need access to a large amount of data. While it would be possible to have the PC-side application act as a "client" to the dongle (e.g. the dongle asks the PC what's in memory address 194331, etc. and the PC gives it that data) such a mode of operation will tend to be extremely slow. The only way decent performance can be achieved is if the PC knows in advance what data the dongle is going to need; knowing that would require that the PC have most of whatever algorithm is being used coded, which could in turn lead to exploitable weaknesses. |
|
| |
The memory-partition problem is tricky but I don't think it's necessarily insoluble. You'd use a VM-like system with copy-on-write pages and dirty bits and cache callbacks and so on. Admittedly a little more complex but mostly a software problem.
Memory (actually, memory allocation points) can be profiled like code to minimize the number of "page faults". |
|
| |
Ideally, the dongle would sit on the computer's bus and have direct access to its RAM for data, but that's hard with something like USB. |
|
| |
If the application is run from a CD, such as most games, it might be possible to embed the chip into the CD somehow. It would be a real challenge to interface with the chip, and power it, but if you could do that, you wouldn't be adding dongles to the annoyance of having lots of CDROMs. |
|
| |
Baked, printer port dongles for enterprse software were relatviely common in the past, and you can still come across some. |
|
| |
No, belg, read the idea itself more carefully, as suggested in the first line. This is different. |
|
| |
I believe this principle is applied in the 'smart cards' used by satellite receivers (DirecTV, Dish) where the smart card has ROM/ROM and a (wimpy weak) CPU. The set top box ‘talks’ to the smart card CPU with a specific protocol but only a limited set of action is allowed. For example, once a card has been used in a specific receiver, you cannot use it in another one. This process is done at first initialization and cannot be undone. Bought a new receiver? Call DTV and get a new card. A card that has been ‘bound’ to a receiver will not accept to be bound again.
This is very close to the model you describe. It is very difficult to physically tamper with the device without destroying it - everything is glued/embedded in tiny fragile circuit, probably designed to tear apart when you try to open it too. Tampering with the software is hard too, because it will only allow specific set of commands and will forbid direct access to memory. It’s not foolproof, there are ways to circumvent that kind of protection, but I think the model is quite good. |
|
| |
I'm not fully sure if I understand
what you are saying but couldn't
someone take apart the software
and look in the section of what its
expecting to see (ie code from
such port) and then put a program
in the other computer that tells
that program exactly what it wants
to hear on the exact port it's
supposed to transmit at? |
|
| |