xmake

byOpen是一个绕过移动端系统限制的增强版dlfunctions库。 支持特性 Android 支持App中加载和使用Android系统库接口（即使maps中还没有被加载也支持）。 Android 7以上dlopen, System.load都是被限制调用的，虽然目前网上有 Nougat_dlfunctions 等库通过从maps中找so库来绕过加载限制。 不过对于app中还没被加载到maps的so库，这种方式就不行了。 而byOpen不仅支持fake dlopen方式从maps加载，还可以将还没加载到maps的so库绕过系统限制强行加载进来使用，实现更加通用化得dlopen。 注：目前的实现方式理论上还是比较通用的，至少我这Android 10上测试ok，但还没完整详细测试过，是否使用请自行评估。 相关原理 具体实现原理还是比较简单的，主要还是借鉴了 一种绕过Android P对非SDK接口限制的简单方法 的思想和实现方式。 虽然这篇文章中主要目的是为了绕过hide api，不过它里面使用的将自己假装成系统调用的方式，一样可以用到 System.loadLibrary 上去，让系统以为是系统自身在调用 System.loadLibrary 从而绕过Android N的classloader-namespace限制，将系统/system/lib中任意so库加载到maps中

luject A static injector of dynamic library for application 简介 luject是一个可以将动态库静态注入到指定应用程序包的工具，目前支持以下应用程序的注入： Android APK iPhoneOS IPA Windows可执行程序 MacOS可执行程序 Linux可执行程序 如果你想要了解更多，请参考： 在线文档 项目主页 Github Gitee 准备工作 我们需要先安装 xmake 来编译此项目。 编译 $ xmake 安装 $ xmake install 使用 $ luject -i app.apk lib1.so lib2.so $ luject -i app.ipa lib1.dylib lib2.dylib $ luject -i liba.so lib1.so lib2.so $ luject -i app.exe lib1.dll lib2.dll $ luject -i a.dll lib1.dll lib2.dll $ luject -i liba.dylib lib1.dylib lib2.dyib $ luject -i bin lib1.so lib2.so 示例 注入libfrida-gadget.so到APK 使用frida系列工具对app进行动态分析，相关详情见： frida $

xmake 在构建程序的时候，会去自动检测系统环境，工程描述等来创建最合适的编译配置来进行编译。。 一般情况下，我们只需要执行： $ xmake 就行了，并且如果工程描述没有改变，就不会去重新检测和生成配置。。 但是有时候，我们的编译需求千奇百怪，不可能一行 xmake 就能完全满足我们的需求，例如：我要在macosx上编译android程序了，怎么办 这个时候就需要手动修改配置： $ xmake f -p android --ndk=~/file/android-ndk 上面是简写，这样会少敲些字符，如果要可读性更好些，可以写全： $ xmake config --plat=android --ndk=~/file/android-ndk 然后我们继续执行编译即可： $ xmake 如果每次编译都是相同配置的话，就不需要重新配置了 当然有时候系统环境发生改变，例如之前用的是 gcc， 现在gcc被卸载了，装了clang，那么缓存配置就无效了，这种情况下，xmake还没有那么智能，能够检测到进行重配，只能手动加上 -c 参数，强制清楚配置缓存，进行重新检测： $ xmake f -c 如果有时候遇到些配置上的问题，都可以尝试加上这个参数，重试下，一般都能解决。。 上述讲的都是相对于工程的局部配置，只对当前工程有效，配置的缓存数据都被放置在了当前工程目录下： projectdir/

3 月，跳不动了？>>> 随着xmake v2.0.1 版本的发布，这大半年的辛苦总算告一段落，这个版本我基本上重构整个项目的90%的代码，几乎算是重写了，但结果还算挺满意的。。 因为上个版本的架构设计的不是很好，不能很好进行扩展，也不支持插件模式，语法设计上也不严谨，容易出现各种隐患，这对于后期维护和发展来说，已经出现了不可逾越的瓶颈。。 每个项目到了一定阶段，都是要不断重构，重新构思整体架构，才能使得项目不断的向好的方向演进。。 （当然如果是公司项目就另当别论了，坑太多，历史负担较重，不是说要重构就能让你重构的。=。=） 回归正题，目前xmake基本上所有模块都是可扩展的： 插件扩展 工程模板扩展 平台架构扩展 action扩展 option选项扩展 自定义task任务机制 宏脚本扩展 模块化和可扩展性，使得xmake整体是高度解耦的，整个core的内核算法实现非常轻量，其他模块如果我们想要扩展它，只需要把自己实现的脚本放到对应目录，就可以实现自注册，自加载。。 并且每个插件模块内部都有严格的作用域控制、沙盒化处理，非常安全，不会干扰到其他插件。。 下一个大版本，我打算开始研究下，怎么去实现完善的依赖包管理，目前的一些想法和构思： 自动检测依赖包，如果存在直接链接编译，如果不存在，从远程仓库中自动下载对应版本，进行本地编译安装，然后自动集成和链接 支持多架构