Dealing with partial code tampering on external memory

[ajie_dirgantara]

I've understand that code protection is overrated and python is built with openness in mind. But what is the best method to avoid partial code tampering, especially on external memory? How to avoid people decompile, and then put some illegal python codes while retain it's current functionalities?

let's work on some use-case, with targeted codes located in external storage (sdcard/flash), internal memory is JTAG fused:

1. Said I've got the code compiled into .mpy, put the bytecodes in sdcard. Attacker could retreive the bytecode and mess with it. Exception will raised and REPL is exposed. From there, attacker could read code in the internal memory and do anything they want including partial tamper the codes located in external memory.

2. Disable REPL. Said attacker retreive bytecode and then put some effort to decompile .mpy, then he put code that enabling REPL. REPL is exposed again.

3. Disable REPL support entirely when compiling the mpy image (is this possible?). Still no good. Even without REPL, attacker still able to dump the internal memory/ mpy code via uart.

4. Disable "stm" in stm32 ports, or any memory access module in other boards (again, is this possible?). This will avoid attacker to exploit memory access functionality.

any thoughts?

[pythoncoder]

A forum search will show that this topic has been extensively discussed. IIRC the conclusion was that the best that can be done is to implement the application as frozen bytecode stored in the device's Flash memory. If an attacker has physical access to the device there is little to stop them from interrogating the stored bytecode or installing a firmware build of their own.

[deshipu]

I also would like to note that if by "attacker" you mean a customer who bought your device, owns it, and has full right to do anything they want with it, then you have a bigger problem than hiding your code from them.

[ajie_dirgantara]

A forum search will show that this topic has been extensively discussed. IIRC the conclusion was that the best that can be done is to implement the application as frozen bytecode stored in the device's Flash memory. If an attacker has physical access to the device there is little to stop them from interrogating the stored bytecode or installing a firmware build of their own.

I've understand the previous discussion was intended to "hide" and make it "protected". But here, it isn't the point. Say the attacker is able to read the code which is fine, but again, the point isn't it. The point is to make it hard, if not impossible, for them to mess around and tamper the code.
Even if they want to alter whole code, it is also fine as the effort would be tremendous to re-do what already had been done.

Problem is, when they do small effort to be able to alter some small functionality (e.g. bypass security checking by comment out some code) permanently untraced/unnoticeable. The whole system is running perfectly but the attacker successfully leaves a hole in the system.

[ajie_dirgantara]

I also would like to note that if by "attacker" you mean a customer who bought your device, owns it, and has full right to do anything they want with it, then you have a bigger problem than hiding your code from them.

The point is not to "hide" the code, but prevent it to be altered/tampered with. And no, the "attacker" won't be the customer who bought the device, but e.g. the competitor whose has bad intention to tamper the device and make it look bad.
Well, in real life this kind of thing happened. If it can detect tamper or become broken when tampered, it is considered good device. But if it is tampered and working with undetected wrong behavior, it is bad device.

[deshipu]

And no, the "attacker" won't be the customer who bought the device, but e.g. the competitor whose has bad intention to tamper the device and make it look bad.

If he paid for it, he's a customer and it's theirs to use however they like. If you are afraid that they will be distributing modified devices, there are laws in place to protect you from that, and I would recommend basing it on that, because there is no technical way to distinguish between a legitimate user and a "competitor".

Well, in real life this kind of thing happened. If it can detect tamper or become broken when tampered, it is considered good device. But if it is tampered and working with undetected wrong behavior, it is bad device.

In "real life" any anti-tampering feature simply just make the device easier to break, and harder to fix once it's broken. A small bug somewhere that normally would be hard to even notice or easy to work around can then become a serious problem rendering the device useless. I would strongly advise against installing any kind of such booby traps on things you sell to users.

[ajie_dirgantara]

If he paid for it, he's a customer and it's theirs to use however they like. If you are afraid that they will be distributing modified devices, there are laws in place to protect you from that, and I would recommend basing it on that, because there is no technical way to distinguish between a legitimate user and a "competitor".

Understand, the product usage is protected by laws. Any laws broken could be then processed accordingly, if it is detected. But the question is then how do we detect this by using what any available micropython features. This is what I wanted to highlight in the question. How far can we "write protect" code, by using what method, so it makes it isn't worth it to be actually do so.

In "real life" any anti-tampering feature simply just make the device easier to break, and harder to fix once it's broken. A small bug somewhere that normally would be hard to even notice or easy to work around can then become a serious problem rendering the device useless. I would strongly advise against installing any kind of such booby traps on things you sell to users.

Well, not really as if the customer itself wanted their product to be break if it is tampered, instead of working but not as designed. Take a sample of rented product. Our customers (A) is a service company, want their product to be working as designed as it is, when they rent it to their customers (B). But then (B) could alter something which harmful to (A) until the rent is due and (B) restore the original codes, hence leaves (A) unnoticed. If only we could have a way to make (A) knew that (B) is alter some code when this product is being rented. Broken product is considered good in this case, because (B) must go back to (A) to return the product.

[deshipu]

If he paid for it, he's a customer and it's theirs to use however they like. If you are afraid that they will be distributing modified devices, there are laws in place to protect you from that, and I would recommend basing it on that, because there is no technical way to distinguish between a legitimate user and a "competitor".

Understand, the product usage is protected by laws. Any laws broken could be then processed accordingly, if it is detected. But the question is then how do we detect this by using what any available micropython features. This is what I wanted to highlight in the question. How far can we "write protect" code, by using what method, so it makes it isn't worth it to be actually do so.

No, the *use* is not regulated (outside of some 3rd world countries with broken legal systems). What is regulated is the *distribution*. So I can do whatever I want with the things I bought, as long as I'm not selling (or distributing in any other way) them further, and not causing "harmful interference" with other user's devices.

[deshipu]

Well, not really as if the customer itself wanted their product to be break if it is tampered, instead of working but not as designed. Take a sample of rented product. Our customers (A) is a service company, want their product to be working as designed as it is, when they rent it to their customers (B). But then (B) could alter something which harmful to (A) until the rent is due and (B) restore the original codes, hence leaves (A) unnoticed. If only we could have a way to make (A) knew that (B) is alter some code when this product is being rented. Broken product is considered good in this case, because (B) must go back to (A) to return the product.

In that case I would recommend re-flashing the original firmware every time the item is returned before renting it again.

[ajie_dirgantara]

If he paid for it, he's a customer and it's theirs to use however they like. If you are afraid that they will be distributing modified devices, there are laws in place to protect you from that, and I would recommend basing it on that, because there is no technical way to distinguish between a legitimate user and a "competitor".

Understand, the product usage is protected by laws. Any laws broken could be then processed accordingly, if it is detected. But the question is then how do we detect this by using what any available micropython features. This is what I wanted to highlight in the question. How far can we "write protect" code, by using what method, so it makes it isn't worth it to be actually do so.

No, the *use* is not regulated (outside of some 3rd world countries with broken legal systems). What is regulated is the *distribution*. So I can do whatever I want with the things I bought, as long as I'm not selling (or distributing in any other way) them further, and not causing "harmful interference" with other user's devices.

What if it is the *use* which is regulated? and I believe it isn't just in 3rd world countries. Take an simplest example as the usage of clean water from water utility, Utility provide water to the customer, but then customer could tampering the water meter firmware so it fails to measure correctly, hence the utility is harmed. Well, I know water meter is sealed mechanically to protect what is inside, but the question is can we provide more added "security" on the firmware by adding a simple tamper-mitigation procedure?