-
-
手机阅读
在某种场合，有时不得不将Hex文件即程序代码交付对方自己烧写。
这在FLASH的MCU/ARM/DSP上会经常遇见，因为派人到对方现场ISP的费用太高。
故如何防止对方改写代码是我们需要考虑的问题。
这实际是已知代码反汇编源码的问题，如果不加以手段，那么任何反汇编软件
都会反出汇编源码，即使源码是C源码。
那么如何阻止对方反汇编及调试出程序真正的入口地址呢？？？
FLASH/EPROM大多都可以“二次写入”，即FLASH的某位为‘1’时可继续写入‘0’
但一旦写入‘0’时必须擦除后恢复为‘1’。
那么我们即可利用FLASH这一“特性”来保护真正的代码和数据在对方反汇编及调试时得不到所需结果。
我们可以将真正的代码(入口地址)和数据在HEX文件里让其为‘空’，即0xff/0xffff/0xffffffff
当首次运行时，解开一部分代码或数据，利用内部或外部看门狗复位，再次重复
解开一部分代码或数据...
这样复位N次后，真正的代码和数据才出现在FLASH中，程序才真正可以运行。
由于“解码”需要N次复位，故反汇编和调试工具也就无用武之地了。
实际应用中，一般要把显式调用函数改为结构函数指针调用。即类似COM接口技术。
它实际上是将重要函数的入口地址作为结构中的成员(函数指针表)。
若是我们将其申请为动态的结构指针，结构成员将要动态装载(函数指针表)，这样
我们即可将“解码”后的“数据”装载即可完成。
如何防止代码被改写呢？？？这实际是个很简单的算术问题。
假入真正的数据或代码为(前3位)：
01 02 03 FF.
求和为0B.
由于不为0，我们认为未“解码”。
由于“惧怕”反汇编及调试跟踪“断点”，故不能去判断这个0B不为0是错误！！!
应该将此值去对函数指针表进行“解码”运算，因为正确为0，那么+或^实际
函数指针表会不变的！！！
由于debug时，很难发现IAP调用，即FLASH二次写入，故用0B去“解码”肯定不对。
所以我们只需将FF二次写入F5即可得到：
01 02 03 FA
这样求和为0。
假若这个FA隐藏在别处，或为其他“解码”所用，那么对方想改写源代码，即
想改写01 02 03都会出错。这就达到了我们利用FLASH二次写入保护代码的目的。
假若用CRC等算法和多次复位加载等，对方“解码”难度肯定增强。
当然本主题是在MCU不被解密的前提下，HEX文件的保护问题。
1楼
0
0
回复
这在FLASH的MCU/ARM/DSP上会经常遇见，因为派人到对方现场ISP的费用太高。
故如何防止对方改写代码是我们需要考虑的问题。
这实际是已知代码反汇编源码的问题，如果不加以手段，那么任何反汇编软件
都会反出汇编源码，即使源码是C源码。
那么如何阻止对方反汇编及调试出程序真正的入口地址呢？？？
FLASH/EPROM大多都可以“二次写入”，即FLASH的某位为‘1’时可继续写入‘0’
但一旦写入‘0’时必须擦除后恢复为‘1’。
那么我们即可利用FLASH这一“特性”来保护真正的代码和数据在对方反汇编及调试时得不到所需结果。
我们可以将真正的代码(入口地址)和数据在HEX文件里让其为‘空’，即0xff/0xffff/0xffffffff
当首次运行时，解开一部分代码或数据，利用内部或外部看门狗复位，再次重复
解开一部分代码或数据...
这样复位N次后，真正的代码和数据才出现在FLASH中，程序才真正可以运行。
由于“解码”需要N次复位，故反汇编和调试工具也就无用武之地了。
实际应用中，一般要把显式调用函数改为结构函数指针调用。即类似COM接口技术。
它实际上是将重要函数的入口地址作为结构中的成员(函数指针表)。
若是我们将其申请为动态的结构指针，结构成员将要动态装载(函数指针表)，这样
我们即可将“解码”后的“数据”装载即可完成。
如何防止代码被改写呢？？？这实际是个很简单的算术问题。
假入真正的数据或代码为(前3位)：
01 02 03 FF.
求和为0B.
由于不为0，我们认为未“解码”。
由于“惧怕”反汇编及调试跟踪“断点”，故不能去判断这个0B不为0是错误！！!
应该将此值去对函数指针表进行“解码”运算，因为正确为0，那么+或^实际
函数指针表会不变的！！！
由于debug时，很难发现IAP调用，即FLASH二次写入，故用0B去“解码”肯定不对。
所以我们只需将FF二次写入F5即可得到：
01 02 03 FA
这样求和为0。
假若这个FA隐藏在别处，或为其他“解码”所用，那么对方想改写源代码，即
想改写01 02 03都会出错。这就达到了我们利用FLASH二次写入保护代码的目的。
假若用CRC等算法和多次复位加载等，对方“解码”难度肯定增强。
当然本主题是在MCU不被解密的前提下，HEX文件的保护问题。