Most of these solutions are based on public key encryptions. You send a data
to the dongle, and the dongle encrypts it or sign it with the private key
and sends back the results so the software of yours can check it using the
public key. But then the cracker eliminates this checking mechanism in your
software so its not even sending the data to the dongle or just overpassing
the condition jumps. Some other dongles decrypts piece of codes of yours.
That's the situation where usually crackers write a device driver to emulate
the dongle and maybe make some modification to the code as well.

You can make it very hard to crack but never could make it uncrackable. It's
your decision how much money you would like to spend on developing such
stuff or buying an existing one and then seeing that somebody put the crack
onto the net on the next month or so.

Tamas



On 3/26/07, Alan B. Pearce <A.B.Pearce@rl.ac.uk> wrote:
>
> >> But for what started this thread, I do wonder if a dongle containing an
> >> 18F or 30F PIC doing a calculation on the data may well be a viable
> >> way of doing things
> >
> >That's what I was thinking. DES3 may be overkill, perhaps TEA ?
>
> I wasn't thinking that, I was working on the basis that the input data
> stream is fed to the PIC in the dongle, the data gets manipulated by the
> PIC
> into the G-code form, and then fed back to the host program to stick in a
> suitable file somewhere.
>
> Now none of the relevant calculations that are the basis of the whole
> program are done in the easily got at software. They are all hidden in the
> dongle, and the data path has to go through the dongle, so there is no way
> past it.
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
unPIC -- The PIC Disassembler
http://unpic.sourceforge.net
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist