P2 under xray inspection
JRoark
Posts: 1,215
I have a project that has the potential to sell several hundred copies, but it is aligned in a marketspace that is completely dominated by the Chinese. Translate: the moment something better comes along they will try to reverse engineer it, steal the binary, and offer it for sale at half the cost. 🤨
The P2 was designed without any code protection, so all I can really do is attempt to hide the hardware and make it harder to figure out what is in there. I can pot the board in epoxy, and I can put a stiff piece of metal around it, but I cant stop a serious xray inspection.
This is probably a Chip question: Is there anything “unique” about the P2 internals under xray inspection that would be a distinguishing feature that could be used to ID the chip?
Comments
You could add a second chip, as a security protection ?
If that also uses the unique ID in the FLASH memory, that elevates their required effort way above any simply copy/clone.
I think just using a P2 may be enough to deter the chinese. AFAICT they'd have to import the chip from the US. And most reverse engineering tools do not have P2 support, so recreating the code for a different MCU would be difficult. If you have some sort of output that you can put a message on, some relatively simple defensive programming could make that quite hard to alter/remove.
PS: The code protection features on most MCUs are utterly worthless against anything beyond casually reading the flash through the intended tool. It turns out dipping the supply voltage at the right time can often defeat a fuse check.
IIRC we once had the option to purchase unmarked P1s.
Craig
@jmg Adding a second chip at this point is no problem, but I’m not following your thoughts here as to how it would make much difference. Can you expand a bit on this for me?
@Mickster The P2 will definitely have the markings removed before it gets encapsulated with the rest of the board. I havent seen any P2 offerings without markings, but I’ve got a Dremel tool that’ll deal with things thru the prototype stage. 🤣
I'd be impressed if they went to the trouble to port it off the Prop2. If they did that then they probably deserve to have the market.
You are trying to make simple copy/paste harder, so you can add a small MCU with secure flash, that P2 needs to transact with.
In one simple form, some 'known only to you bits' in Flash ID could define which parts of P2 memory need to rescramble.
Then after boot, P2 sends the RAM for a round trip thru the descramble part and replaces it, and the secure part is regularly pinged during normal operation..
A hacker now needs to capture RAM, rather than the easy clone-of-FLASH, and reverse engineer that, to even begin to know where to de-key things.
If they have that skill level, they probably do not need your code
On the P1 I use an EEPROM with a unique MAC address (24AA02E48). The MAC address is used by the bootloader to de-scramble the main program. So a simple copy of the EEPROM contents would not work on a different board. It's not completely impossible to reverse engineer the encryption but it's a lot harder than a simple copy.
My code self-scrambles on the first boot process so I don't have to generate different binaries for each board.
And BTW, the Chinese don't like the propeller because they have to import it and pay taxes. I tried really hard to find a chinese board house that offers assembly of PCBs with propellers. We had to do a lot of paperwork and negotiations...
That is a really interesting approach. Stolen with heartfelt thanks, @ManAtWork !
If there is one thing I have learned about the knock-off houses it is this: they CAN and they WILL steal anything that is not firmly bolted to the conference table. Its just the way they are wired. Taxes and such are merely a speedbump on the road, and there are any number of ways to avoid this.
If the expected audience will count for just a few hundred replications, not economically viable, but, for a few thousand, things can be different...
Almost four year ago (wow), Chip brought us some info, about the possibility of using one interposer, in order to aggregate, e.g., flash memory, and some other stuff (either active or passive), over P2 die, before proceeding to the final packaging.
Beyoud Onsemi, Amkor also offers simillar solutions, perhaps at competitive (and compelling) prices.
In place of a standard flash memory, jmg's idea of using a protected microcontroller (in KGD/bare-die form) can provide enough copy protection.
At least P01(Test), P100 (RESN), P62/P63 (TXD/RXD) and any other ones involved in the ATE test programm injection/protocol must not be brought out from the final package, in order to avoid eavesdropping/perusing of any sensible information.
XI/XO are also good candidates for external access exclusion, and even some VIOs. The clock oscillator circuit can be provided by onboard protected micro, that sure, must have its own programming injection pis externally available, for customization.
For a finished (and also not too hot) BGA package, P2 can be "on top", and flipped, in order to enable the installation of a good copper heater spreader.
Pin 101 (GND) would translate to as many as GDN balls as needed (at the external perimeter of the BGA package), in order to ensure the minimum possible ground bounce.
Perhaps it'll not support more than, says, 250 MHz, but, as seen during the last years, with P2, good surprises will ever come...
https://forums.parallax.com/discussion/comment/1432015/#Comment_1432015
https://amkor.com/packaging/laminate/interposer-pop/
Would it help to tell the compiler to scatter regions full of content censored in China throughout the flash image?
@JRoark
On P1 I used a Ramtron FM31L278 chip, accessible through I2C. It contains an RTC, a Wtchdog, 32KB FRAM, a 64bit GUID and two 16bit event counters.
The protection was based on the counters that runs also on the battery backup of the RTC. They are used eg to detect PC chassis opening when powered off.
In my case I used the GUID (fixed) with the two counters (variable) value as a decryption key. Once the P1 transferred the image on its internal ram the first part of code reads the counters and guid values and decrypted the part of encrypted ram by simply looping over it and overwriting the encoded ram addresses with its decoded value.
On the board you can then use different circuits/sensors to drive the two event inputs (eg: a switch , light to frequency sensor, ...) as tamper device.
If the protection get triggered it advances the counter value making the decryption key invalid.
Take care on decrypted program validation somehow, as the first time I tried the protection I destroyed a few things because the P1 executed unexpected/unwanted(wrongly decrypted) code.
IIRC at the time they had also a SPI variant of the "processor companion" chip that perhaps better suits the P2.
Another thought might be an otherwise innocuous-looking (and dirt cheap) 1-wire temperature sensor. Something like a Maxim DS18B20 is guaranteed to come with a unique (64-bit) serial number. Buy yourself a box of them when building the boards, then put together a lookup table of 'all the known serial numbers of all the temp sensors I have'. A whitelist, as it were - because the copiers won't be able to get temp sensors with the same serial number.
If they just straight copy the binary but put in a different sensor, it will fail the lookup table step, and not work.
If you don't want a big lookup table, then you might want a two-step programming procedure - The first program, just in-house, determines that board, and that board only's, temp sensor serial number, and outputs that as an input to the next programming step - the actual running program, which takes the serial number of the temp sensor and compares it to the one it got from the previous program step.
If there's a different serial number in the sensor than what's stored, it doesn't work. Hashing it might be fun.
They also make, of course, 1-wire devices that just provide the serial number and don't do temperature at all. But they're more suspicious.
And again, if they're willing to hack the binary, then you're still out of luck. This is a cheap'n'cheerful idea, not something to protect nuclear secrets with. S.
Your idea could be extended by validating serial numbers with a Bloom filter instead of incurring the the size and crackability of embedding the list verbatim in your binary. It will have a small false-positive rate, causing it to very rarely work with non-whitelisted devices, which will probably just confuse copiers more than if it just never worked for them.
And then to prevent them from tampering with the Bloom filter table or with other parts of the program, include another piece of code that only allows the program to run if a weak 16-bit hash of the Bloom filter table matches some other 16-bit value similarly derived from the rest of the program. When you generate the Bloom filter table, you'll need the program that generates it to figure out by brute force which few extra bits to set to cause the hash to collide, but the copiers hopefully won't understand this is all they need to do. (You must only set bits, slightly increasing the false positive rate; clearing any bits will introduce false negatives.)
Wowzers! Just checking in on this thread again and one thing is crystal clear to me: we have an impressive brain trust here. I have a LOT of reading to do!
Here is a huge THANK YOU to everyone who has posted! I’m on it… at least as “on it” as a humble Lilliputian can be in the Land Of The Giants🤣
Sincerely… thanks to all.
Late comment, but unless there is something in your project that only the P2 can solve, doubtful code protection would help. As noted above, there are many rip-off houses, no doubt they could rip/strip/copy your idea to any bottom feeder MCU. Seems your best bet would be to quickly saturate your intended market and provide a product that your direct support is a value added component. Very hard to duplicate you cheaply enough to make a knock-off worth doing. That may perhaps discourage the rip and dumps from bothering with it as well as making a properly supported product more desirable to the purchaser. Guess you are safest when they can't make something able to undercut you by enough and enough volume to make a yuan... I mean buck.
This might be a good way to help customers know if they got a knock-off. Perhaps a composite video output with banned images. Of course, some might knowingly buy a knock-off.
For very high volume applications, mask ROM.
I only need a way to disable P2 feature that sends back a copy of the code in NVRAM through serial port; as I understand it is done to verify code upload, right?
I can take care of the rest of security.
Banned images like the famous "tank man"?
That is not what the DOCs suggest.
There is no serial loader read back, a verify check is optionally done by append of 4 checksum bytes and a '?' and the P2 echos with a '.' if the checksum matches.
DOCS :
There are four commands which the sender can issue:
1) Request Propeller type: Prop_Chk
2) Change clock setting: Prop_Clk
3) Load and execute hex data, with and without sum checking:
Prop_Hex ?
Prop_Hex ~
4) Load and execute Base64 data, with and without sum checking:
Prop_Txt ?
Prop_Txt ~
I'm not sure how much memory can be read back on the other possible pathways in the docs
If the serial bootloader is accessible, you can replay out the flash contents to your heart's content. You can set the boot configuration to skip the serial loader entirely, but that disables any reprogramming and obviously you can't stop someone from just changing the pullups to re-enable it. Or stop them from glitching the supply voltage to bypass the pullup check. Or stop someone from just desoldering the flash chip and reading it out some other way. The only actual way to stop the code from getting read out is to store it in a battery backed RAM chip and then rig it so you can't futz with the hardware without disconnecting the battery. However, if you do that, you are literally evil and should dig your own grave at the disservice you are doing to your customers.
I think the only completely safe way is the not use the flash chip, load the code via serial port, and then keep the P2 always powered, with good battery backup.
You can use a third chip, a small MCU that can encrypt some or all of the FLASH memory, as well as provide a handshake key, to slow someone down.
It depends exactly what the OP in #19 is trying to protect against ?
Yes this is the way to do it, but also park the secure stuff inside a running cog, and wipe over its image in hub from when the cog was loaded.