reverse engineering
kalbun
Posts: 3
Hello everybody, I just joined your forum as a new user of BS2.
I plan to use BS2·for an industrial prototype but, if the device acts well, we could even decide to adopt it as the final platform.
The device we are planning seems to be rather interesting for our Customer, so I am worried that someone can "steal" the tokenized code and decompile it (once you have the tokens, I suppose that obtaining the source is extremely easy).
Have someone else had the same issues?
Looking in the forum I only found very old answers and not fully satisfactory.
The only possible way I could think is deactivating the programming port, provided this is possible. This would make the BS2 no longer modifiable, but this could be acceptable.
Bye
· kalbun
I plan to use BS2·for an industrial prototype but, if the device acts well, we could even decide to adopt it as the final platform.
The device we are planning seems to be rather interesting for our Customer, so I am worried that someone can "steal" the tokenized code and decompile it (once you have the tokens, I suppose that obtaining the source is extremely easy).
Have someone else had the same issues?
Looking in the forum I only found very old answers and not fully satisfactory.
The only possible way I could think is deactivating the programming port, provided this is possible. This would make the BS2 no longer modifiable, but this could be acceptable.
Bye
· kalbun
Comments
Once the program is complied, the source code ceases to exist. Thus there is NO way anyone can steal the original source code with only the token file.
If one asked the question: Could you create new source code from the tokens? - Yes, but nothing would be commented, the variables would not have names, and none of the target addresses (GOTO xxx, GOSUB xxx, etc) could be determined by name. You would have quite a mess on your hands trying to make anything useful out of the new source code. Even beyond that, the tokens are often variable in length, and are not human-readable (more like binary).
This question is often asked, and to date I can't think of anyone who hasn't forged forward with the Stamp platform due to this type of concern. There have been MANY before you who have had similar programming concerns, and the source remains secure to this day.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Involvement and committment can be best understood by looking at a plate of ham and eggs. The chicken was involved, but the pig was committed. ANON
nearly impossible to translate that code into usable source code.
I'm basing this off a bunch of posts I've read about retrieving code from the BS2 after losing the original source... almost
everyone says its not possible.
I think that's also the offical statement that Parallax holds to... although I could be wrong.
Can we get some word from Parallax on this? If its just a matter of writing a reverse compiler... I'm sure someone would
want to take the challenge on.
There have been long discussions on this point, most recently with regards to the Propeller. A determined and well-equipped thief can steal the code from any processor including those with on-chip flash ROM and "protection" fuses. Specifically with regard to the Stamps:
1) As you've noted, the Stamp program is compiled into byte codes with all the information about variable names, labels, etc. removed as is typical for compiled programs and the byte codes are what are downloaded to the Stamp.
2) The byte codes are not publicly documented. People have figured them out, but the information is not readily available.
3) It's possible to convert the byte codes back into compilable source by creating labels of the form "X0001", "X0002", etc. and using names like "W3" and "B7" and "IN3" for variables, but any explanation of what things are and what the program does is missing.
4) The only way to actually retrieve the byte codes from the EEPROM is to download a new program that READs what's left in the EEPROM and sends it to the connected PC. This program will overlay a small portion of the existing program (the end of it) which can't be retrieved that way. The only way to get the whole program is to solder wires onto the EEPROM or unsolder it and remove it from the module and use some kind of external device to read it. The EEPROM is a small SMT component and the thief has to have the right equipment to do this and a bit of skill and experience as well.
The most interesting point is that (as stated by Mike), you have to destroy a part of the existing program to download it. The key could be storing some critical part of the program at the end of the EEPROM. I will think a bit on this...
Kalbun
Actually wouldn't it overwrite the beginning of the program since PBASIC programs are loaded from the high address downward?
' {$STAMP BS2} ' {$PBASIC 2.5} sensor_data VAR WORD okay VAR BIT DATA WORD 43552 READ 0, WORD sensor_data 'read checksum IF sensor_data = 43552 THEN 'verify checksum okay = 1 'set okay GOTO start 'start program ELSE END ENDIF routine1: '<DO stuff> routine2: '<DO stuff> start: IF okay = 1 THEN GOSUB routine1 GOSUB routine2 ELSE END ENDIF▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1010, so be surprised!
Here is one possible solution.
Put a Photo Transistor on a port.
Read the port and if there is light on the Photo transistor the port will be low.
If low, then run a routene to overright important code.
Protect the Stamp with an inclosure and if no one knows about it the code is safe.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
D. A. Wreski
If the device ever needs repair, it will have to be done in the dark, at least until the phototransistor gets covered. Typically, someone who's repairing the unit would turn off the unit before servicing anyway. Someone who wants to steal the code would buy one unit, open and examine it, then they'd know to turn off the power before opening the 2nd unit. Without power, the Stamp can't run and erase the code.
If I wanted to 'copy' your code, I would just remove the Eeprom, and then attach it to another stamp, and use that stamp to read the Eeprom in, then send it out to another Eeprom. I then have a way of making an exact copy of your code. Thats the easy bit, now the real problem here is when I have to...
-Find out what the heck it is that you do with your program.
-Copy the hardware around it.
-Find your client list and convince them / prospective new clients·that mine is better.
- AND MOST IMPORTANTLY - I need to support my new clients (that I stole from you only if you werent supporting them properly), and all the time I would be hoping you did a good job with your software / hardware design, because·I wont be able to really support it properly, unless· I designed it all myself.
...
So what I'm really saying, is that if you have a commercial product, and you dont rip anyone off, and you do your best to support it, then you wont have an issue, because its just not worth anyone bothering.
Also, anyone capable of all of the above, will be able to design their own product anyway, and be able to support it, so they wouldnt bother to risk it with yours.
Dont stress·too much about having·your software 'stolen', its not a big deal unless you are making something in the thousands, and making big bucks out of it. And if you were making a product in the thousands, economics would suggest you went to another type chip that cost less and was more secure. (Me, I'm staying with stamps, and have used thousands of them).
If it is that much of a concern to you though, just put a 1wire serial id number chip on the board, read the id number and look for the number on startup. At least that way that Eeprom containing the code will only operate on one circiuit board. If·the stamp doesnt·find the correct 1wire chip on startup, just start writing zeroes over the Eeprom until it crashes.
Now, I'm not saying it cant be done, but anyone that can get around that one or actually decompile your code from the Eeprom, is capable of designing whatever the heck they want to.
Cheers,
Chris, West Oz
I could use the idea of the iButton. Indeed I will use at least one iButton for the RTC and maybe a second one to have an external memory.
I also agree that having reasonable prices and giving a good service SHOULD give a better protection than any hardware/software mechanisms. In my experience, unfortunately, this is often untrue, especially for Customers in the Public Administration who often move to a different company/product if they can pay one cent less - no matter the quality of service.
But I feel I'm going off topics... so I stop now. Thank you very much for all the precious suggestions!
Cheers,
Morrolan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Flying is simple. You just throw yourself at the ground and miss.
"I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image."
Stephen Hawking
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Flying is simple. You just throw yourself at the ground and miss.
"I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image."
Stephen Hawking
A lot of products out there have large black "blobs" covering their ICs to protect them from reverse engineering.
I'm not sure what the heck the blobs are made out of, but they are some seriously tough stuff. Try to get it off to
even see what the IC is, and 99% of the time you break the IC.
If the blob is non-conductive and spreads heat well enough... couldn't you cover an entire stamp in it on a finished product?
Thus pretty much rendering it tamper-proof?