search

HikariObfuscator / Core

Shared Obfuscation Core
123 stars 46 forks source link

Skip functions who don't use ConstantString. #1

Closed LeadroyaL closed 5 years ago

LeadroyaL commented 5 years ago

No comment.

Naville commented 5 years ago

感谢。 我假定你已经阅读了贡献指南，里面声明了你的变更我拥有所有权利，如果不是这样请务必告知以便我回滚更改。

另外我个人比较偏好用花括号显式声明作用域

Naville commented 5 years ago

看了下你的博客上的指点江山，不太确定你的博客的评论系统是否完整有效。 下文是完整回复:

至于你的这篇指点江山的文章。
二： 这是故意的，为了确保每个地点的字符串加密都不一样，否则同一个字符串在一处被解密会导致其余所有引用都被破解
三： 这也是刻意做的设计。 因为这玩意的主要用户只搞iOS而且也不会自己算flag，私有版本是根据平台硬编码的flag
五: 如果你看了文档会发现文档里早就写了。https://github.com/HikariObfuscator/Hikari/wiki/StringEncryption 不这么做的唯一原因是跨平台下很麻烦。
六: 解决方案是根据visibility来切换注入点，这类方法就放回入口点一次性解密
七： 这是唯一一个真正有点用的bug，但实际情况下很少有人这么干而且也没有负面影响所以我也懒得管
Naville commented 5 years ago

写了长版的一篇解释，还请查收 : ) https://github.com/HikariObfuscator/Hikari/wiki/Known-%22Bugs%22

Naville commented 5 years ago

我的实现绝对不完美，我也很乐意看到真正的bug指正。但在不看文档的情况下将文档里特意写明的特性当作bug提交还要自我满足的意淫一番“怎么会写出这么蠢的bug”就不是我能理解的思路了，只能说我暂且蒙在内蒙古大草原里

Naville commented 5 years ago

关于你的pthread解决方案，我加了一堆解释，希望对你有帮助 : )

LeadroyaL commented 5 years ago

看了下你的博客上的指点江山，不太确定你的博客的评论系统是否完整有效。 下文是完整回复:

至于你的这篇指点江山的文章。
二： 这是故意的，为了确保每个地点的字符串加密都不一样，否则同一个字符串在一处被解密会导致其余所有引用都被破解
三： 这也是刻意做的设计。 因为这玩意的主要用户只搞iOS而且也不会自己算flag，私有版本是根据平台硬编码的flag
五: 如果你看了文档会发现文档里早就写了。https://github.com/HikariObfuscator/Hikari/wiki/StringEncryption 不这么做的唯一原因是跨平台下很麻烦。
六: 解决方案是根据visibility来切换注入点，这类方法就放回入口点一次性解密
七： 这是唯一一个真正有点用的bug，但实际情况下很少有人这么干而且也没有负面影响所以我也懒得管

你先平静一下，我没有攻击你的意思。

先道个歉，我没有仔细看文档，现在也没有仔细看文档，所以我认为是 BUG 的地方，可能是你列出来的、可能是你没有列出来的，这里存在误会。

二、你的考虑没有问题。但我的考虑是，我做测试样例时，各个case 都会测的，你对于rwdata的char*，你也做了多份处理，这个我依然认为是 bug，毕竟rwdata本身是不该被复制的，会导致使用者程序出 bug。

三、ok，没问题，是每个平台自己定义的变量。

五、抱歉，阅读文档没有完整阅读。我不该写 destroy，承认是我的错。在删掉 destroy 后，我的方案是没有问题的。

六、感谢提出方案，目前也没有想到跨 Module 的字符串处理方式，你讲的我不明白如何实现，保留意见，毕竟这样写代码的人不多。

七、你说的不对，在你的测试样例里，可能影响只有几 k 的水平，但在普通的、使用了大量 cpp 的特性的项目里，影响是几百 k 的，因为 cpp 有大量的碎片的函数受到影响。我也是因为这个原因，才提交了此次 commit。

LeadroyaL commented 5 years ago

写了长版的一篇解释，还请查收 : ) https://github.com/HikariObfuscator/Hikari/wiki/Known-%22Bugs%22

我的实现绝对不完美，我也很乐意看到真正的bug指正。但在不看文档的情况下将文档里特意写明的特性当作bug提交还要自我满足的意淫一番“怎么会写出这么蠢的bug”就不是我能理解的思路了，只能说我暂且蒙在内蒙古大草原里

你的文档是 Zhang edited this page on 12 Dec 2018 · 1 revision 写的， 我的 blog 是 2018年11月21日 写的，而我读源码时候，是 2018 年 10 月的事情。

当时是没有文档让我读的，而不是我故意找茬，希望你明白一下。

另外，我后面补充的几个问题，是在 2019 年 3 月，因为我没怎么看到hikari 的更新，我自然不会去翻它的文档，我认为我已经比较了解了，所以也没有去翻文档。

My implementation is far from perfect and I'm more than happy to discuss such issues, but calling someone else's DOCUMENTED FEATURE a "very stupid bug" multiple times while can't even provide any reasonable improvement himself is just beyond me

在没有文档支持、没有注释的情况下，对rwdata运行会让程序逻辑出问题，因此我当时对这个 feature 评价是 very stupid bug。对于每一个我列出来的问题，我都思考过，而且尝试并成功修复（在我的测试样例里是可以通过的的），我没有给出改进是因为我手头还有别的事情，我也提到过，我有空会去提个 issue 的。

综上，我认为这是一个误会。

我去编辑一下我的 blog、你去编辑一下你的wiki，大家都是 llvm Pass 的开发者，和平共处 ok？

LeadroyaL commented 5 years ago

关于你的pthread解决方案，我加了一堆解释，希望对你有帮助 : )

你说的对，确实容易被人dump出来，但我想不到在 IR 层有别的方式，只能用加锁的方式来实现；而且我注意过，你代码里是思考过这个问题的，因为那个Store/Load是 Atomic，平时不大用这个 flag。

其次，那段代码确实是我从网上复制粘贴的，测试时候也是用那段的，destroy 抄多了，我承认。

这并不是一个完美的解决方案，真要使用的话要经过功能测试的，你指出的缺点确实存在，但实际用起来还真挺好用的。早知道我不写这个解决方案了，也不需要被你冷嘲热讽，没必要，真没必要。

Naville commented 5 years ago

你那文章读起来就是在冷嘲热讽我，我觉得合理的反击无可厚非。你要说那不是本意的话也行，我误会了，我道歉。你那篇文章怎么编辑你看着办吧

Naville commented 5 years ago

为了表示诚意我删除了wiki里的冷嘲热讽，您随意

Naville commented 5 years ago

另外，你说的锁是完全可以在不调用pthread的情况下实现的。不这么做的理由也很简单，每个平台需要单独适配，而且语义比较复杂

LeadroyaL commented 5 years ago

已更新，如果仍有问题的话，可以再联系我。