duangsuse::Echo

https://t.me/vvb2060Channel/416 #Android #Security #aop asm inline hook 当然是任意点都可以，实际上 frida 配 xposed 开发是真好吧🤔 /proc/self 都可以 mount --bind ，但是改动是系统级的。通常做法就是由框架来实现访问权共享，像 Riru 一样换一个 preload .so 来实现 hook 我觉得应用层开发者尝试对抗系统动态分析是很愚蠢的行为，毕竟你又不是搞安全的，凭 Proguard 组搞出来…

为了避免被认为是在指点江山我就简单 PoC 一下，真的不需要十行代码。毕竟这个「反破解手段」门槛也太低了，只需改动 .h 文件&重编译，其它都自动兼容了。
而加密 bytecode 的各种方法全都逃不过内存 dump ，因为「原原本本」的程序文件是虚拟机要求的，总是要还原。 hook 一下虚拟机的 load() 即 luaZ_undump() 就都出来了，代码保护唯一有效的是削除命名标识符的本义，或者对程序做些预处理和切分什么的(对这些，基于符号执行的 smalivm 类反混工具也能消除)，但是大部分有「产权保护」意识的人意识不到吧😒。

目标只是得出两版 #Lua 指令号直接的对应关系，也就是只需做指令id 数组的读取，得出的对应关系用于 patch 给 chunkspy 等工具。

本来说是可以用 getOpcode(buf, i) 的，忘记数组迭代需要长度的问题了，就用迭代器吧…… 也是惰性计算的😒

首先自编个 lua luac （实质都是 liblua 的命令行工具

curl -O http://www.lua.org/ftp/lua-5.4.2.tar.gz
tar xf lua-* &&cd lua-*/src/
make luac lua

#sysadmin 科普下 lua.org 的 doc 里 curl/tar 的 -R/-z 是设置文件mtime/gz解压

看看 https://bbs.pediy.com/thread-250618.htm
https://t.me/berd_channel/1647
可以参考

Luac chunk 文件是比较标准带 insn size 的二进制结构， size_t 一般为 4 (int32) 大端字节序，因为只需要读取 opcode 我就做个比较 hack 的操作——hexdump diff 断言指令数组头的偏移量，本来想可以直接取每条指令首字节，没想到这个好像是仅 7 bit ，那就只能 import struct 了😓
然后指令集也不必写完整的，反正也没有 unluac ，源码手改的，自己验证意思意思够了。

lopnames.h 对虚拟机无意义， lopcodes.c 只是定义指令格式的，所以要改 .h 里的顺序，稍后 grep -r 'ORDER OP' 还会发现必须同时更改 .c 的顺序，而且还得修正 lua.h 的一处 #define 🌚 (不过和 lcode.h 的 OPR_x 以及 ltm.h 没关系，因为 opr 是以 OP_ADD+i 及 TM_ADD+i 的方式两向对应的 )
其实如果不改 ltm.h 而想保证元表事件正常派发，那 OP_ADD 到 OP_NOT 直接的顺序都不能变🌝
不过这里就随便点，反正没用到～

用于乱序的 py 脚本：
同时 shuf .c array 和 .h enum 的索引号，总之就是先搞出 index mapping 再 apply 它两次。 🌚

用于对应的脚本(见下下条)：
d[op[i]] = names[op_orig[i]]

胡话：呃，好像是 d[k] = d1[d[k]] ... 不对
其实变的是 k 吧(re-associateBy)， d[k1] = d[k] 其中 k1=d1.keyOf(k) ，因为 v 都是复制过来的。

#plt #ce #backend 反破解小指南 🦜
嘛，其实这个还是有强化的方法的。只需这个有强烈愿望🧐并且敢动 C 虚拟机🌝实现代码的人对他的每个单个应用 重编译乱 opcode 的私有版 lua
同时更改下 LuaVM 指令格式 bitmask 里操作数的顺序，并且以自有算法加密常量池(必须由虚拟机层来解密，最好是惰性完成的内部传输性 loadk 只传常量编号不解密)，这样对 naive 的破解者就非常棘手了，只能从外部 API 分析某一特性点的实现方法惹🌚

自有版虚拟机的代码文件看起来符合规范(因为你改得少)，但是完全无法被通常工具读取，一些虚拟机壳也是出于同样的意图(which 我没在 Android 上见到过，设计这种加壳器需要一定编译原理或状态机的知识需要预处理 bytecode)

最关键的一点就是孤立自己利用到的技术，让破解者无法使用针对性工具，然后增加破解者自写工具的难度，尽可能用没工具的 native 平台叠加难度。单机程序用惩罚机制来反动态分析？可笑。程序状态是不可信的，稍有常识的坏人完全可以保留某 fork 的整机状态，你检查虚拟机都不行，有的是机会给检测方法 hook 光光；用别人的反破库，也容易被找到针对性反反破工具。😒
其实嘛，越是简单的代码越接近真理，越往程序的根基走，手段越能令破解者头疼。

其实用私有版 luaVM 不暴露指令号对应关系就已经很安全了(当然坏人🌝还是可以用生成 code 看 vm state 的方法甄别指令，虚拟机状态就不是纯二进制领域的人能魔改的了🤪)，但最好还是用预处理给 luaV_execute 的 opcode switch 每个 case 加点随机乱代码，防止被源码相似性搜索（这个只需要反汇编字符串匹配破解者就能完成）。

介于 C 的静态自动分析尚无完整解法，对每个模块都要还原虚拟机指令才能反编译出真实逻辑，就可以说是「无法破解」的软件了🤣。
你掌控程序流程，你掌控无物；你掌控程序码解释，你掌控一切。
越是在根基做限制越难破解，但是外部 API 和 memdump 依然没办法对抗，但至少，这样反调试代码就不易被分析了🌚 这些代码能造成巨大的麻烦，让破解者不知从何下手，例如反外部 API 断点和管理加密的常量池，制造 garbage String 来混淆 memdump 。

什么叫做欺骗系统，「系统」这个概念都是针对软件运行时而言的，运行时可以是带trace/hook的实机、虚拟机或者静态分析器，这些都是合法合理的运行时，因为，程序只是数据而已。「我的代码，我的权利、我的私产」？谁能想到那么多啊😅。
除非有一天 DRM 会无法被模拟复制破解，不然最实际的方法是把软件做得足够大，然后诉诸法律或己方威权。

Pediy

[原创]用 Lua 简单还原 OpCode 顺序-Android安全-看雪论坛-安全社区|安全招聘|bbs.pediy.com

83 viewsduangsuse, edited 07:05