35岁回家养猪

问题已解决，感恩开源

好的，感谢回答，我测试一下

 验证了一下是可以的

上面截图是在arm层远程绘制的效果。模拟器可以注入x86的so作为跳板然后再通过native bridge加载arm so。我还是想用native绘制，但是注入的so是不走jni_onload的，无法获得java的虚拟机环境，从而也就无法获得java层的NativeWindow，如果拿到java层的NativeWindow而不是自己通过libgui创建出来的surface，我的预想是可以通过native进行绘制出的，目前这个问题让我很困扰

哈哈，想了2天怎么去突破suface权限问题，还是没什么头绪。还是不折腾了，老老实实hook eglswapbuffers吧。unity和ue在arm层都会调用到/nb/libEGL.so所以模拟器hook绘制不用愁，cocos2dx的处理就比较麻烦点，它是jni到x86层调用eglswapbuffers不走arm层，但是可以通过其导出的swapbuff进行hook，主流的引擎目前hook都有解决方案，不折腾native surface了QAQ

可以劫持一下debughelp.dll，然后hook 一下createservice更换一下自己签名的驱动镜像(盲猜楼主是因为现在打的签名过不了EAC的回调) SC_HANDLE WINAPI MyCreateServiceW( _In_ SC_HANDLE hSCManager, _In_ LPCWSTR lpServiceName, _In_opt_ LPCWSTR lpDisplayName, _In_ DWORD dwDesiredAccess, _In_ DWORD dwServiceType, _In_ DWORD dwStartType, _In_ DWORD dwErrorControl, _In_opt_ LPCWSTR lpBinaryPathName, _In_opt_...

maybe the app protect the export symbols，you can just parse libil2cpp.so to check this.no il2cpp symbols dump no work