前两天心血来潮，想给C盘扩一下容量，结果玩脱了，系统开不了机了，无奈还原了一下，还原后发现连不了网了。浏览器无法打开网页，百度都进不去。但nslookup命令可以用。

ping命令直接ping IP可以，但PING 域名却不行。

解析也没问题，IP也可以ping，为什么偏偏域名ping不了。排查了一圈网络设置，从浏览器设置到网卡配置，从代理设置到DNS服务器设置等。路由器配置都检查了，网上搜了都不能用，禁用IPV6，禁用DNS CLIENT服务等等各种办法，尝试后仍无法解决问题。
抓个包看看吧，发现当ping域名时直接没有数据包，nslook时能看到DNS包。浏览器输入www.baidu,com也是一个数据包没有。
能发送DNS数据包，起码网络功能是没问题的，又试了FTP，MSRDP，ARP扫描等功能都没问题。感觉像是DNS服务的原因。但对比正常设备的服务列表，也没少啥服务，那是哪个服务出问题了？刚好也是很久没逆向了，看看能不能逆一下ping.exe找一下原因在哪

虽然本机连不了网，但好在远程桌面还能用，而且，刚好电脑够多。远程另一台电脑。把问题设备的ping.exe拷贝过去，在正常主机上可以工作。确定不是程序问题。之所以有这一步是因为这两台设备系统版本不一样所以Ping.exe的大小，hash都不一样了，所以才试试。
刚好也是很久没搞过逆向了，想着试试吧，走到哪算哪。但又想着这一直试着这电脑连不了网不是废了吗。所以先给问题设备做了个Vmdk，在虚拟机里分析吧。
目前来看，大致可以确定是服务原因导致的FQDN解析过程失败了。那就逆一下看看吧。先拉进IDA，加载个符号看看。然后分别在两台电脑上用X64dbg调试一下。
但问题来了，连不了网的电脑就没法更新符号库，导入map文件后还有问题，具体解决方法看这里https://editor.csdn.net/md/?articleId=124530547
既然是找不到服务，现在故障设备里用X64把服务相关的函数，比如OpenSCManager，EnumServicesStatusEx，OpenService等等加断点看一下，结果程序直接结束了。那就是没用这些API吗？后来才想起来这些API需要管理员权限，那应该确实就是没用到。那是找相对应进程吗？把遍历进程和查找进程的函数也下断，还是没有。
那就一步一步来吧，看看程序到哪一步返回有问题了。本来想写个X64脚本，时间长不写了，老是不对，IDA看了看，也不太复杂，F8慢慢过吧。
wmain里函数先走一遍，可以看出是ResolveTarget函数返回不一样了

故障设备返回0

正常设备返回1
搜一下这个函数的说明，没有，应该是未公开函数。IDA看一下。函数本身不负责，一共没用到几个API，感觉会出问题的只有GetAddrInfoW和GetNameInfoW了吧。

跑一下看看，果然在执行第二个GetAddrInfo时。故障设备返回了个0X277c，正常则返回0。而且看起来两次执行GetAddrInfo只改变了一个参数，ai_flags，第一次是4，第二次换成了2.上MSDN看下这个函数。
返回277c，十进制是10108，跟进根据MSDN说法是无法提供服务

而ai_flags则用于指示 getaddrinfo函数中使用的选项的标志。当等4时必须时纯数字，

虽然知道了第一次执行GetAddrInfo失败的原因，但第二次执行时为什么故障设备会无法提供服务，提供的又是什么服务呢，继续挖吧。
那就继续F8走吧，不过可以现在IDA大致看一下决定返回值的函数有哪些，以及可能会出错的函数又有那些，基本可以定位到问题函数。这里不赘述。
最终定位出的问题函数流程为:
ws2_32:GetAddInfoW->ws2_32:LookupAddressForName->ws2_32:QueryDns->ws2_32:QueryDnsForFamily->ws2_32:WSALookupServiceBeginW->ws2_32:NSQUERY::LookupServiceBegin。到了NSQUERY::LookupServiceBegin这个函数时，会重复多次执行LookupBeginEnumerationProc这个函数。

对比过每次的返回值都无显著差异后，却在之后的执行中跳转到了不同的地方。

这个je跳转的地方，正常的不会发生跳转。故障设备则发生了跳转。分析一下跳转原因，当r13+10地址上的值指向自身时，则跳转。往前会查r13值是参数一RCX给的。那看一下进入函数时RCX+10的值吧。重试后发现，无论故障与否。进入函数时该值是相等的

那在正常设备中给RCX+10的地址加个内存读写断点。看一下什么时候改变的数值。然后发现是在LookupBeginEnumerationProc内的NSQUERY::AddProvider函数中改变的

在两台设备里都给这个函数下断，看看有何不同。结果故障设备根本就没走这个函数。现在需要弄明白两件事，因为LookupBeginEnumerationProc这个函数是多次执行的，先要搞明白两台设备重复次数是否一致，以及正常设备第几次执行时会执行NSQUERY::AddProvider这个函数。而是看一下LookupBeginEnumerationProc这个函数什么情况下会去执行NSQUERY::AddProvider。
第一个问题结果是两台设备都执行了6次这个函数，且正常情况下第六次会执行NSQUERY::AddProvider。第二个问题，看IDA很容易看出来。

只要前边不return，那正常流程就可以走到AddProvide的。因为这个函数返回值非零，所以其实只要返回1的两个地方判断不成立即可。看起来大概率是LoadProvider函数的返回值影响了结果。加个断点看一下。果不其然，在正常设备中，LoadProvider函数返回0，而故障设备则返回E。
那就继续进LoadProvider函数里F8一步一步往下挖吧。其实在IDA大致就可以看出问题函数在哪里。比如这个LoadProvider里其实只有NSPROVIDER::Initialize看着可能会出问题。一验证，果然。

最终，在F8查找法下逐层定位的问题函数如下：

比较麻烦的就是因为牵扯了三个dll，需要打开多份IDA，而且导入多次MAP文件。每个函数都先看下IDA，再去找找MSDN有没有官方说明，有说明的参数看起来会更易懂。在定位到Reg_GetValueEx后，看IDA发现它会调用RegQueryValueExW函数。就觉得是它了，同时也后悔为啥没早点想到给注册表函数下断。

给RegQueryValueEx下断，查询的键值为
计算机\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters下的hostname键。在故障设备一看，真的没有这个键，而正常设备中这个键键值为本地主机名，一般是DESKTOP开头那个。

在故障机设置里看，发现故障机没有主机名，而且不能更改。没办法，那就直接该注册表吧，在注册表加入了hostname键值后重启。问题解决。
ok，到这里就结束了，实际上问题原因很简单。而且如果我能早些想到注册表加断的话，应该会更早解决，我这个方法也是够笨了。记录一下，提醒自己有多菜。