NScript:有符号的64位和无符号的32位(?)
最近有一个比较扯淡的学业水平试题,学业水平考试一向是走形式,没想大厂微软也做了类似的事情。微软的公共符号不仅方便微软找问题,也方便了安全人员找问题,不过最近在看MSE的NScript时,发现了微软一个好玩的东西。
不知道微软是32位被报的多了还是怎么的,在它的公共符号服务器上还就是没有32位DLL的符号(无论是直接下载,还是使用虚拟机看x86自带的Windows Defender,最后结果都是——没有)。但是64位的符号却有,这就让人十分不解了。
(32bit)1.1.13804.0 From Windows Defender
E:\Program Files (x86)\Debugging Tools for Windows>symchk E:\Users\BlastTS\Desktop\wLoadMpEngine\Debug\mpengine.dll
SYMCHK: mpengine.dll FAILED - mpengine.pdb mismatched or not found
SYMCHK: FAILED files = 1
SYMCHK: PASSED + IGNORED files = 0
(64,win7)1.1.13701.0 From Windows Defender
E:\Program Files (x86)\Debugging Tools for Windows>symchk E:\msmpeng\x64-w7\mpengine.dll
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
如果你觉得是版本的问题,那也有例外,win10 64bit:1.1.13103.0 也就没有符号。所以,不知道微软葫芦里卖的什么药,难不成是正式版和非正式版的区别?不过这可都是你官网下发的啊。
这里主要最近看了taviso的linux加载MSE引擎并evaluate的例子,我想着在Windows下直接用系统的方式加载DLL并传入数据进行Fuzz。但是可怕的是没有符号,也就是说我需要手动定位我要hook的函数在哪里,而且修改它,让它跳转到我的函数中。
taviso的方式类似grinder的处理方式,即hook strtod来做logging。传入的字符是__log:开头的时候,就会认为是我们的log,否则调用正常的strtod逻辑。这个strtod被parseFloat调用:(后续的代码截图全是基于x64的)
不过为啥要放出上面的图呢,因为……即使32位无符号,像strtod这样不会有代码变动的函数(微软的编译选项中,strtod的代码是被直接静态写入DLL中的,不是对MSVC库的调用),只要和x64的代码一对比就可以找到位置。通过对比x64的JsDelegateObject_Global::parseFloat,就可以轻易地找到strtod,并在我们的代码中对其进行Hook。一下午的操作之后,我们就能直接调用NScript的接口,并且正确的得到输出了:
相关的代码之后我会整理放出。