好友
阅读权限10
听众
最后登录1970-1-1
|
jbc
发表于 2020-7-21 16:49
本帖最后由 jbc 于 2020-7-22 12:28 编辑
之前在看雪发的文章,现在在这儿里新申请了账号,以后就在这里发布内容了
----------------
这里只探讨思路,不提供任何破解工具和破解包
----------------
MyEclipse 从10以后破解只能手动替换覆盖jar包,工具只能负责计算license和存储license
那有没有直接用工具一键进行操作的办法么?有!
写起来会比较麻烦,一旦写好了,后续几乎可以完全自动化了,要详细理解这个思路,那还需要从头说起了
为什么现在网络上的工具不能自动化了?
因为MyEclipse每次发布版本都会验证位置,以前的版本存在固定的位置和固定的特征,而后面的版本每次发布,位置不固定了,但是验证逻辑是相同的,那么我们需要把这些位置找出来,根据验证逻辑的特征定位
验证完整性逻辑:
为了防止软件被破解,MyEclipse存在自校验逻辑,校验jar包是否被修改过,因为公钥和逻辑都在在jar包中,如果被修改,自校验逻辑结果失败,程序弹出提示,退出。
校验的逻辑比较简单,但很有效,逻辑有两点
1:通过eclipse基础类库验证核心的jar包,里面存在license认证和解密公钥的逻辑和数据,逻辑点是jar包的签名信息,签名是否完整,有否有被篡改,必须存在,而且要和操作系统里面的根证书存在链路关系
2:签名信息使用的key是必须是自己的key
通过这两点就能确定jar包是否被修改过
验证逻辑随机放置,一般会放到MyEclipse自己开发的其他插件中,插件启动就会校验
网络上针对版本10~2015这些版本的破解就是自己找到这些位置,反编译类文件,删除掉自校验代码,重新编译,覆盖文件就可以完成了,但是找到有哪些位置是比较消耗心力的。
那么有没有自动化扫描的呢?有!
扫描自校验;
1:粗暴的方法,把所有class加载到内存里面,通过反射找到方法名相似的,打印结果,之后再通过人眼确认,这个需要开辟大量的内存
2:解析字节码,通过解析常量池的数据定位具体的类,这个定位比较精准,但是需要高超的技艺,工具有bcel,asm,javassist
在自校验的逻辑中存在key的字符串,通过这个扫描所有的jar包,但是有些位置在多个层次的jar文件中,需要特殊处理,这样就可以找到相应的位置了。
修改校验逻辑有个特别的思路,就是转换校验jar包,上面提到了核心包core中存在publickey和license逻辑,这个包必改的,自校验就是检验这个jar包完整性,那么我们可不可以让自校验逻辑验证其他的未修改的jar包,而不是核心包。
修改校验类中获取核心包字符串id
反编译之后修改也是一个方案,这里不推荐
推荐使用字节码修改,直接修改常量池中的字符串就可以了,方法逻辑不用动,推荐javassist和bcel,而且上面提到的扫描就是通过扫描字符串池定位,不用扫描方法的指令集
通过上面的方法就可以快速定位位置,之后进行修改id,就可以导出新的jar包。
程序工具化有许多需要注意的问题,譬如多层次嵌套的jar文件怎么替换最里面的某一个或者多个文件,需要用到嵌套流的方式,之后和替换的逻辑能不能和这个整合到一起,这个具有一定的设计复杂度,当然这个是个工具链开发的问题
那有没有更简洁一些的办法呢?有!
这个需要更高的技能了,就是使用javaagent,不用替换jar包内容,通过启动之后在内存中替换验证class文件达到目的,但是这个也需要你提前知道具体的类,写到agent逻辑里面进行class替换
有没有更容易的办法呢?有!
俗话说大道至简,适用这里非常合适,需要替换的类是jdk的类,通过这个类的信息,植入你的逻辑,就可以强制让某些验证通过,达到最终的目的。
具体是哪个类我就不在这儿说了,你们自己研究吧。
再高阶一些点就是把license计算写入和这个agent整合到一起就可以一步操作到位
更高阶的是写个eclipse插件plugin,让一切自动化
说起javaagent,我觉得可以大概聊聊jetbrains,最开始通过替换jar包的类文件,但是有个很大的问题就是破解之后不能升级,因为idea升级策略是差量更新,就是patch包,升级后的文件是根据本地文件和patch文件一起通过更新算法计算出最终的文件内容,这样的好处是更新包非常小,节省带宽,而且易于发布。
直到后面有人开始使用javaagent的方式破解,才解决这个困局。
我看网上没有最新的破解了,是不是没什么人用MyEclipse了啊 |
免费评分
-
查看全部评分
|
发帖前要善用【论坛搜索】功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。 |
|
|
|
|