只要单片机具有真正唯一ID,就可以让加密坚不可摧(转)

源:只要单片机具有真正唯一ID,就可以让加密坚不可摧

http://www.amobbs.com/thread-5518980-1-1.html

第一环:
ID-->F1(ID) -----》IDX,
将ID通过自定义的一个算法F1,转换为一个整数IDX , F1为不可逆运算,也不能被轻易分析,这个实际上是容易实现的。
然后,将IDX保存到EEPROM或FLASH的任何地方,我们通过编一个函数 GET_IDX()能够读出这个数即可。

第二环:
再编一个函数:
int getmy_1()

{

return F1(ID)-GET_IDX()+1;

}

int getmy_0()

{

return F1(ID)-GET_IDX();

}

还有一些其他自定义的函数内:都可以直接使用(F1(ID)-GET_IDX()) 来替代0; 直接用(F1(ID)-GET_IDX()+1)来替代1;

第三环:
在程序任何需要使用到1的地方,都可以考虑使用getmy_1()代替。
或即使本不使用1,也可以来用上一下:
如: x=(x+1-getmy_1())*getmy_1();
或把

for(i=0;i<=count-1;i++)  改为: for(i=getmy_0();i<=count-getmy_1();i++)
抑或是:
指针 p++;可以改为: p=p+getmy_1();
或者:给函数传递变量时,传递方在 变量上+F1(ID), 被调用的函数在 变量上--GET_IDX():
比如本来是

void f1(){ int i,j; .... j=f2(i); }
    int f2(i){ return i*2; }

修改为:

void f1(){ int i; .... j=f2(i+F1(ID)); }
    int f2(i){ return (i-GET_IDX())*2; }

如程序被非法复制:从ID无法得到IDX,那么IDX和F1(ID)不相等,
那么getmy_0不再是0,getmy_1不再是1,
程序将出现什么结果,谁都无法预料了。
---------------------------------------------------------

特点: 由于整个程序的加密,采用了“运算加密”的思路, 而非判断加密, 又没有用到任何一行 if判断,让解密者去想破脑袋吧。

即使猜测到有可能是这种加密思路,但是程序并不是基于if判断跳转,加密的作用自然分布在程序的各个地方,怎么去改,也很伤脑筋了。 直接修改getmy_1和getmy_0,这个首

先是得分析出加密思路时才能作出的。

另外修改getmy_1和getmy_0只是干掉简单的部分。

还有一些是很难干掉的:
给函数传递变量时,传递方在 变量上+F1(ID), 被调用的函数在 变量上--GET_IDX():
比如本来是

void f1(){ int i,j; .... j=f2(i); }
int f2(i){ return i*2; }

修改为:

void f1(){ int i; .... j=f2(i+F1(ID)); }
int f2(i){ return (i-GET_IDX())*2; }

另外,包括一些全局部变量的处理,可以在一些函数里面加上F1(ID); 在;另外一些地方进行-GET_IDX()的操作,并不会将代码简单集中放到一点的。
当然,如果精准的理解了整个程序的加密思路来说,这个也可以花时间干掉,不过这种加密方式本身目前是很少有人用的。
总之这种加密强度远高于简单的if比较方式。这个是一个新的基本思路,我举的例子只是一些简单的例子,完全可以自己做得更加灵活。

F1当然是一样的啊。只是ID不同。

顺便回复上楼,我有个前提: 只要单片机具有真正唯一ID,这个意思包含: 单片的ID不可以复制。
你说那个地方只是怎么去拷贝程序出来, 如果单片机具有真正唯一ID, 拷贝程序是没有用的。

大家先别拍砖头,思路很不错。从复杂度上已经增加到了一定程度。 建议做成强制in-line,否则对破解人来说太明显……因为大量的逻辑都指向某一个或某两个函数…… 别低估干这行的智商——所谓没有金刚钻,不揽瓷器活。另外,用减法做比较也是业内常识……其它还有用异或结果是否为0……这些都是常见的特征…… 对, inline!好思路, 必须的!

代码尺寸就上去了哦~ 执行效率也随之受到影响……不过如果有内部的什么1~4个周期的硬件CRC之类,就可以 解决效率问题,并且彻底把算法隐藏好……问题是……这个CRC硬件最好是不公开的才行……有一些芯片还有一些特殊矩阵转置(permutation)外设——也都没有对外公开……

隐藏加密算法的加密应用范围受到影响,因为用的人多了,自然就公开了,公开加密算法,没有密钥但依然很难解密的才有生命力,楼主这种思路是能够增加破解的困难,不过只能给盗版者加工资。当然有些小产品,利润和市场本来不大,盗版的成本太高也的确能保护可怜的程序员

所有的单机程序都是可以破解的,真正要保护自己的成果其实并不是通过加密,而是通过网络服务,这就像杀毒软件,只要联上网,主动权永远掌握在自己手中,这样的软件根本就永不着加密。就像微软的WINXP,再怎么加密也会被破解,但是只要联网,就可以黑你屏,就像单机游戏,今天做出来,明天就被破解,可是网络游戏,你见过破解的吗?除非入侵服务器,只要一入侵就被发现。所以单片机要想完全保护产权,就要提供网络化服务。

首先不要忙着拍砖,我来整理一下思路。利用全球唯一ID(每颗MCU都有一个唯一ID)的加密精髓在于防止程序轻易读出的情形,甚至HEX ROM根本无需加密,和破解读出HEX code的难易程度没有关系。实际上只需要两步: 1.自己想一个认为非常好的算法,利用MCU的GUID生成另外一个ID(可变长),再自己设计一个下载器(加密算法也在里边)烧录到EEPROM或Program ROM里边。保管好烧录器,不要外泄。你的烧录器就是一个加密工具! 2.在你的程序当中分布式的对用烧录器烧进去的加密后ID解密。这个比较重要,因为解密代码写的过于集中便于反汇编分析。比如不要解密后不正确不要进入死循环,不要立刻封杀所以功能,如果是盗版你故意给他几个致命BUG,让他抄袭后生产退货,损失更大。加密的结果就是烧录到每个MCU的HEXCODE是不相同的,即使读出了一个MCU的HEXCODE,烧到另外的MCU是不能通过解密算法验证的。唯一的解密的方法是去分析你得HEXCODE,分析出加密算法,破解者再设计出和你一样的烧录器!总之,这个方法只能对比较大的Program ROM有效果,如果是小的MCU,比如只有1KB ROM就很难做好,毕竟代码少,容易分析。说实话,如果有这样的功底的工程师去反汇编你的代码,说不定他就正向设计来得更快!这只是防盗防火防小人而已。

用simlator去跟踪程序。然后找到GUID。替换掉即可。

STM32的UID有一部分是说明这个片子在晶圆的XY坐标位置的,一个晶圆上面所有的片子UID都不一样,至于不同晶圆的UID如何实现不同我就不知道了。。在晶圆上实现个唯一ID又难了?激光几闪,随机割断96个硅片的导线就获得了96bit的唯一ID了------------------------

楼主这个加密方法确实不错,不过前提是inline的方式,否则频繁调用某个函数很快就会被发现,另外加密后的IDX最好在启动时就读取到RAM中,否则频繁读取某个FLASH或EEPROM位置也很容易被发现,最后,还需要选用解密成本较高的单片机,如最近一个朋友想解密一款NEC的单片机,读出ROM的费用就需要近20万。 另外楼上说这个方法简单的,只是因为你已经看到了楼主的加密思路,如果现在是先给个用这种方法加密的固件出来,我想就不会有人轻易下结论了。如果是inline函数并上去的话,那么有个小问题就是代码量会超大。

楼主要研究软件的加密算法,建议先去学习一下现在windows下一般应用软件加壳的各种原理,唯一ID在这个领域是完全不新鲜的一个东西,最常见的就是软件根据CPU、硬盘或网卡的MAC来生成一个所谓硬件ID让用户注册。 而算法加密更是五花八门,除了加密条件判断外,还有代码的动态解码,就是用正确的KEY来解密函数A的代码,再跳过去执行,下次解码函数B时又会覆盖函数A的空间等等。 还有虚拟机加密,把一段x86代码转换为MIPS代码,在虚拟机中运行,这样如果破解不知道虚拟机模拟的是哪种汇编指令的话,反编译就会很累,代价就是运行速度下降。

适合有很大rom的mcu 可以加入一些垃圾代码。读取硬件id或软件id的这两个点是爆破的主要地方。例如固件整体验证的就是硬件id, 就算自己编写编程器变换固件内的其它key位置等, 整个算法验证的还是当前的mcu的硬件id是不是与这个固件匹配只要找到读取这个id的地方补丁一下就完了。这个其实就类似与pc机上绑定机器的软件的加密时一样的。

你的方法必须保证你读唯一ID的行为不被破解者看出。像STM32的独立ID在某个固定地址,那么只要找出访问那个地址的语句就可以了。

现在有不少量产编程器都支持根据唯一ID变换一些数据写入指定地址,甚至支持自己编写变换插件,每个单片机的程序都不一样是完全可以做到的。

你算法设计的越复杂,如果不是用来直接保护你自己的利益,那么就是为他们谋福利了。

什么坚不可摧。专业的加密芯片都可以摆平。何况这玩意儿?

时间: 2024-10-09 23:27:29

只要单片机具有真正唯一ID,就可以让加密坚不可摧(转)的相关文章

分布式系统唯一ID生成方案汇总

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结.生成ID的方法有很多,适应不同的场景.需求以及性能要求.所以有些比较复杂的系统会有多个ID生成的策略.下面就介绍一些常见的ID生成策略. 1. 数据库自增长序列或字段 最常见的方式.利用数据库,全数据库唯一. 优点: 1)简单,代码方便,性能可以接受. 2)数字ID天然排序,对分页或者需要排序的结果很有帮助. 缺点: 1)不同数据库语法和实现不同,数据库迁移的时候或多数据库版本支持的时候需要处理. 2)在单个数据库或

高并发分布式系统中生成全局唯一Id汇总

高并发分布式系统中生成全局唯一Id汇总 (转自:http://www.cnblogs.com/baiwa/p/5318432.html) 数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求:   1 不能有单点故障.   2 以时间为序,或者ID里包含时间.这样一是可以少一个索引,二是冷热数据容易分离.   3 可以控制ShardingId.比如某一个用户的文章要放在同一个分片内,这样查询效率高,修改也容易.   

生成唯一id

有时候在某些业务中需要先生成一个唯一id,然后再进行存储.可以使用一下的方法: 1.借助mysql或者redis这类能够自增的数据库 这种方式可以满足需求但是需要跟数据库有一次额外的操作.对性能有一定的影响 2.毫秒级的时间加上一个随机数. 这种方式不需要借助数据,性能高些,但是随机数可能会重复,所以结果可能不是全局唯一的 3.毫秒级的时间加上进程id 这种方式可以既满足性能,又是唯一的 对于多核的cpu,每个cpu可以同时执行不同的进程,而每个进程有唯一的id,所以时间可能相同,但是进程的id

如何在高并发分布式系统中生成全局唯一Id

我了解的方案如下-------------------------- 1.  使用数据库自增Id 优势:编码简单,无需考虑记录唯一标识的问题. 缺陷: 1)         在大表做水平分表时,就不能使用自增Id,因为Insert的记录插入到哪个分表依分表规则判定决定,若是自增Id,各个分表中Id就会重复,在做查询.删除时就会有异常. 2)         在对表进行高并发单记录插入时需要加入事物机制,否则会出现Id重复的问题. 3)         在业务上操作父.子表(即关联表)插入时,需要

如何在高并发分布式系统中生成全局唯一Id(转)

http://www.cnblogs.com/heyuquan/p/global-guid-identity-maxId.html 又一个多月没冒泡了,其实最近学了些东西,但是没有安排时间整理成博文,后续再奉上.最近还写了一个发邮件的组件以及性能测试请看 <NET开发邮件发送功能的全面教程(含邮件组件源码)> ,还弄了个MSSQL参数化语法生成器,会在9月整理出来,有兴趣的园友可以关注下我的博客. 分享原由,最近公司用到,并且在找最合适的方案,希望大家多参与讨论和提出新方案.我和我的小伙伴们也

全局唯一ID生成器(Snowflake ID组成)

Snowflake ID组成 Snowflake ID有64bits长,由以下三部分组成: time—42bits,精确到ms,那就意味着其可以表示长达(2^42-1)/(1000360024*365)=139.5年,另外使用者可以自己定义一个开始纪元(epoch),然后用(当前时间-开始纪元)算出time,这表示在time这个部分在140年的时间里是不会重复的,官方文档在这里写成了41bits,应该是写错了.另外,这里用time还有一个很重要的原因,就是可以直接更具time进行排序,对于twi

分布式唯一id:snowflake算法思考

匠心零度 转载请注明原创出处,谢谢! 缘起 为什么会突然谈到分布式唯一id呢?原因是最近在准备使用RocketMQ,看看官网介绍: 一句话,消息可能会重复,所以消费端需要做幂等.为什么消息会重复后续RocketMQ章节进行详细介绍,本节重点不在这里. 为了达到业务的幂等,必须要有这样一个id存在,需要满足下面几个条件: 同一业务场景要全局唯一. 该id必须是在消息的发送方进行产生发送到MQ. 消费端根据该id进行判断是否重复,确保幂等. 在那里产生,和消费端进行判断等和这个id没有关系,这个id

分布式全局唯一ID的实现

分布式全局唯一ID的实现 前言 上周末考完试,这周正好把工作整理整理,然后也把之前的一些素材,整理一番,也当自己再学习一番. 一方面正好最近看到几篇这方面的文章,另一方面也是正好工作上有所涉及,所以决定写一篇这样的文章. 先是简单介绍概念和现有解决方案,然后是我对这些方案的总结,最后是我自己项目的解决思路. 概念 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识. 如在金融.电商.支付.等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID来标识一条数据或消息,数据库的自增I

分布式系统全局唯一ID生成

一 什么是分布式系统唯一ID 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识. 如在金融.电商.支付.等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID来标识一条数据或消息,数据库的自增ID显然不能满足需求,此时一个能够生成全局唯一ID的系统是非常必要的. 二.分布式系统唯一ID的特点 全局唯一性:不能出现重复的ID号,既然是唯一标识,这是最基本的要求. 趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来存储索引数