x64逆向——MT、MT在release和debug下的四种模式寻找main入口
vs代码生成四种模式：
MT选项：链接LIB版的C和C++运行库。在链接时就会在将C和C++运行时库（LIBCMT.LIB、LIBC.LIB）集成到程序中，程序体积会变大。
MTd选项：LIB的调试版。
MD选项：使用DLL版的C和C++运行库，这样在程序运行时会动态的加载对应的DLL，程序体积会减小，缺点是在系统没有对应DLL时程序无法运行（需添加MSVCPxx.DLL、MSVCRxx.DLL）。
MDd选项：表示使用DLL的调试版。
带T的链接静态库lib；带D链接动态库dll；带d为调试版本，库名加d
例如我的机器上搜索，vs2022里有libcmt，但是libc.lib只有vc6才有：
因此，寻找main的入口函数，需要针对四种模式进行区分：
x64里main三个参数，call之后就是exit，因此寻找的方式：直接寻找exit最近的一个包含ecx、rdx、r8的三个参数的call调用就是main了：
举例：
#include <stdio.h>
int main(int argc, char* argv[], char* env[])
{
return 0;
}
1、debug模式： 多线程调试 DLL (/MDd) 寻找main：
我使用vs2022生成的exe，在ida 7.5里使用上述思路寻找main：
第一个exit上面，有2个call都可能是main，为了看里面是否有三个参数，点击进去：
第一个sub_140011C20,双击进去：
可以确定它就是main调用了。
当然，另外一个不是，如下图所示：
2、Release模式： 多线程 DLL (/MD)寻找main：
思路基本上和上面1是一样的，但是更加简洁，可以直接在exit上面看到call main：
如果是动态调试呢？如何快速找到main：
在xdb里打开，使用符号搜索exit，然后在该处设置断点，然后运行程序到断点处，查看调用栈，这样就可以快速识别到main了。
符号搜索exit，注意是在urcrtbase.dll里搜索：
跳转到该处，设置断点：
运行到该处：
查看调用堆栈：
然后双击test.$...那个，可以看到返回地址对应下面图中的nop，上面调的call是test.exit，也就是他里面调用的ucrtbase的cexit了！
向上找，是不是就可以找到包含三个参数的test main调用了！！！
如果是上面1的debug模式，要在xdb里寻找main，思路和上面类似，但是有区别：
在test.exe搜索exit，调用的是ucrtbase.exit 设置断点，然后看调用stack，追到如下位置：
然后看上面的几个call，哪个是main？一一点击进去就可以看到是最上面的第二个call了！如下看到了3个参数的main调用：
总结下来：
多线程dll模式寻找main通过用符号搜索的方法先找到exit再到附近函数寻找三个参数的main方法还是比较容易操作的。注意release是可以直接看到三个参数的main，而debug是要进入到函数里面才可以看到。
重要说明：
之所以IDA可以直接找到main，是因为IDA是通过arc和argv的dll调用发现了main的，如下：
而如果使用了静态链接，也就是MT方式的话，如下图所示，那么IDA是无法找到main的！！！这个时候定位到main的话，就需要另外的方式了。
这个时候，就需要使用sigmake生成sig签名文件，让ida可以根据签名寻找函数名了。
3、debug模式： 多线程调试 (/MTd)寻找main：
ida里生成sig文件方法：将需要生成sig文件的lib放在flair75文件夹下，然后运行下面的几个命令：
具体参考这个文章：https://www.freesion.com/article/65491420550/
注意：冲突的时候需要编辑这个.exc文档，将前面几行的注释删除，下面有冲突的函数签名，选择一个，前面加上'+'，保存即可。 然后，重新运行sigmake工具，sigmake会自己读取修改以后的.exc文件，生成sig文件。
然后我的ida里代码终于成如下模样了：
这里比较难的是如何在xdb里寻找到main。看符号和callstack已经比较繁琐了。
在test.exe里搜索exit，找到exitprocess调用，设置断点：
运行， 然后观察调用stack：
向上走了2,3级才看到下面真正的main，也是很蛋疼：
4、release模式：多线程 (/MT)寻找main：
同上，ida里也需要制作sig文件。
总之呢，static方式链接的exe要找main还是比较复杂，需要较多的工程经验。即便是看到了exit，也需要向上捣腾好几级，在进入附近的函数（甚至还继续点击进去）才能够找到main。
