只要单片机具有真正唯一ID,就可以让加密坚不可摧。
本帖最后由 smset 于 2013-2-4 16:24 编辑第一环:
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,让其直接返回1和0 没有什么不能破解的,关键在于成本和时间 每一个单片机ID都唯一,还是每一款单片机ID唯一? 本帖最后由 smset 于 2013-2-4 16:40 编辑
直接修改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比较方式。这个是一个新的基本思路,我举的例子只是一些简单的例子,完全可以自己做得更加灵活。 dianzimingong 发表于 2013-2-4 16:36 static/image/common/back.gif
每一个单片机ID都唯一,还是每一款单片机ID唯一?
每个单片机都是唯一ID lz太年轻了,没有什么坚不可摧,http://www.amobbs.com/forum.php?mod=viewthread&tid=5515631&extra=&highlight=%E8%A7%A3%E5%AF%86&page=1,看看16楼,有这种人在,一切皆有可能。 那岂不是 每个单片机程序 F1()都不一样?
产量大的话....................... dianzimingong 发表于 2013-2-4 16:41 static/image/common/back.gif
那岂不是 每个单片机程序 F1()都不一样?
产量大的话....................... ...
F1当然是一样的啊。只是ID不同。
顺便回复上楼,我有个前提: 只要单片机具有真正唯一ID,这个意思包含: 单片的ID不可以复制。
你说那个地方只是怎么去拷贝程序出来, 如果单片机具有真正唯一ID, 拷贝程序是没有用的。 smset 发表于 2013-2-4 16:43 static/image/common/back.gif
F1当然是一样的啊。只是ID不同。
哦加密思路 了解了
只是对于破解有什么方法不太了解,就不发表评论了 大家先别拍砖头,思路很不错。从复杂度上已经增加到了一定程度。
建议做成强制in-line,否则对破解人来说太明显……因为大量的逻辑都指向某一个或某两个函数……
别低估干这行的智商——所谓没有金刚钻,不揽瓷器活。
你算法设计的越复杂,如果不是用来直接保护你自己的利益,那么就是为他们谋福利了。
没有什么不能被破解的软件
你的方法必须保证你读唯一ID的行为不被破解者看出。像STM32的独立ID在某个固定地址,那么只要找出访问那个地址的语句就可以了。 没有绝对的安全吧 dianzimingong 发表于 2013-2-4 16:41 static/image/common/back.gif
那岂不是 每个单片机程序 F1()都不一样?
产量大的话....................... ...
现在有不少量产编程器都支持根据唯一ID变换一些数据写入指定地址,甚至支持自己编写变换插件,每个单片机的程序都不一样是完全可以做到的。 另外,用减法做比较也是业内常识……其它还有用异或结果是否为0……这些都是常见的特征……
什么坚不可摧。专业的加密芯片都可以摆平。何况这玩意儿? Gorgon_Meducer 发表于 2013-2-4 17:02 static/image/common/back.gif
另外,用减法做比较也是业内常识……其它还有用异或结果是否为0……这些都是常见的特征……
...
{:lol:} 对, inline!好思路, 必须的! 编译时会不会给等价代换掉? smset 发表于 2013-2-4 17:11 static/image/common/back.gif
对, inline!好思路, 必须的!
代码尺寸就上去了哦~ 执行效率也随之受到影响……不过如果有内部的什么1~4个周期的硬件CRC之类,就可以
解决效率问题,并且彻底把算法隐藏好……问题是……这个CRC硬件最好是不公开的才行……有一些芯片还有一些
特殊矩阵转置(permutation)外设——也都没有对外公开…… 楼主天真了.这加密P都不算. sibtck 发表于 2013-2-4 17:25 static/image/common/back.gif
楼主天真了.这加密P都不算.
哎……话说好的算法都是不能拿出来说的……你就别对楼主那么苛刻了。 隐藏加密算法的加密应用范围受到影响,因为用的人多了,自然就公开了
公开加密算法,没有密钥但依然很难解密的才有生命力
楼主这种思路是能够增加破解的困难,不过只能给盗版者加工资。
当然有些小产品,利润和市场本来不大,盗版的成本太高也的确能保护可怜的程序员 lz太年轻了。。{:biggrin:} 所有的单机程序都是可以破解的,真正要保护自己的成果其实并不是通过加密,而是通过网络服务, 这就像杀毒软件,只要联上网,主动权永远掌握在自己手中,这样的软件根本就永不着加密。
就像微软的WINXP,再怎么加密也会被破解,但是只要联网,就可以黑你屏, 就像单机游戏,今天做出来,明天就被破解,可是网络游戏,你见过破解的吗?除非入侵服务器,只要一入侵就被发现。
所以单片机要想完全保护产权,就要提供网络化服务。 本帖最后由 logicgreen 于 2013-2-4 18:54 编辑
首先不要忙着拍砖,我来整理一下思路。
利用全球唯一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。替换掉即可。 逆向工程,倚天屠龙,只有你想不到,没有做不到 骚年,你想的太天真了.记住了,只要是人做的加密,人就能破掉你.除非,嗯嗯,你不是人.
成功的加密就是,你破解的成本高于收益,那就是成功了. 俺的感觉是所有的大批量生产的芯片都没有什么唯一id,唯一id也就是厂家生产后通过一定的方式写到某个地方的。如果,都有唯一id那么批量 生产如何廉价的实现?这些具体俺不太懂需要真正的专家来确认了。
就如,stc 唯一id 一样,就是自己写入的一个数据而已。 zhifeng 发表于 2013-2-4 19:48 static/image/common/back.gif
俺的感觉是所有的大批量生产的芯片都没有什么唯一id,唯一id也就是厂家生产后通过一定的方式写到某个地方的 ...
不要轻易下结论,STM32的UID有一部分是说明这个片子在晶圆的XY坐标位置的,一个晶圆上面所有的片子UID都不一样,至于不同晶圆的UID如何实现不同我就不知道了。。 没有不可解密,只有价钱高低
{:loveliness:} 在晶圆上实现个唯一ID又难了?激光几闪,随机割断96个硅片的导线就获得了96bit的唯一ID了------------------------ 假如要是有量子计算机,破解现有任何密码,也都是几秒钟的事 楼主这个加密方法确实不错,不过前提是inline的方式,否则频繁调用某个函数很快就会被发现,另外加密后的IDX最好在启动时就读取到RAM中,否则频繁读取某个FLASH或EEPROM位置也很容易被发现,最后,还需要选用解密成本较高的单片机,如最近一个朋友想解密一款NEC的单片机,读出ROM的费用就需要近20万。
另外楼上说这个方法简单的,只是因为你已经看到了楼主的加密思路,如果现在是先给个用这种方法加密的固件出来,我想就不会有人轻易下结论了。 如果是inline函数并上去的话,那么有个小问题就是代码量会超大。 本帖最后由 twitter 于 2013-2-4 21:40 编辑
楼主要研究软件的加密算法,建议先去学习一下现在windows下一般应用软件加壳的各种原理,唯一ID在这个领域是完全不新鲜的一个东西,最常见的就是软件根据CPU、硬盘或网卡的MAC来生成一个所谓硬件ID让用户注册。
而算法加密更是五花八门,除了加密条件判断外,还有代码的动态解码,就是用正确的KEY来解密函数A的代码,再跳过去执行,下次解码函数B时又会覆盖函数A的空间等等。
还有虚拟机加密,把一段x86代码转换为MIPS代码,在虚拟机中运行,这样如果破解不知道虚拟机模拟的是哪种汇编指令的话,反编译就会很累,代价就是运行速度下降。 适合有很大rom的mcu 可以加入一些垃圾代码
读取硬件id或软件id的这两个点是爆破的主要地方
例如固件整体验证的就是硬件id, 就算自己编写编程器变换固件内的其它key位置等, 整个算法验证的还是当前的mcu的硬件id是不是与这个固件匹配 只要找到读取这个id的地方补丁一下就完了
这个其实就类似与pc机上绑定机器的软件的加密时一样的 goodcode 发表于 2013-2-4 21:43 static/image/common/back.gif
适合有很大rom的mcu 可以加入一些垃圾代码
读取硬件id或软件id的这两个点是爆破的主要地方
例如固件整体验 ...
LZ的意思是说内联读ID函数。让他们改死去…… LZ 如果用8楼的方法 一切都是浮云 不过 现在的情况下 最好的方法是用现成的晶圆找厂家绑定成专用芯片 这样 一般级别的破解很难 哈哈{:lol:} 我还是不太明白上面的加密,弱弱地问一下,如果IC原厂给了一个唯一的ID,其他客户都拿不到这个ID的货,然后code里会去匹配这个ID。若是没有这个ID的IC匹配不上,则关机。这种情况是怎么破解的???若是破解IC就算了,而从hex(1~2Mbyte)中找出这个,估计够呛的。 xwkm 发表于 2013-2-4 23:12 static/image/common/back.gif
LZ的意思是说内联读ID函数。让他们改死去……
中国最不值钱的就是人工;
xinyou 发表于 2013-2-4 23:30 static/image/common/back.gif
我还是不太明白上面的加密,弱弱地问一下,如果IC原厂给了一个唯一的ID,其他客户都拿不到这个ID的货,然后 ...
你说的是主动失效,主动失效一般是有判断和跳转语句的,这个很容易被找到判断出来,然后把判断代码改写了就破解了,破解工作量也很低。
我现在提的思路是 被动失效,就是程序从不主动去判断,而是当出现Id不匹配时,通过一种机制让代码自然失效,而且这种被动失效机制可以广泛分布在代码里,从而加大破解工作量。
这种加密方式要hack掉真是太容易了:
1. 在程序的空白区域,添加一个函数,返回一个固定值。这个固定值就是被破解芯片的GUID。
2. 把所有读GUID的操作,都替换成调用这个函数。
所有的芯片都可以使用这个hack之后的程序了,GUID根本不起作用了。 xwkm 发表于 2013-2-4 23:12 static/image/common/back.gif
LZ的意思是说内联读ID函数。让他们改死去……
就读取id的代码内联了又能怎么样 数量级也不可能太大 尤其是通过高级编译器编译 代码形式都差不多 就算用汇编来写又能写多少 本帖最后由 smset 于 2013-2-4 23:57 编辑
mitchell 发表于 2013-2-4 23:43 static/image/common/back.gif
这种加密方式要hack掉真是太容易了:
1. 在程序的空白区域,添加一个函数,返回一个固定值。这个固定值就是 ...
是的,这个是有破解效力的,所以前面讨论了一种方式就是把GETID写为inline内联, 所以读ID的GETID并非一个函数了。
而且如果大量分布在代码里,(实现时,可以在程序编写完成后,统一把 =0; 替换为 =getmy_0() , 这样原代码里所有=0;
的地方都变为加密点,对于编程者而言这个文件内容替换操作仅需要1分钟而已,但对于破解者来说,就要花很长时间去到处修改)
同样=1;也可以这样干。只是代码会变大, 但也基本未丧失程序的可读性。
推而广之,同样可以=2; =3 。。。。。,只要flash够用。多多益善。
另外,程序空白区域的确是给破解者发挥的空间,我也考虑连空白区域都不给破解者,通过一种机制让整个Flash充满代码,哪怕是冗余代码(但也是有关联的,牵一发而动全身),不给破解代码落脚的空间。
总之,我觉得对于加密,不能太乐观,也不必太悲观,一切皆有可能。
smset 发表于 2013-2-4 23:55 static/image/common/back.gif
是的,这个是有破解效力的,所以前面讨论了一种方式就是把GETID写为inline内联, 所以读ID的GETID并非 ...
我觉得再加上这一个办法会比较有效:不写lock位,任其随便读出程序,读出的程序可以正常使用。但是如果GUID不匹配,程序会慢性自杀,自杀的期限可能1年、2年。
破解者以为轻松破解了程序,等到大量出货之后,死无葬身之地。
goodcode 发表于 2013-2-4 23:53 static/image/common/back.gif
就读取id的代码内联了又能怎么样 数量级也不可能太大 尤其是通过高级编译器编译 代码形式都差不多 就算用 ...
所以说要换种形式啊。类似jmp main我写成
*(SP+1)=&main >>8;
*(SP) = &main & 0xFF;
return;
如此等等。编译器再搞得变态一点,拼命用寄存器。内存到处占,到处插垃圾代码应该就能解决问题。
return;
本帖最后由 smset 于 2013-2-5 00:14 编辑xwkm 发表于 2013-2-5 00:05 static/image/common/back.gif
所以说要换种形式啊。类似jmp main我写成
*(SP+1)=&main >>8;
*(SP) = &main & 0xFF;
*(SP+getmy_1())=&main>>(7+getmy_1());
*(SP+getmy_0())=&main&(0xFE+getmy_1());
return;
{:lol:} ,在汇编语言来看,这是神马“乱七八糟的”代码啊,呵呵。
smset 发表于 2013-2-4 23:55 static/image/common/back.gif
是的,这个是有破解效力的,所以前面讨论了一种方式就是把GETID写为inline内联, 所以读ID的GETID并非 ...
这个也好意思叫加密程序,楼主你让我想起来那些卖小家电的宣传自己的产品由微电脑控制{:titter:} ,单片机穿上马甲就敢叫电脑
{:lol:} 那你说什么才是加密? smset 发表于 2013-2-5 00:12 static/image/common/back.gif
*(SP+getmy_1())=&main>>(7+getmy_1());
*(SP+getmy_0())=&main&(0xFE+getmy_1());
return;
这个这么搞确实看着头晕……
不过这么内联的效率大丈夫? 防弹衣可以抵当一般的子弹,要是换个火箭来试试{:lol:} 已x86为例 获得cpu的信息作为硬件绑定的运算 无论后面有多少加密运算甚至把加密运算混淆了在加vmp 其实最关键的地方还是调用cpuid这条指令的地方
这条指令vmp等虚拟机软件也是不能虚拟化的 所以... 本帖最后由 hhxb 于 2013-2-5 01:57 编辑
smset 发表于 2013-2-5 00:21 static/image/common/back.gif
那你说什么才是加密?
没有算法,没有技术含量;
你自己为天衣无缝的代码,别人获取HEX反汇编,找到与ID相关的代码(ID是存放在一个固定地址的,很容易找到)然后修改,批量替换;根本就不用理解你原来代码的意思
真正的加密应该是单向性很强的算法,在数学上能证明其可靠性。
hhxb 发表于 2013-2-5 01:00 static/image/common/back.gif
没有算法,没有技术含量;
你自己为天衣无缝的代码,别人获取HEX反汇编,找到与ID相关的代码(ID是存放在 ...
找id地址并不容易,比如uid地址是9999,我可以uint8_t *ptr=3000;ptr+=6999; 你在hex文件里面找9999是找不到我读uid的代码的。
说白了,你就是把我的mcu代码hex全读出来,也是不能用的,只能通过反汇编来找到反破解陷阱,而反汇编的成本极高,跟从头开发的成本进行博弈而已。
10k(bin文件长度,不计算中文字库这样的常数数组)以内的单片机程序,只要你有一个月10k以上的量,找单片机原厂FAE都可以给你免费开发,无需破解。需要破解的往往跟模拟电路有关的特殊算法 i55x 发表于 2013-2-5 01:17 static/image/common/back.gif
找id地址并不容易,比如uid地址是9999,我可以uint8_t *ptr=3000;ptr+=6999; 你在hex文件里面找9999是 ...
原来如此{:smile:}
i55x 发表于 2013-2-5 01:17 static/image/common/back.gif
找id地址并不容易,比如uid地址是9999,我可以uint8_t *ptr=3000;ptr+=6999; 你在hex文件里面找9999是 ...
有没有可能编一个脚本,让单片机单步执行直到读UID。
因为读UID前地址寄存器的值是一定的 hhxb 发表于 2013-2-5 02:00 static/image/common/back.gif
有没有可能编一个脚本,让单片机单步执行直到读UID。
因为读UID前地址寄存器的值是一定的 ...
有内存读写断点。 我还是觉得在单片机里面建立虚拟机才是王道啊。 http://oamajormal.blogspot.co.uk/2013/01/fun-with-masked-roms.html?m=1
演示用浓硝酸开盖,对rom拍照,然后用专门软件对图像识别,最终逆向出汇编代码。
erpao 发表于 2013-2-5 11:59 static/image/common/back.gif
http://oamajormal.blogspot.co.uk/2013/01/fun-with-masked-roms.html?m=1
演示用浓硝酸开盖,对rom拍照, ...
网页无法打开 erpao 发表于 2013-2-5 11:59 static/image/common/back.gif
http://oamajormal.blogspot.co.uk/2013/01/fun-with-masked-roms.html?m=1
演示用浓硝酸开盖,对rom拍照, ...
最后逆向出的软件解码解死你去…… 本帖最后由 xwkm 于 2013-2-5 14:19 编辑
hhxb 发表于 2013-2-5 02:00 static/image/common/back.gif
有没有可能编一个脚本,让单片机单步执行直到读UID。
因为读UID前地址寄存器的值是一定的 ...
最好的办法就是虚拟机执行不发作。然后量产了玩脱线,^_^。类似互相联网的设备。只要设备探测到联网,量产而且都是盗版机就自动风暴式死机擦除。如果能连电话线的设备就直接打坑钱电话。玩死他们……
读ID的函数一定要隐蔽。用指针变换加随机数的方式,最好一台机器一个独立的ID函数(随机数要自动发生,必要的时候那个内联函数可以被编程器改得面目全非)。然后虚拟机不发作,量产单独实验不发作,联网就风暴死机…… gzhuli 发表于 2013-2-5 03:01 static/image/common/back.gif
有内存读写断点。
读了也不来事,写新片正常工作。基本上没人怀疑这个HEX加了密 xwkm 发表于 2013-2-5 14:13 static/image/common/back.gif
最后逆向出的软件解码解死你去……
有人吃这行饭……做一单一年就可以啥都不干了,要你愿不愿意去耐心的追踪别人的汇编代码嘛?而且有以下事实:
1、主流编译器的代码有固定规律和模式,干这行有个几年经验就熟悉了
2、有大量他们自己开发的工具可以辅助
3、大部分人的加密算法复杂度并不超过3个LV,凭借1、2两条加上一点运气……你懂的……
4、芯片结构只对程序员是神秘的,对这群用显微镜的家伙来说,简直是赤裸裸的……而且不会说谎,很少有主流MCU
在芯片版图阶段做复杂的加密……
5、高门槛,蓝海市场,会者不难,难者不会。这帮家伙对计算机理论的理解超乎你的想象。
6、这个行业人数并不多,很多芯片可能就是他们当年设计或者Layout的…… Gorgon_Meducer 发表于 2013-2-5 14:22 static/image/common/back.gif
有人吃这行饭……做一单一年就可以啥都不干了,要你愿不愿意去耐心的追踪别人的汇编代码嘛?而且有以下事 ...
不是,我的意思是说,破出来的HEX烧到新片里能运行。而且一段时间还没事。然后我的芯片锁定都不写。轻而易举就复制了。估计没几个BOSS会花一大把钱去请软件逆向工程的人来吧?
至于编译器固定的模式我还真领教过。原来看gcc的代码几乎就是套固定模板,然后去无效指令的…… 本帖最后由 cash95 于 2013-2-5 14:31 编辑
不知道在嵌入式领域有没有混淆器这种东西,将C或汇编打乱执行,不过通过某些硬件应该实现混乱执行。
包括写入flash的代码也是混乱的,这需要特殊的引导代码和硬件来解密。 xwkm 发表于 2013-2-5 14:24 static/image/common/back.gif
不是,我的意思是说,破出来的HEX烧到新片里能运行。而且一段时间还没事。然后我的芯片锁定都不写。轻而 ...
恩,你这是唱空城计……属于加密的另外一重境界了。
我一般写代码都会基于一个事实,就是别人已经拿到我的汇编代码了。 cash95 发表于 2013-2-5 14:29 static/image/common/back.gif
不知道在嵌入式领域有没有混淆器这种东西,将C或汇编打乱执行,不过通过某些硬件应该实现混乱执行。 ...
混淆器是最弱的加密……只针对Java, .Net这种可以直接反编译出原代码的系统有用,可以说,机器码本身
就是最强的混淆器…… Gorgon_Meducer 发表于 2013-2-5 14:31 static/image/common/back.gif
混淆器是最弱的加密……只针对Java, .Net这种可以直接反编译出原代码的系统有用,可以说,机器码本身
就 ...
从gcc连接器上看,所生成的固件内存映像布局大致都是一样的,这样很容易就找到全局变量定义的位置之类的东西 cash95 发表于 2013-2-5 14:34 static/image/common/back.gif
从gcc连接器上看,所生成的固件内存映像布局大致都是一样的,这样很容易就找到全局变量定义的位置之类的 ...
全局变量的位置是固定的……引导代码几乎会很快开始拷贝全局变量的初始值到SRAM……很多所谓的加密算法,它的KEY
就是通过这种方式拿到的……也就是跑完初始化代码,去查SRAM……一串连续的8/10/16/20/24/32长度的字节看起来很可
疑,用这个东西去一验证……bingo~成功了。这样的案例在某次时代游戏主机平台的加密狗上真实发生过,某傻X公司用
Atmel的芯片……在中国被立等可取了……分析人员简单的用网上到处都是的AVR返汇编工具产生汇编码,载入avr studio……
10分钟内拿到了价值连城的KEY…… Gorgon_Meducer 发表于 2013-2-5 14:39 static/image/common/back.gif
全局变量的位置是固定的……引导代码几乎会很快开始拷贝全局变量的初始值到SRAM……很多所谓的加密算法, ...
so,这是个很大漏洞,加密的话首先要彻底打乱编译器的映像,然后将固件用rar或zip加密压缩进外部flash,启动时用硬件或者什么特殊方法解压缩到内存后执行。应该够解密的够玩一会了。当然,还是无法对付整个的内存导出这种终极干法。也许用变量函数的随机地址地址方式能对付一阵子。
纯理论,没测试过。工作中不需要这么高的加密程度,呵呵 Gorgon_Meducer 发表于 2013-2-5 14:39 static/image/common/back.gif
全局变量的位置是固定的……引导代码几乎会很快开始拷贝全局变量的初始值到SRAM……很多所谓的加密算法, ...
ATmel的芯片加密这么差,立等可取?我只记得貌似AT89S52的加密位是一下就挂而且FLASH还是从后往前擦的…… xwkm 发表于 2013-2-5 14:20 static/image/common/back.gif
读了也不来事,写新片正常工作。基本上没人怀疑这个HEX加了密
能打内存断点的,肯定是怀疑有加密,怀疑有加密且发现读ID,傻X都知道肯定有后着……
而且定时逻辑炸弹几乎必须配合RTC才能发挥作用,应用条件受限。
再说,逻辑炸弹这玩意搞不好连自己都栽进去,参考江民KV300事件。 gzhuli 发表于 2013-2-5 20:43 static/image/common/back.gif
能打内存断点的,肯定是怀疑有加密,怀疑有加密且发现读ID,傻X都知道肯定有后着……
而且定时逻辑炸弹几 ...
不是啦。我想很多公司破解出来直接烧片能运行他们认为够长的时间就行了吧。应该不会去反ASM的 xwkm 发表于 2013-2-5 21:50 static/image/common/back.gif
不是啦。我想很多公司破解出来直接烧片能运行他们认为够长的时间就行了吧。应该不会去反ASM的 ...
我只是说57楼的方法躲不过内存断点拦截,好像跟你说的不太搭边吧。 hhxb 发表于 2013-2-5 00:14 static/image/common/back.gif
这个也好意思叫加密程序,楼主你让我想起来那些卖小家电的宣传自己的产品由微电脑控制 ,单片 ...
单片机 的全称叫 单片微型计算机. gzhuli 发表于 2013-2-5 23:04 static/image/common/back.gif
我只是说57楼的方法躲不过内存断点拦截,好像跟你说的不太搭边吧。
内存断点拦截在破解PC软件上面很常见,典型如SoftICE,我还做过。
但是单片机仿真器有这个功能的我还真没见过。 Gorgon_Meducer 发表于 2013-2-5 14:22 static/image/common/back.gif
有人吃这行饭……做一单一年就可以啥都不干了,要你愿不愿意去耐心的追踪别人的汇编代码嘛?而且有以下事 ...
别逗了,又开始异想天开,现代编译器发展的很完善了,只要优化等级开高,你从汇编根本没法推算C源程序。实际上搞破解的人最大的难度在于找到校验那部分代码在哪里,而非怎么校验的。
注册机我也写过,最后一次大概是02年keil C51 6.20(后来过了6.22就不好使了),根本不知道人家注册算法是什么,直接把验证算法的那段代码放注册机里面就行了。反汇编当然有技巧,但是不管怎么说,反汇编都是一个极其痛苦的过程,一个优秀的黑客不一定需要太高的知识水平,但是他必须一定是一个具备超出常人无数倍的耐心的人。 i55x 发表于 2013-2-5 23:39 static/image/common/back.gif
内存断点拦截在破解PC软件上面很常见,典型如SoftICE,我还做过。
但是单片机仿真器有这个功能的我还真没 ...
常用的平台基本上都有。
这个是ARM Keil的:
这个是STM8 STVD的:
其他懒得截了。 i55x 发表于 2013-2-5 23:58 static/image/common/back.gif
别逗了,又开始异想天开,现代编译器发展的很完善了,只要优化等级开高,你从汇编根本没法推算C源程序。 ...
我没有说要获得C源程序啊,只要找到加密逻辑所在就可以了。如你所说,剩下就是耐心了。 xwkm 发表于 2013-2-5 15:30 static/image/common/back.gif
ATmel的芯片加密这么差,立等可取?我只记得貌似AT89S52的加密位是一下就挂而且FLASH还是从后往前擦的… ...
这是夸张,但主流型号都很快 Gorgon_Meducer 发表于 2013-2-5 12:07 static/image/common/back.gif
网页无法打开
要翻墙,我存成pdf附件了方便看
erpao 发表于 2013-2-6 02:09 static/image/common/back.gif
要翻墙,我存成pdf附件了方便看
谢谢你。 Gorgon_Meducer 发表于 2013-2-6 03:58 static/image/common/back.gif
谢谢你。
我是看不懂啦,对你这种高手来说有用. 小片子加密实在是难呀,没有啥最好的加密码的。只要你使用公共的指令集。除非你自己定义指令集,那破解起来就不是一般的难。 为啥大家都在盗版和防盗之间纠结呢,真是值得思考啊... 本帖最后由 NJ8888 于 2013-2-6 15:41 编辑
我也在用唯一ID,只是我用的不是单片机,是存储芯片,并且挂到FPGA上用20MHz时钟访问,这样除非用个CPLD或其他FPGA模仿这种存储芯片行为(我还要对这个给定地址芯片读写),单片机模仿时序来不及,FPGA代码是透明BIN能随便COPY的 简单,破解2个芯片,一比对就知道不同的一定是加密算法,改之即可;
只能对付君子,不能对付小人 NJ8888 发表于 2013-2-6 15:39 static/image/common/back.gif
我也在用唯一ID,只是我用的不是单片机,是存储芯片,并且挂到FPGA上用20MHz时钟访问,这样除非用个CPLD或其他F ...
几年前我在用XC3S50A就用到了Xilinx芯片内部的DNA来加密,没人能破解。
现在我又用Winbond的SPI Flash的Unique ID来加密,自己的加密算法,很难破解。 apachectl 发表于 2013-2-6 16:04 static/image/common/back.gif
简单,破解2个芯片,一比对就知道不同的一定是加密算法,改之即可;
只能对付君子,不能对付小人 ...
通常来说,懂各种破解的,有实际经验的才能做出好的加密产品。 NJ8888 发表于 2013-2-6 15:39 static/image/common/back.gif
我也在用唯一ID,只是我用的不是单片机,是存储芯片,并且挂到FPGA上用20MHz时钟访问,这样除非用个CPLD或其他F ...
STM32 IO速度看看行不 xwkm 发表于 2013-2-17 14:34 static/image/common/back.gif
STM32 IO速度看看行不
怎么可能行?任何单片机都不行{:lol:} 只有国家下力气保护知识产权才有意义。这些方法意义不大 我没有仔细看。但是软件都是分模块的。只要分析出函数入口,返回值。id都是屎。 内联id操作,那就nb了。 NJ8888 发表于 2013-2-17 14:49 static/image/common/back.gif
怎么可能行?任何单片机都不行
那你是用什么单片机来访问的? outt60777 发表于 2013-2-17 15:17 static/image/common/back.gif
我没有仔细看。但是软件都是分模块的。只要分析出函数入口,返回值。id都是屎。 ...
问题就是基本上你找不出。
花指令&代码数据混着。要分开谈何容易?
页:
[1]
2