 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > CODE PROTECT? | Forum Quick Jump
|
 | 
Chip Gracey (Parallax)
Forum Moderator
      
Date Joined Aug 2004
Total Posts : 1136
| Posted 2/18/2008 10:04 PM (GMT -7) |   | The simplest approach might be using a 39-cent PIC chip as a cypher. You could connect it over a single pin and transceive serial messages. The Propeller would send it a real random number (like from the RealRandom object), the PIC would run a known cypher algorithm on it, send it back, and the Propeller would then confirm that the cypher was of the expected algorithm. If it wasn't, shut down.
Someone would have to reverse-engineer your application from the 32KB EEPROM image to defeat this protection mechanism. It wouldn't be trvial, especially if your cypher code was written by you (unique) and not immediately recognizable as a one-size fits all Propeller object that everyone uses.
One of you guys ought to be able to make a PIC programmer object for the Propeller that actually burns some customized cypher code into a PIC chip to form the cypher device, and then have another object that just talks to it. It would be the cypher algorithm, itself, that each user should code in his own way, outside of the standard cypher-communication object, which would make the tiny and critical code very difficult to find in the 32KB image.
Chip Gracey
Parallax, Inc. | | Back to Top | | |
|
hippy
Registered Member
Date Joined Feb 2007
Total Posts : 1951
| Posted 2/19/2008 7:56 AM (GMT -7) | | I'm not convinced that would be effective. Although not trivial, it's my opinion that there's enough information in the bytecode to be able to reconstruct Spin and PASM source code from it and it's just a matter of time before a tool is publicly available to do that. It would then just be a matter of locating the challenge-and-authenticate object / call and forcing it to return a passed result.
A alternative solution would be to encrypt most of the Eeprom and then decode that in Ram before execution using an external micro or something to provide the key to decoding. That can be reversed engineered ... to reveal yet another level of different or more complex encryption.
The Spin program itself could encrypt itself in Eeprom after every new download which would simplify the development cycle.
One possibility which would defeat a bytecode decompiler at its first pass is to dynamically build up the decoding or challenge-and-authenticate code and patch bytecode at run time, ideally using information from the micro to make it more than just a software task. Even then, a bytecode simulator running on a PC ( or a patched executable to dump Ram ) could save the image as it would be once the secret routines had been built, and that can then be decompiled.
There's no perfect protection scheme when the executable image is available, and the best that can be achieved is to beat the reverse engineer in a war of attrition; make the effort outweigh the gains.
Parallax could help with the Prop II by hiding encryption routines and the Propeller to micro comms in Rom but it could still be reverse engineered. | | Back to Top | | |
|
Chip Gracey (Parallax)
Forum Moderator
Date Joined Aug 2004
Total Posts : 1136
| Posted 2/19/2008 9:48 AM (GMT -7) | | | Even if a standard object (identifiable in the binary image) was used to communicate with the cypher PIC, things would still be very difficult to figure out if it was the customer's own code which performed the brief check of the result. As an attacker, you wouldn't know what you were looking for. This code (or its functionality) can be obscured to the point where it's just not worth the effort of reverse engineering, even if you did have the Spin/PASM all decompiled, and even if you simulated the whole chip using this understanding. You would not know what you were looking for. For example, the cypher results could be used as an index to a jump table, which forms the correct function of the application. You wouldn't just be trying to spoof the cypher I/O, but you'd be tasked with having to learn the application, itself. I think it could make someone pretty insane. It would be a lot less work to design a comparable product from a clean slate.
The next Propeller will hopefully solve this problem, once and for all. By the way, can anyone out there figure out how to get the proper binary image of the current Spin interpreter from ROM?
Chip Gracey
Parallax, Inc. | | Back to Top | | |
|
Phil Pilgrim (PhiPi)
Registered Member
Date Joined Feb 2006
Total Posts : 7744
| Posted 2/19/2008 11:40 AM (GMT -7) | | Uh oh! My productivity has been sorely lagging of late as it is, and now comes the perfect avoidance activity. Chip, I think you're what addiction counselers would call an "enabler"! 
-Phil | | Back to Top | | |
|
Mike Green
Registered Member
Date Joined Oct 2004
Total Posts : 15579
| Posted 2/19/2008 12:52 PM (GMT -7) | | parsko,
There is no "magic key" in the IDE. The IDE knows nothing about it. The Spin interpreter is stored in the ROM on-board the Propeller chip. It happens to be stored in encrypted form and is decrypted automatically by the hardware in the chip as it's being copied into a cog for execution. I suspect that the hardware for the COGINIT instruction uses the decryption logic whenever it starts a cog from ROM since the bootloader is also stored in encrypted form. | | Back to Top | | |
|
stevenmess2004
Registered Member
Date Joined Dec 2007
Total Posts : 1076
| Posted 2/20/2008 12:50 AM (GMT -7) | | | Looking at the memory map for the prop. There is 1024 longs allocated in the ROM for the interpreter and the bootloader. Now to load the interpreter you use the address F004 which is 1 word past the start of the allocated memory (obviously because it needs to be long aligned. Now my guess is that this loads a small assembler program that then loads the interpreter over the top of itself. At a guess it doesn't use the 'shadow' registers because Chip didn't mention this until much after they released the prop so it should be reasonably straight forward to figure out. Time to start exploring | | Back to Top | | |
|
Phil Pilgrim (PhiPi)
Registered Member
Date Joined Feb 2006
Total Posts : 7744
| Posted 2/20/2008 2:02 AM (GMT -7) | | My guess is that there's a linear feedback shift register (LFSR) involved, the output of which is used either to XOR the actual code in ROM or to generate a sequence of addresses that unscrambles the order of otherwise plaintext instructions. A peek at the actual code would determine which. The former would look like nonsense, with an inordinate number of condition-code-dependent instructions. In the latter case, the instructions would look normal, but their order would make no sense.
I'll also conjecture that the actual deciphering is done in hardware, so look for a method (like the LFSR) that's simple to implement in hardware — but nonetheless diabolical.
-Phil | | Back to Top | | |
|
stevenmess2004
Registered Member
Date Joined Dec 2007
Total Posts : 1076
| Posted 2/20/2008 2:11 AM (GMT -7) | | | I kind of doubt that this would be done in the hardware because it would require the coginit instruction to load differently from ram and rom. I'm more inclined to think that there is a small loader program that then performs the decryption. If this is the case it should be fairly easy to tell from a disassembler. What happens if you try to get GEAR to load from that point? (I'm on a mac at the moment and I haven't tried running GEAR on it yet.) If it is just an assembly routine then it should work in GEAR otherwise there must be something else going on like you suggested. | | Back to Top | | |
|
stevenmess2004
Registered Member
Date Joined Dec 2007
Total Posts : 1076
| Posted 2/20/2008 3:17 AM (GMT -7) | | | It would be interesting to start a cog that copied some from the ram and some from the rom just to see what happens. | | Back to Top | | |
|
stevenmess2004
Registered Member
Date Joined Dec 2007
Total Posts : 1076
| Posted 2/20/2008 5:23 AM (GMT -7) | | | Tomorrow I'll try a couple more simple things like just inverting the bits. | | Back to Top | | |
|
hippy
Registered Member
Date Joined Feb 2007
Total Posts : 1951
| Posted 2/20/2008 6:04 AM (GMT -7) | | With the scrambling done in hardware it is very likely to be 'instantaneous' to not slow down loading, but that can include feeding through an LFSR, XOR's, barrel shifting, bit swapping, and may be affected by previous unscrambled results, on top of that there could be address re-ordering ( using all the same tricks ). All easy enough to implement in silicon and multiple scramblings may be taking place.
The first question is; is it byte, word or long scrambled ? Does anyone have a pointer to information which shows how the ROM is actually configured in silicon ? Perhaps someone with some experience could look at the Die images and give an answer ? Are there any other 'helpers' which looking at the Die image reveals ? Anyone have a link to the Die image; I cannot find it ?
Although the actual interpreter code is unknown, I believe it's a reasonable guess that the first instruction in Cog is likely to be a 'mov', and PAR will be used early on to utilise the data provided by CogInit along with some 'rdxxxx' code and that's at least a helper towards recognising if descrambling is working and maybe towards it. At least it gives a needle to be looking for in the haystack.
I created a Propeller Wiki page with some links to related and useful information which everyone is welcome to add to ...
propeller.wikispaces.com/Cracking+Open+the+Propeller+Chip | | Back to Top | | |
| 202 posts in this thread.
Viewing Page : 1 2 3 4 5 6 7 8 9 |
| Forum Information | Currently it is Thursday, July 29, 2010 5:23 PM (GMT -7)
There are a total of 462,441 posts in 62,066 threads.
In the last 3 days there were 90 new threads and 802 reply posts. View Active Threads
| | Who's Online | This forum has 20143 registered members. Please welcome our newest member, ME01.
57 Guest(s), 14 Registered Member(s) are currently online. Details
John Abshier, Erik Friesen, RossH, Kevin Wood, simpsonmichael1, David Betz, Julian800, Martin Hodge, RDL2004, Harley, Sapieha, wiresalot, Ravenkallen, Tubular |
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2010 |
|
|