Could a competing school read our EEPROM? (oops)

SuperCricket

Suppose at this competion you had many boards laying around. Suppose further you forgot one in a box and another school took our board back by mistake.

Would they be able to read our EEPROM and Spin/Spin ASM code?

I suppose I should better understand the architecture of the Propeller. Does the Propeller tool compile our programs into machine code and then load them onto the EEPROM? Or does it simply copy the code to the EEPROM with the Propeller decoding the program at run time?

rjo_

Almost.

The compiler produces something called byte code... which if you are complete genius and follow the forum, you could unwind.
But if your competition is smart enough to do that, you are toast anyway[noparse]:)[/noparse]

Rich

mctrivia

Unless you get my prop mod. The code on it is secure. Of course they could take it apart very carefully but it would be a lot of work and would probably damage the chip holding the code.

http://forums.parallax.com/forums/default.aspx?f=25&m=330600

rjo_

What mactrivia is talking about is that there are various kinds of theft. His mod makes it very difficult to copy the eeprom... which is all most criminals are smart enough to do.

Again there is a feedback system at work. If a guy is smart enough to do what he needs to do to steal this stuff, he really doesn't need to steal... that doesn't mean he won't, some guys enjoy stealing. Which makes it lucky for us that there are guys who spend all of their time catching thieves. For them, it is better than deep sea fishing[noparse]:)[/noparse]

virtuPIC

mctrivia said...
Unless you get my prop mod. The code on it is secure. Of course they could take it apart very carefully but it would be a lot of work and would probably damage the chip holding the code.

Oh c'mon... if you look at various SMD soldering tutorials you find instructions you to take it apart. And if you are willing to spend such a module for the code you can simply use a saw to get to the contacts...

I see only two ways to protect code from foreign reading. To burn it on the chip itself and lock it which is possible with AVR and PIC but not on the Propeller or to use some secure decryption algorithm on the chip for loading which is also not available. Of course, you can emulate the first version as mctrivia states for his mod - but then soldering an a board is not tight enough. You have to glue them together and make the contacts inaccessible somehow.

Okay, code is never completely safe. You only have to make it safe enough that taking it from the carrier is more expensive than the expected financial yield.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

mctrivia

Actually on my board there is no contact to the eeprom, SDA pin, or even the RX for the programing header once the security system is enabled. Yes sawing the module in pieces could get you access to the eeprom. no way to stop someone if they are willing to break the device.

On chip would be ideal but is not available with prop.

BradC

mctrivia said...
no way to stop someone if they are willing to break the device.

Potted or not, physical access means game over, all you are doing is raising the barrier to entry ever so slightly.

An AVR or PIC can be de-capped and probed. It's harder, but there are plenty of people around who have done it or will do it for a nominal fee.

If your risk assessment is such that it can be mitigated by potting the device then by all means, do it. Never underestimate the effect of "warm and fuzzy".

In this particular case a quick run through an X-Ray machine (available at any dentist, vet or airport) will tell you precisely where the pins are you need to access, and a quick run with a dremel and a carbide bit will expose them for probing and soldering.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

kensong

At school level, not realistically.

.SPIN (Spin code) will be in "Byte Code" format (compiled), the code is not readable as a "spin" program.
At run time SPIN programs are executed on a Cog by the cog loading a copy of the "Spin Interpreter" (stored in the ROM), the "SPIN Interpreter" is the program which is actually running on the Cog, it reads your SPIN program (stored as bytecode, loaded to the RAM on Propellor startup), decodes it and actually runs it.

Did I make that clear? Maybe not, so;

For SPIN programmes there is a "SPIN Interpreter" program in the built in ROM.
This program is loaded on to a Cog and runs.
This program then reads and executes your <object> program (the one you wrote).
Your <Object> program is stored in the RAM (and normally EEPROM) in "ByteCode" form.
"ByteCode" is a Compiled form of your SPIN code file, it cannot be read as "SPIN" code.

Assembly code is run directly on the Cog.
Assembly code is stored as single, 32bit instructions, the instructions have the form:
Instruction (6 bits [noparse][[/noparse]64 instruction types]), Indirect/Immediate status (4 bits), Conditional Execution bits (4 bits), destination (9 bits [noparse][[/noparse]0-511]) and Source (9 bits [noparse][[/noparse]0-511])
i.e. the bit groups are 6-4-4-9-9 = 32

So as you can imagine, this is not "readable" by eye.
The code can be read and "reverse engineered" out, several of the sage forum users have done this, but it would take time, expertise and some effort.
If your code is very simple, then it would be relatively easy to work out the functionality.
If it is complicated and hence the comments in your source code are very useful, then it would be more difficult, as the source code original structure and comments would not be available to the "decoders".

References:
Page 18(ish) and Page 349 "WebPM-v1.01.pdf" available on Parallax download page: http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/WebPM-v1.01.pdf

kensong

To get an idea of "Bytecode"

Load a program and do a view info (F8), then do "Show Hex".

Gadgetman

Note that as long as there's a programming interface on it, there's no need to 'get physical' to extract the code.
All they need is a short program with a I2C driver which they download to RUN in RAM without going through the EEPROM. This can then read out the EEPROM and dump it back the cable.

In other words, if you care enough about your program to 'POT IT', make certain that the usual programming tools doesn't work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

virtuPIC

Regarding assembly: The scheme of instruction composition is publicly known. It is well documented by Parallax. (As it should be for a processor.) If you fiddle apart the bit groups and decode them by simple table lookup you get a disassembler. Do it by hand or spend less than half a day of work to write such a program. You will get well readable assembler code. If you know the purpose of the program (which you probably do, why do you look at it?) you can also introduce symbols by text replacement.

Regarding SPIN-bytecode: You can also decode them to ASCII to make them readable. Their list is also public. Even more, if you know a little about compiler internals you can even build a deompiler that takes the bytecodes and delivers some corresponding SPIN code.

I consider reading assembler and writing a byte code 'readifier' school level. At least I did such stuff when I went to school.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

mctrivia

Gadgetman you are right about if you have access to the programing head you don't need access to the eeprom. That is why with my module after programing is complete you can destroy access to programing head by applying a negative voltage to the RX pin.

I never claim it 100% secure that just is not possible. Just trying to make it as hard as is possible. You need to first destroy the board to get the data then spend a lot of time to try and reverse engineer. much more time and harder then just having to reverse engineer and will deter many.