Code protect?

PABLOZIA

I want to knowing if the propeller the chi has protective code

or knowledge like implementing it ,thanks.

Mike_GTN

Hi Pablozia,

Propeller has no code protection devices, that I know of. A simple matter for anyone to uplift the contents of the external Eeprom using a reader and then programme a new Eeprom with the exact same firmware. I think the best solution that I read about here was hiding the·Eeprom under the Propeller chip. Now that really is a slave and master I2C set-up··You would still be on to a loser if the Prop was a 40 pin DIL mounted device (and would presume would have to be to get the clearance for the Eeprom sat underneath it)· ·Actually thinking about things further might just be possible to fit an SMD Eeprom underneath a soldered DIL propeller.

Regards

Mike.

Mike Green

The Propeller chip has no code protection provisions.· There have been several long and thorough discussions about this here, about why most code protection schemes are not as good as they seem, and some suggestions for making it harder to steal code from a Propeller-based product.

cgracey

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.

hippy

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.

cgracey

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.

Rayman

Isn't embedding the eeprom with the Prop a good solution?· OBC, I think, was just showing a cut-down Proto-board that could have a DIP layout.· If you just pot this in epoxy, and don't expose the i2c bus pins, it would take a lot of work to get the program out...

Harley

Chip said...

...By the way, can anyone out there figure out how to get the proper binary image of the current Spin interpreter from ROM?

Did I just hear a challenge?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

cgracey

Harley said...

Chip said...

...By the way, can anyone out there figure out how to get the proper binary image of the current Spin interpreter from ROM?

Did I just hear a challenge?

Yep! Maybe it hasn't been pursued, out of consideration to Parallax, but if someone posts the correct binary, I'll post the original source code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Phil Pilgrim (PhiPi)

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

Skogsgurra

We have had this problem in a device that is used to check voltage across bearings. We did put a 16F688 PIC on board and have a way of finding out if the PIC does the right thing to a crude picture (a matrix with pixels) that the Propeller sends to it. That is not a standard encryption algorithm and there are no readily available algorithms that you can test it with.

That is only part of the protection. The next layer is in the communication with a PC via USB. The PC then sends data to the Prop, which in turn sends the data to the PIC for modification. Another algorithm in the PC checks if the PIC/Prop answers as expected and, if not, shuts down.

So, even if you brake the first barrier and have a functional device that does what it is supposed to do, you will not like it when you connect to the PC to really use the data.

We do not sell this device to "computer people" and are not overly concerned with someone copying it. It is also being sold in limited quantities and it is not likely to be copied like games are. We actually didn't think about protecting it, but we needed the A/D in the PIC so it was only natural to use it for protection as well.

Sorry for being absent for a long time. Simply haven't had the time to hang around. Will try and chime in more often.
Oh, yes, BTW: Still love that chip. It is really great! What? If I am talking about the PIC or the Prop? Well, have your pick!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

hippy

Chip Gracey (Parallax) said...

Harley said...

Chip said...


...By the way, can anyone out there figure out how to get the proper binary image of the current Spin interpreter from ROM?

Did I just hear a challenge?

Yep! Maybe it hasn't been pursued, out of consideration to Parallax, but if someone posts the correct binary, I'll post the original source code.

Well; one cannot be more open or fair about it than that !

I'd considered it, but beyond that consideration to Parallax it seemed it would be an up-hill struggle for little real gain. I'd like to see the source one day just because I'm a curious hacker at heart and I want some "Aha! That's what it actually does" answers.

I had fun writing my own Spin interpreter and I'd really like to know how it matches with your own, what tricks I missed and what cleverness you used. There are also a few things which remain a mystery to me where I've obviously not captured your way of thinking yet.

Maybe now the challenge is out there

parsko

Every time this topic comes up, I keep thinking of the old "million monkeys at a million typewriters" line...

Chip said...
By the way, can anyone out there figure out how to get the proper binary image of the current Spin interpreter from ROM?

Can anyone explain exactly what this means to a person whom does not quite understand why this is important, or maybe post a link that does explain it?? Why is it so hard to figure out, I guess is the more pointed question? Isn't there some "magic key" embedded in the IDE that could be found?

-Parsko

Mike Green

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.

stevenmess2004

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

Phil Pilgrim (PhiPi)

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

stevenmess2004

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.

stevenmess2004

Looks like I was wrong. I have modified a version of my propAsm (PAL version attached) to display the contents of the ROM and I can't see anything useful (an encode instruction that is supposedly not implemented yet maybe it actually does something interesting). So as Phil suggested there is something else going on.

Phil said...
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

Would suggest the first option as there are a lot of instructions with very interesting condition bits and zcri bits. Also the first instruction is to write a byte to the hub which doesn't make sense if it is just loading straight from the ROM.

Post Edited (stevenmess2004) : 2/20/2008 10:06:35 AM GMT

stevenmess2004

It would be interesting to start a cog that copied some from the ram and some from the rom just to see what happens.

stevenmess2004

Time for some theory, If they use something in one place then they are likely to use it in another. From the prop manual

prop manual said...
The Propeller chip’s Random output is reversible; in fact, specifically it is a 32-bit
maximum-length, four-tap LFSR (Linear Feedback Shift Register) with taps in both the LSB
(Least Significant Bit, rightmost bit) and the MSB (Most Significant Bit, leftmost bit)
allowing for bi-directional operation.

The question is if this is used how do we figure out the seed? I seem to remember a post by Chip a long time ago that the interperter was scrambeled or something. Will have to go and look for it.

Also, if this is done in hardware, does the interpreter use the hardware version or a software version? There mustn't be one in the cogs because there is no room. There may be one in the HUB using the HUBOP instruction and a value greater than 7.

Post Edited (stevenmess2004) : 2/20/2008 11:41:19 AM GMT

CardboardGuru

What a very interesting thread.

It seems we might be looking for a 32 bit seed for an LFSR or a 32 bit value to XOR. These are very doable by brute force. But to do so the cracking program would need to know what a SPIN interpreter looks like.

Early codes and cyphers were often cracked using the knowledge of frequency of letters of the alphabet in a certain language or in the expectation of certain known words that were likely to appear. It seems to me one could do a similar thing here and score different instructions on how likely they are to appear in real code.

e.g. MOV would score big as they appear often in code.

JMP, RD*, WR* would score well.

ADD,SUB would be mid scoring.

MUXNC wouldn't score much at all. Possibly negative.

The opcodes reserved for MUL or other things thatr don't make sense would be negative.

Little used condition codes would score negative. e.g. IF_NZ_AND_C

The result of adding up all the scores would give a likelyhood of the code being real code.

You could use your best judgement to construct a score table. Or alternatively take real code, especially code known to be written by chip, and use it to construct the table.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

stevenmess2004

Tomorrow I'll try a couple more simple things like just inverting the bits.

stevenmess2004

Chip said...
The booter is at $F800 and the interpreter is at $F004. You will not be able to disassemble these programs, though, since the data is scrambled and only gets unscrambled by the HUB during launching. This is the only 'code protection' that the chip has and it's designed to slow down others from making me-too Propeller-like chip products. This issue has never come up before, but I figured your next post would be something about "How come this code looks jumbled?"

From here http://forums.parallax.com/showthread.php?p=593557
So, we know where the bootloader and inteperter starts and that the decoding is done by the hub.

hippy

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

hippy

CardboardGuru said...
MUXNC wouldn't score much at all. Possibly negative.
Little used condition codes would score negative. e.g. IF_NZ_AND_C

My impression is that Chip's a proficient and crafty PASM coder and used every trick in the book to get the interpreter into 496 instructions. I would expect to see code which us mere mortals would not normally generate.

That's not to say your idea is flawed, just be careful not to discount anything or the real interpreter might hide as a false negative.

CJ

if you look in the GEAR thread, Paul Baker posted the code for the random operation, should be big enough to search for

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

CardboardGuru

hippy said...
My impression is that Chip's a proficient and crafty PASM coder and used every trick in the book to get the interpreter into 496 instructions. I would expect to see code which us mere mortals would not normally generate.
That's not to say your idea is flawed, just be careful not to discount anything or the real interpreter might hide as a false negative.

Absolutely, that's why I mentioned using Chip's own code (from OBEX) as the best corpus to start with. And using scores to give a total fitness number, rather than excluding code based on unknown or unlikely opcodes. Chip will use wierd looking code in places, but no one can avoid biasing their code towards MOVs and the other really common instructions.

He does for example use series of instructions with conditions codes rather then jumping around code more than most. Actually, having series of LONGs with different values but the same condition codes might be another pointer towards real code rather than random numbers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

Post Edited (CardboardGuru) : 2/20/2008 2:16:12 PM GMT

Sleazy - G

···
·· Put a sensor between the hub and cog0 at boot and the first data you'd see would be the interpreter.

· Anyone got a high res pic of the die?

hippy

With enough computational power, one could try every possible Cog program and see which run as Spin interpreters.

I'm not sure that tapping into the internal hardware is in the true spirit of the challenge but would work. There was a die image posted but I cannot find it and I don't recall its resolution here ...

http://forums.parallax.com/showthread.php?p=680119

and some other extracts, here ...

http://forums.parallax.com/showthread.php?p=672115

A - COG RAM - (view of the ISDR Word Line drivers)
B - HUB RAM - (view of the Column Address Decoder)
C - HUB ROM - (view of the 4-16 Decoder driver)

The link to the Spin LFSR for randomising information ....

http://forums.parallax.com/showthread.php?p=624986

Post Edited (hippy) : 2/20/2008 4:06:34 PM GMT

cgracey

hippy said...
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

Hippy's got all the right ideas here, and then some.

I bet many of you believe that simple obfuscation is too weak a protection mechanism to be viable, but that is what you are facing here. What's been done with the executable ROM code is very simplistic as encryptions go, and almost nothing to design, but still poses a substantial headache for someone trying to unravel it.

The whole strength·of this ROM·'encryption' lies in the notion that nobody knows too much about WHAT they are looking for. For generic data encryption, much stronger algorithms are needed because the utility for inputing plain data and outputting encrypted data must exist, which·affords an interactive means of figuring out what is going on. Here, you don't have that, though·Hippy has made some accurate predictions about what you should be looking for.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Phil Pilgrim (PhiPi)

Looking at the code, I'm now dubious that an LFSR was used. There are too many bit patterns that get repeated, which would not be the case if they were XORed with the output of an LFSR. So I'm guessing the same transformation was applied to each instruction. Additional clues come at the end of the code block, where one would expect to find constants larger than 511 that can't be loaded with the immediate bit set. There's an FFFFFFFF, followed by an 00000008. Those numbers that are actually used as constants would have to be $200 or higher, else the space wouldn't have been wasted for them. So a transformation that converts 00000008 to 80000000, maybe? Hmm.

-Phil

P.S. Chip, I know you're enjoying this tremendously; but, please, no more clues! I know we can get it!