1.Lua 脚本静态分析的游戏源码游戏源码思路与实现
2.十一重新起步
3.hybridclr源代码解析
4.Text Mesh Pro图文混排如何对任何都能实现
5.逆向入门cocos2d游戏逆向分析
Lua 脚本静态分析的思路与实现
作者:levizhao,腾讯 IEG 客户端开发工程师
在游戏开发过程中,最新lua 脚本的游戏源码游戏源码广泛应用带来了一定挑战。由于其语法检查主要在运行时进行,最新且作为胶水语言,游戏源码游戏源码全局变量的最新sobel滤波源码注入和修改可能导致编辑器难以提前发现错误,影响开发效率。游戏源码游戏源码本文探讨了如何通过静态分析来改善这一状况。最新
xlua,游戏源码游戏源码作为热门的最新lua解决方案,它支持Unity等C#环境的游戏源码游戏源码扩展,通过代码生成和反射实现与C#的最新交互,对代码的游戏源码游戏源码侵入性相对较小。在Unity项目中,最新运营内容的游戏源码游戏源码热更新通常依赖xlua进行开发,但其局限性在遇到lua脚本错误时显得明显。
目标是通过静态分析在编译阶段检查lua代码的符号语义,避免运行时的错误。这种思路类似于动态链接,但在脚本执行前进行模拟,关注符号的有效性,遇到无法解析的符号,视为“链接失败”。这一方法并非局限于Unity,而是适用于其他lua绑定的静态分析。
实现这一目标需要对lua源码进行预编译,包括词法分析、语法解析、解释器和编译器等。lua标准库函数需要导出,同时处理外部注入的符号,通过懒加载机制减少开销。lua虚拟机的指令解析是关键环节,涉及多种指令操作。
尽管静态分析解决了部分问题,但混合编程的局限性仍存在。混合编程初衷是2017锁机源码利用不同语言的优势,但目前实践中存在效率和简洁性的妥协。为了更优雅地解决这些问题,我们需要深入考虑游戏引擎、编译器和代码编辑器等基础设施的改进,以打破单纯的插件式设计。
十一重新起步
哈,没想到吧,本专栏还有再次更新的一天。
其实是看到这个之后,决定把热更新也整合进去。既然要整合热更新,那现在的框架不得不重新写一次,因为代码最终要编译成Dll的。
这次重写的话,我做出了如下选择:
脚本语言:xLua
Unity版本:Unity .3.5 (VS)
文件夹设置:游戏工程的建立
没啥好说的,中规中矩建一个3D工程。随意新建一个脚本,用VS打开,在“解决方案管理器”视图找到Unity相关的引用,其属性为:
把路径里用到的东西打包复制到Dll工程的3rd目录下,供Dll工程引用。然后再找到pdb2mdb.exe和mono.exe:
如果电脑里有多个Unity版本,则可能会有多个该程序,选择对应版本的即可,等下要用的是路径,pdb2mdb.exe是DLL的调试符号转换器,不生成mdb就没法调试DLL中的代码。
类库工程建立
依旧是中规中矩创建一个类库的工程。先添加刚才准备好的Unity相关程序集引用,然后打开项目属性,设置生成后事件:
此处就使用了mono和pdb2mdb的路径,生成之后复制到游戏工程中。这里随便写了一个测试类,在游戏工程中可见,Dll中已经有这个类了。
打上断点,谷歌上查看源码挂上调试。然后运行游戏工程,好的,成功断住:
接入xLua
将Plugin放进游戏工程中,将Src下的源码分别放进Editor目录和DLL工程中,测试一下:
没毛病,成功启动Lua虚拟机。接下来就是要配置xLua,选择一些可能要在Lua端使用的C#内容,按照xLua文档所示,直接整个静态类静态List,把要用的东西码入。
这里我根据个人的判断添加了如下内容:
然后调整一下配置生成器的路径:
然后执行一下生成命令,更新Dll工程,然后编译一下。是时候测试了。
也确实打印出来了“hello”字样。
API定义生成
写这种脚本语言,没有个编辑和调试插件其实是挺蛋疼的。这里推荐luaide,直接在vscode插件里找就可以,收费也比较便宜。
不过暂时还没有用它的打算,而是先接入它的api定义生成,这样编写Lua的时候可以相对直观的看到C#中一些api和数据的写法。
放进工程目录之后,修改导出路径,然后注释掉LuaIdeApi.cs里的菜单标签和自动生成;在xlua的生成函数末尾添加LuaIdeApi的生成即可。
这样,每次生成xlua内容的时候就会自动把api定义也更新,可以说是非常完美。
VS Code准备
用VS Code打开了Lua文件夹之后,会发现Unity生成的.meta文件也被计入了其中,因此我们要设定过滤,保证VS Code开发环境的清爽:
另外我比较习惯折叠代码,这点VSCode的发展历程竖着源码Lua样式还没有,手动打开配置一下:
加载Lua
在编辑器下的开发应当越快越好,越高效越好,所以加载的时候,就有必要设计一种编辑器下的加载模式,跟使用AssetBundle或者其他自定义数据存储形式的生产环境不同,该模式应当做到修改Prefab\Lua等资产之后,无需打包即可立刻启动。
因为是为了测试xLua的加载,所以一切从简:
其中LoadContext是一个发起加载的上下文,该结构我暂时还没想好填充什么,不过也无关紧要,对于现在的测试来说,只要保证LoadLua方法可用就行。
这里使用System.IO.File而不是用AssetDatabase的原因是,“*.lua”在Unity中会被认为是DefaultAsset,无法被当做TextAsset处理。
在测试用的MonoBehavior类中用require('Game/Game'),打印成功。
Lua的class实现
才疏学浅,自己写的果然又长又臭,这里使用了quick-cocos2d-x的实现,但是因为我并没用到什么native C++的东西,所以大笔一挥,只保留了基本的Lua Object的内容:
好,我们来稍加测试一下:
表格的使用
将Excel表格生成成如下形式,代码可参照之前的内容:
使用一个_Data.lua来封装所有对数据表的查询操作:
测试,然后通过:
hybridclr源代码解析
基于lua的unity热更新解决方案
使用lua5.3.5,可以通过VS进行调试,lparser.c负责解释lua源代码,LClosure *luaY_parser函数是解释lua源码的入口。llex.c中的llex函数负责词法分析,而lparser.c中的statement函数进行语法分析。lvm.c则用于执行lua代码。观察到lua需要第三方插件以查看性能,其基于寄存器的虚拟机性能优于ilruntime,但与unity交互成本高,c 外贸 erp 源码依赖于lua的堆栈交互。
流行解决方案如XLua和ToLua,XLua在处理如Vector3等结构体时,避免了不必要的拆箱和装箱操作,ToLua则直接在lua代码中实现了与C#类似的Vector3数据结构。
基于ilruntime的unity热更新解决方案
ilruntime的下载地址为github.com/Ourpalm/ILRuntimeU3D。它提供了unity示例工程,其中ImageReader.cs负责加载dll,而ilruntime使用Mono.Cecil来读取dll的PE信息。从2.0版本开始,ilruntime引入了寄存器模式以解决数值计算效率问题,分为按需JIT(ILRuntimeJITFlags.JITOnDemand)和立即JIT(ILRuntimeJITFlags.JITImmediately)两种模式。ILIntepreter.cs用于执行il代码,非寄存器模式下,Execute函数负责执行代码,而寄存器模式下的ExecuteR函数实现相同功能。然而,所有解决方案的虚拟机与il2cpp相互独立,导致元数据不相通,影响了与unity类的集成,需要额外封装和跨域访问处理。ilruntime支持大部分C#语法,但使用时需注意避免一些陷阱。
基于hybridclr的unity热更新解决方案
hybridclr提供了unity示例工程,官方博客地址为hybridclr.doc.code-philosophy.com...,使用手册可参考介绍 | HybridCLR。建议在vs和unity.3.0f1环境下调试PC工程。加载dll的两个主要入口在于.metadataModule.cpp中的LoadMetadataForAOTAssembly函数和RawImage.cpp读取原始信息,随后Image.cpp解析dll信息并翻译成il2cpp类型,AOTHomologousImage.cpp和ConsistentAOTHomologousImage.cpp分别用于封装加载过程,确保一致性或超集程序集的灵活管理。Assembly.cpp的Il2CppAssembly* Create函数解析PE头、CLR头和元数据以得到镜像信息,随后初始化metadata和interpreter模块以提供快速访问和执行速度。
hybridclr的优势在于直接使用il2cpp的内存对象,避免跨域问题;利用C#语言特性进行开发;并能够使用unity自带的profiler工具查看性能。
Text Mesh Pro图文混排如何对任何都能实现
1)Text Mesh Pro图文混排如何对任何都能实现
2)PlayerSettings.WebGL.emscriptenArgs设置无效的问题
3)Prefab对DLL中脚本的引用丢失
4)如何在第三人称蓝图模板中获得当前相机SpringArm的Target Arm Length
这是第篇UWA技术知识分享的推送,精选了UWA社区的热门话题,涵盖了UWA问答、社区帖子等技术知识点,助力大家更全面地掌握和学习。
Q:目前Text Mesh Pro图文混排需要把打入图集并放入TMP的Resources文件夹中。项目中想在任务UI面板展示很多装备或物品的icon,这些icon都是打好了的图集,很多别的系统也要用,不可能都放入TMP的这个资源文件夹里,但这样就无法进行图文混排,请问有什么解决办法吗?
A1:把TMP里面所有的Resources.Load接口,都替换成项目自身的Bundle加载接口,应该就可以解决了。
A2:可以注册以下回调:TextMeshProUGUI.OnFontAssetRequest,这样就可以自定义一个加载方法。 如果加载成功了,TMP就不会Resources.Load。
Q:游戏里用了C++的第三方库集成到xLua里面,端版是用CMake构建,可以配置宏、Include路径等,很方便。
我现在用Unity .3发布的WebGL版本,xLua是把所有Lua代码放在了“工程目录/WebGLPlugins”下面,在引擎里去#include这里的C代码,也没问题。
但是自己的C/C++代码比较多,也不能全部扔在同一个目录下,如果加了目录,就有跨目录Include的问题(主要是lua.h,lauxlib.h)。我从PlayerSettings.WebGL.emscriptenArgs = "-Imy_file_folder_path";这样设置搜索路径,但是没用;然后定义宏-Dxx也没用,不知道为什么。(参数中没有自己定义的路径和宏,都是Unity自己的,虽然ProjectSettings.asset已经生效了。)请问有解决方案吗?
A:在Unity .2之后更新Emscripten,emscriptenArgs属性失效了,可以把Lua代码和C/C++代码都放到一个层级,然后改引用。 还有一个方式:找到你Unity安装目录\PlaybackEngines\WebGLSupport\BuildTools\Emscripten\emscripten\emcc2.py,如果没有emcc2.py就找emcc.py,在里面找到get_clang_command方法,这个方法就是拼接执行编译C/C++代码语句的,在[src_file]后面增加+ ['-IAssets/XXX/XXX'],注意-I和Assets之间没空格,大概这样子:
注意py文件缩进问题,多个文件夹就添加多个“-I”,我猜因为它自己有“-I.”参数,所以可以使用相对目录(对clang++编译不太熟,我在Windows的Unity .3.f1上使用可行。) compile_args变量是记录传进来的参数的,有精力也可以找找调用emcc2.py的地方传进来更合适,我这边没找到。 其它需要改C/C++编译参数的地方我也在这里改了,如果有其它更简便有效的方法,欢迎分享。
Q:开发时,不希望策划看到源码,于是将源码替换成DLL,但是这样挂在Prefab上的脚本引用会丢失,请问怎么解决?
A1:是原有的预制挂了CS,后面想打成DLL重新挂?如果是这样,遍历预制,去批量修改GUID和FileID。可参考文章 《Unity将C#脚本转换为DLL,Prefab等文件不丢失引用的方法(转)》,文章里面用了DLLSwitcher插件,也可以自己理解Prefab GUID fileID和DLL,CS文件对应的关系就行了。
A2:代码要分成底层和逻辑层。底层用DLL+Obfuscator,逻辑层就不能了,因为如果也加密,开发验收查bug都会费劲。 如果要防止策划带走代码,按照我说的底层DLL就行,即使他带出去,只有逻辑层的开发,后面也会一大堆问题,除非自己写底层,就要调试,时间还不如自己重新写,这样的博弈论一旦开始,这个代码库重要性就不高了。 同时也要防止策划带走服务端代码,做到服务端拿不到客户端,客户端拿不到服务端,这样即使有一方代码,也是无用代码。
Q:使用SpringArm组件会让相机在发生碰撞时拉近,但是为什么获得到的Target Arm Length值却一直不变?
A:在代码中,Target Arm Length永远是不变的,但是它下面有RelativeSocket,在蓝图中可以使用GetSocketTransform来获取,并且使用RTS_Component参数,取Location然后用VectorLength来计算:
还可以用SpringArm与Camera的位置相减来计算,分别GetWorldLocation再Sub和VectorLength:
可以发现两种方式得到的数据似乎有些小区别,这是因为该案例中还有一个相机跟随鼠标位置移动的功能,它会对Camera进行SetRelativeLocation,偏移其Y和Z值。方式一是从SpringArm中取,与Camera无关,所以不受偏移量影响;方式二用到了Camera的RelativeLocation,因此将偏移量也算了进去。 另外还有一种方式,无法计算距离,而是直接检测相机是否与世界发生了碰撞,发生碰撞时就会进行缩放。
逆向入门cocos2d游戏逆向分析
深入剖析cocos2d-x游戏逆向分析
cocos2d-x是一个开源的移动2D游戏框架,它底层支持各种平台,核心用c++封装了各种库,外部则提供了lua和c++接口。关键代码可能隐藏在lua脚本中,许多安卓游戏的逻辑也主要在lua脚本里运行。通过官网示意图了解从c++进入lua世界的路径。
探索cocos2d-x的lua虚拟机相关代码,包括CCLuaEngine.h和CCLuaStack.h。在应用结束加载中进入lua虚拟机,具体由applicationDidFinishLaunching函数调用engine->executeScriptFile("main.lua")实现。
在luaLoadBuffer函数中,使用xxtea_decrypt解密了lua脚本,并通过luaL_loadbuffer加载解密后的脚本内容。因此,通过hook这个函数,可以将(char*)content字符dump出来,获取解密后的lua脚本。
然而,luaL_loadbuffer的源码无法直接获取,它位于编译过的库cocos2d-x\external\lua\luajit\prebuilt\android\armeabi-v7a\libluajit.a中。要找到实现细节,需要下载luajit源代码进行深入分析。
总结关键点:
1. 从c++进入lua世界的调用逻辑。
2. 使用xxtea加密算法,sign和key为XXTEA和2dxlua。
3. 无论是否加密,都会调用luaL_loadbuffer函数,通过hook这个函数获取解密后的lua脚本,但需运行游戏一次。
4. cocos2d-x\external\xxtea\xxtea.cpp中有加密解密算法,逻辑清晰,可使用python脚本本地解密或hook获取key、sign或解密后脚本。
实战案例:
以某捕鱼游戏为例,下载apk后内部集成十余款小游戏。通过分析游戏源码,找到luac加密文件,解密key和sign。使用ida打开libqpry_lua.so,定位到AppDelegate::applicationDidFinishLaunching函数,找到加密调用。对比源码,解密后可直接运行游戏。
深入lua脚本分析,如子弹击中鱼的逻辑,直接查找src\views\layer\BulletLayer.luac文件。通过修改相关函数参数,实现特定功能。其他功能逻辑获取源码后易于理解,修改代码后重新加密,实现游戏破解。
思考如何实现cocos2d-x反逆向,从浅至深可采用以下方法:
1. 修改xxtea的key和sign,需分析so文件。
2. 直接修改xxtea算法,增加逆向难度。
3. 更改luajit源码,调整字节码指令顺序或数据读取顺序。
4. 将关键代码封装到其他cpp或so文件,增加解密步骤。
5. 使用ollvm混淆代码,需分析混淆或vm。