node js 调用dll 方案

最近准备用node js 写一个项目,所以需要对方案进行调研,项目会用到c的dll,通过网上查资料发现基本2种方案:1:ffi 2:addon

ffi 方案

这个方案我经过一天测试,发现这个方案不行,我建议直接放弃,第一个问题安装ffi 编译不通过,通过大量资料查询因为他不支持node 12 ,我通过使用别人ffi-napi 解决这个问题,然后遇到字符串问题,以前的接口默认是wchar_t * ,发现无论使用ref-wchar_t-napi 都无法使用宽直接,后面实在没有办法,我直接转换dll的接口改成utf-8进行传递,来解决字符串问题。最恐怖我发现ffi这个方案内存泄漏实在恐怖了,我防止是我自己API的问题,我直接调用系统的API,发现如果调用很频繁会导致内存泄漏,这点我完全无法接受,因为我的程序需要长期后台运行,那么内存问题是一个恐怖的问题

ffi测试代码

k = ffi.Library("Kernel32", {
  'OutputDebugStringA': ['void', ['string']],
});


var sleep = require('sleep');
for(var i = 0 ; i < 10000; i++){
  var r = k.OutputDebugStringA('' + i);
  r = null;
}

//等待100秒,观察内存是否释放,时间可以设置更长
sleep.sleep(100);

我自己观察内存一直私有内存一直增加,循环跑完也没有回收,那么说明ffi 有内存泄漏

addon

这个用起来挺简单,本质在windows就是一个DLL,通过工具生成一个动态库工程,然后直接按照例子写代码就可以了,也方便自己写代码,这里面有几种,我目前建议采用napi这种,这种就是没有v8版本,导致编译的问题,上面ffi编译的问题就是这个原因。

使用过程:

  • 百度一个addon教程
  • 找到nodejs 官方例子,直接按照例子写就可以 https://github.com/nodejs/node-addon-examples
  • 直接跑就可以(node32 才能加载win32 dll 不然会报错),上一个方案时候就出现加载问题,目前我用node32 12的版本

备注

nodejs 开发代码确实方便很多,但从一个技术方案迁移到另外一个技术方案,成本还真不少。ffi 内存泄漏,这个就不用考虑,ffi本质也是addon技术实现,这种中间件,但网上貌似都没有遇到这个问题一样,我直接测试好几个例子都会内存泄漏。ffi可以不用自己开发一个dll来做桥梁,addon需要自己单独写一个新的dll来调用原来的dll。

输入法软件可以考虑方向

背景

输入法是我们必备的软件,国内常见的输入法有搜狗,QQ,百度等等。这类软件拥有海量的用户,但目前这么年来看很难变现。他们连常见广告变现相对克制(相对其他的软件,手机软件广告随处可见),这个原因很简单,没有合适地方显示广告,因为输入法类似插件而已,在别的软件编辑框附近出现,如果这个出现广告是非常不合适,虽然输入法在这块做了一些联想功能开发,希望能够进行更多变现。但我总感觉在沙堆上造房子感觉,小心翼翼建造,但根本做不到自己想要高度(个人感觉),长期只是吸引用户的周边产品,为其他产品提供数据或者引流的梯子。

根本问题

我觉得根本问题就是输入法寄生在别的软件上面,没有自己长期展示的界面,没法要用户看到更多,就连输入法设置界面都很少打开。

方向

搜索,更加本地搜索,要用户养成用他搜索习惯。你可能会说输入法不是早就出了联想功能,这里说搜索不仅仅联想。

场景

1:用户A想知道今天某地的天气,那么他会打开浏览器输入某地的天气,然后找到页面搜索,用户需要打开3步看到自己想要内容。如果通过输入法,我们可以通过快捷键调出输入框输入某地天气,然后自动显示对应的内容。这样子用户无需打开浏览器,就可以得到自己内容,因为输入法基本常驻内存,所以打开速度非常快,这个就是很大的优势

2:用户B想打开本地某个程序,比喻QQ或者微信。由于桌面太多图标找不到,那么输入法如果提供搜索功能找到某个软件,那么是非常顺利的事情。目前微软有类似的功能,可以同win + s 进行搜索,输入法可以把这个功能做更强,更加方便。互联网更新速度是微软不能比较的。

3:用户C如果想搜索某个问题,那么他需要打开浏览器,输入对应的问题,然后页面打开对应的内容。那么输入法可以在快捷键调出他自己输入框,然后展示一栏搜索的结果,或者直接可以进入浏览器的搜索页面,这里非常有用的,用户用起来方便,这里可以切入到自己搜索引擎,而且增加用户打开输入法的频率,进入到输入法界面

落地

用户养成用输入法的搜索习惯

  • 最开始通过积分引导用户使用开始熟悉操作
  • 更多使用搜索功能对接,输入法搜索查询IP,JSON解析,xml解析,这种只要网络,内置浏览器直接加载导入搜索内容就可以了

参考产品

可以参考utools 的一些插件功能,目前我每天使用utools,并且是付费用户。

备注

上面只是大概说了一下,只是纸上谈兵,不过我还是觉得比较落地。其实每个产品都自己优势,每个产品需要发挥他自己的优势,然后扩展出自己的天地。目前输入法大方向都是AI大数据分析,虽然没有错,但为什么不可以更加接近用户,解决更多用户需求。

SendMessage WM_COPYDATA 拒绝错误

背景

SendMessage WM_COPYDATA 我们经常用来进程通信,今天突然改了一下代码加载方式,突然发现消息无法通信,我不断的通过打印日志来确定问题,最终觉得自己代码没有问题,但就是无法发送消息到另外一个进程。突然想到GetLastError() 看一下有什么错误,通过打印发现出现错误5,然后通过vs 带的错误查询,发现是拒绝错误。

解决方案

通过GetLastError, 我的脑海大概猜测是权限问题,于是搜索SendMessage WM_COPYDATA 拒绝错误,然后我找到这篇 https://blog.csdn.net/aa1991/article/details/19504557 ,固然验证是权限问题。如果是按照文章调用 ChangeWindowMessageFilter(WM_COPYDATA, 1); 就可以了

总结

排错需要更加系统化,尽可能了解不同知识点,更重要是思考方式,学会不断调节

PE加载器,DLL内存加载器

背景

我最近研究了DLL内存加载,网上找了好久代码,基本的原理差不多,自己稍微总结一下。

逻辑

  • 内存读取PE,按照PE格式进行加载(任何一本介绍PE的书籍都可以看有关知识)
  • 修复重定位表(这点非常重要,我开始不明白他怎么修复定位表)
  • 修复定位表
  • 其他细节(tls回调,修改PEB)
  • 调用入口启动

疑惑

1:怎么执行代码?

我们创建内存,然后复制PE到内存中,然后直接调用,但一些变量地址或者函数地址是以va(虚拟地址)直接访问,这些地址固定死的,但加载内存时候,基本不可能是原来的基地址,那么这些地址就是错误地址。那么这些地址要被修改,所以正常加载DLL或者EXE(正常启动EXE基本地址不会变化),如果模块的基地址变化都需要修改地址不然会崩溃。那重定位表记录原来硬编码的地址,我们遍历所有地址修复就修改掉。

2;兼容性

因为毕竟是我们人工模拟加载,那么可能缺失很多环境,导致异常。程序异常退出,这种只能通过OD动态调试分析,然后结合进程,线程有关知识来进行分析。最快就拿别人开源代码跑,因为这种都是经验,如果对这块没有研究,突然去研究感觉有点懵。

代码

1:一份简单代码

2:一份比较稳定,代码非常漂亮

https://github.com/polycone/pe-loader

可以加载MFC,代码优美,多了PEB修复,TLS回调等,只能启动标准的PE,不支持c#.可以正常启动酷我。酷狗启动不了,网易云音乐可以,QQ可以启动但看进程明显自动创建进程来实现。PC微信可以。整体看稳定系还是非常高,而且如果我们自己用,被启动程序我们也可以改,来适配稳定系。

加载DLL

加载DLL比EXE简单一些,不用修复PEB,我暂时没有测试DLL,但应该差不多。

作用

这个看每个人用途,这个技术和android插件技术类似,android多开就是插件技术,稳定性就要看模拟的程度了,这样子技术需要大量的用户测试反馈来排除一些坑。

备注

1:我本想顺着分析loadlibray,发现对于我非内核开发或者非专门逆向分析来说有点难,这种需要经验分析,有一些书籍有涉及,但比较少。

2:大量这几天查看和阅读大量知道PE加载器的核心知识点。

3:找相关代码 google : pe loader github 就可以找到很多代码。