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的接口，并且正确的得到输出了：

相关的代码之后我会整理放出。