I'm planning to protect some software using a knapsack protection scheme. The problem is that I'm not an expert in electronics. The circuit is very simple: just a memory where I store a key to decrypt. Anyone knows an url where I can found the scheme of this type of circuits. I only have found comercial solutions using google and I have not found the schemes to build by myself. Any help pleeeeease :grin:
Posted on 2003-07-03 07:23:12 by Regeax
What is your problem? Do you have a schematic that you do not know how to build, or do not understand? Are you looking for a schematic, or parts? You need to supply more definition. Ratch
Posted on 2003-07-03 10:36:36 by Ratch
Ratch, sorry my English is a little bad :( Yes, I'm looking for the schematic...
Posted on 2003-07-03 11:56:58 by Regeax
I guess I am a little confused. If your protection software is being run on a computer, that computer should have all the storage memory you need without adding another hardware memory, and trying to interface with it. You need to explain what is going on some more. Ratch
Posted on 2003-07-03 17:21:14 by Ratch
I think he wants to make a "dongle",
like HASP(c) devices that you connect on LPT or USB port and it enables a programm to run, without it the programm will not run... a method of software copy protection...
Posted on 2003-07-03 18:35:41 by BogdanOntanu

Perhaps you are right. A dongle is an advanced application project. I don't know too much about them except that there are companies that specialize in making them. That goes beyond the electronics theory aspect of this thread and is more like firmware applications. Ratch
Posted on 2003-07-03 18:58:53 by Ratch
I've never heard of such devices, but I don't think making them is that hard. Using the LPT is easy, and as I see, most of the people here can make PIC projects. I can be wrong, but I suppose the system is like this:

A PIC16F84 with 8 wires, connects to the LPT. I think the best way is to have the IC as a 'passport' - you put it in a socket of a device that is usually connected to the LPT of the PC. Thus, the 'passport' will be easiest to make and maintain...
The PIC sets some inputs and outputs (the ports), and the PC sends data in which stage the PIC should work.
Stage 1- prepare for writing new password (encryption key)
Stage 2 -supply encryption key
Stage 3 -verify key, and write to EEPROM
Stage 4....n - read bytes from encryption key.
When the program starts, its data and code segments are encrypted. It sets the stage of the PIC via the LPT, and reads bytes of the encryption key. After having read all the bytes, the program tries to decrypt the data and code segments using the data from the PIC. If it's the same data - voila :), otherwise GPF or bad instruction or exit program (catching the GPF or bad instruction).

I once made a programmer for pic, and one simple proggie, but I didn't notice I've set the flags of writing to 'protected', and when I tried to verify the data, I always got zeroes only..... so I disassembled the programmer. Later I found out about 'protected' feature. Right now I have no time to make this 'dongle' project, but in a few months I might find some.

I have no experience in PIC, so I might be completely wrong. I also think I remember that the LPT has only a few inputs, that are not enough, so solving this technical problem will be the key to building this project.
Posted on 2003-07-04 01:11:10 by Ultrano
hah. I found some info on the LPT. It can be configured to have GND, VCC, 8 inputs and 5 outputs. The VCC can be taken from nStrobe, if we've set it as output.
It'd best be to transfer in nibble mode, I guess. 4 control(write) wires and 4 data(read) wires, and 1 additional control wire to trigger an interrupt at the PIC's side. That interrupt will serve as timer. Ah, if there was just 1 more control wire, for reset, it all would be easier. I guess this can be 'emulated' by adding a button at the LPT-PIC interface, that simply makes the PIC reset itself.
The PIC and program have a password to verify each other's presence. Let's assume that the password is 16-bit and the decrypt key is 64-bit. You can easily change them to suit your needs for protection. The 64-bit value is written in EEPROM, and the 16-bit one is in the code section (something like cmp al,45 / cmp bl,43 but in PIC code). So, here's the schedule:

comp textequ <PC> ; this is rather for you than for compiler
comp_doesnt_care_about_PIC_absence equ 1 ; also for you

comp: Interrupt + Stage 01
comp: Interrupt + nibble 00 of 16-bit password
comp: Interrupt + nibble 01
comp: Interrupt + nibble 02
comp: Interrupt + nibble 03
PIC: *packs up the 4 nibbles into 2 bytes*
PIC: *compares if bytes are same as in password*
PIC: *if OK, then sets an internal variable "logged_in=1" *
PIC: *from now on, if logged_in==0 then ignore interrupts and all *
<--- basic login complete, now send command (like a menu option) --->
comp: Interrupt + Stage 03 ; script to fetch decrypt key
PIC: *sets internal variables "Script=3; Script_frame=0" *
comp: Interrupt
PIC: nibble 00 of 64-bit password into the 4 data pins / Script_frame++
comp: Interrupt
PIC: nibble 01 / Script_frame++
comp: Interrupt
PIC: nibble 15
comp: *packs up the 16 nibbles, and does try to decrypt its .data and .code *

even if there's no PIC connected or its password isn't ok, the comp continues execution, and there's no way to get the right decrypt key.
The LPT-PIC interface is just a plate with the external parts, necessary for a PIC to run (x-tal or RC), and it's mostly wires :).

visit http://y0da.cjb.net and www.bitshape.com for info/code how to encrypt your proggie
Posted on 2003-07-04 02:26:36 by Ultrano
also, this schematic and code can give you ideas on creation of that project. I've never tested this schematic, but I am sure it works (theoretically).
Posted on 2003-07-04 02:53:42 by Ultrano
Hi, Regeax,

Although I have never built such a dongle, I know the principle and I can offer some suggestions:

1. The dongle should have two connectors: a DB-25 male that connects to the printer port and a DB-25 female to which the printer can be connected. Thus, the client should be able to still use the printer with the dongle. Most of the signals are simply fed through the dongle.

2. The dongle should not be easy to duplicate. It should contain a device whose code cannot be read out. Therefore I advise against the use of the EEPROM. The user can easily duplicate the dongle, since the EEPROM is not code protected. It's just a matter of soldering a few wires together then.

3. The application should check periodically (or at least before important operations, such as Save or Print) that the dongle is present. Otherwise the client could remove the dongle after starting the application. Then they can use it to start the application on another computer.

4. It is best if a VITAL part of the application code actually is in the dongle and only extracted at startup and decrypted. That way even if the user figures out the encription scheme they still cannot use the application, because part of it is missing (it's in the dongle). Typically, 64~256 bytes should be enough.

In the picture I am attaching, there are two schematics, each of which uses a PIC microcontroller. These should be OTP type, code protected.
The use of a microcontroller in the dongle also has the advantage that you can use more than one encription key and use any of them at any time, based on a command you send to the PIC. For the periodic verification part, the PIC can simply contain a jump table. You can send a randomly generated number to it and it replies with a table entry. That way, a person trying to duplicate the dongle would not see the same data being sent periodically and the same reply back.

The first schematic uses a PIC12C509, powered from the INIT line. This line is always HIGH, and only goes LOW when the printer needs to be initialized. That would initialize the PIC, too. The data can be sent in serially via D0, with D1 as clock, or two bits at a time, D0, D1, with D2 as clock, or any other combination. The data is read out of the PIC serially via the ERROR line (on the status port).
The SELECT_INPUT, when HIGH tells the printer to go OFF LINE. Therefore, when talking to the dongle, force it HIGH. Otherwise, force it LOW. The PIC should check this line and when it's LOW, it must copy the state of the GP0 to GP1, working like a switch for the ERROR line: when talking to the printer, the ERROR signal come from the printer.

The second schematic is more complicated, allowing you to use 4 bits at a time. The data is clocked into the PIC in two steps, by pulsing the SELECT_INPUT line. The encrypted data is read out in the next two steps, by pulsing the same line. (While data is clocked INTO the PIC, it can also output some random data, to create confusion. Your application would ignore that).
The data is read from the status port, on D7:D4. The PIC again works like a switch: when the SELECT_INPUT line is LOW, it copies the state of lines RA3:0 to RB3:0.

Note that you can always pulse more data lines than necessary, to confuse the person trying to duplicate the dongle. The STROBE line is the one that when LOW tells the printer the data is available. Therefore, it should be HIGH whenever you talk to the dongle.

If these ideas are of interest to you, I would be happy to assist you further with the necessary details.
Posted on 2003-07-08 19:25:26 by VVV