某 .NET RabbitMQ SDK 有采集行为，你怎么看？ _生活百科

一：背景1.讲故事前几天有位朋友在微信上找到我，说他的一个程序上了生产之后，被运维监控定位到这个程序会向一个网址为： http://m.365ey.net 上不定期打数据，而且还是加密的格式，要他解释到底是怎么回事？朋友说根本不认识这个网址，最后在恐慌中排查到是项目中引用了 DeveloperSharp.RabbitMQ 组件所致，截图如下：

文章插图
朋友反编译了下sdk源码，发现都是混淆过的没法看，聊的过程中朋友很恐慌，很焦虑，担心生产的数据被泄漏，让我帮忙看下是否有手段定位下到底都采集了什么数据？
说实话，这种事情听起来就很惊魂，情从肺腑出，方能入肺腑。。。只要是一个正能量的人，这个忙肯定是尽最大可能的帮一下。
二：WinDbg 分析1. 前置工作准备从 nuget 中把 DeveloperSharp.RabbitMQ 下载下来，写好一个测试案例。

internal class Program{static void Main(string[] args){for (int i = 0; i < int.MaxValue; i++){try{var queueName = "jk";var content = $" hello world! {i}";RabbitMQHelper.SendMessage(queueName, content);Console.WriteLine($"时间：{DateTime.Now}, i={i} 次处理！");}catch (Exception ex){Console.WriteLine(ex.Message);}finally{Thread.Sleep(1000);}}}}

为了安全，我把程序放到虚拟机中，同时在 hosts 下给它设置个错误的 ip 地址。
192.168.1.30 m.365ey.net接下来打开 Fiddler，再用 WinDbg TTD 的方式把程序启动起来来记录程序的全部行为，方便我后续分析，

文章插图
正如朋友所说，真的有采集行为：

http://m.365ey.net:13064/AssistLog.svc
http://m.365ey.net:13063/QueryLog.svc

2. 如何寻找请求代码块截获请求的代码很简单，因为屏蔽了 IP ，所以请求肯定会抛异常，我只需要用 sxe clr 拦截下 First Chance Exception 就能捕获到调用代码。

0:013> sxe clr0:013> g(3398.3f7c): CLR exception - code e0434352 (first/second chance not available)First chance exceptions are reported before any exception handling.This exception may be expected and handled.Time Travel Position: 16D93B:0eax=079befe8 ebx=00000005 ecx=00000005 edx=00000000 esi=079bf0a8 edi=00000001eip=77207380 esp=079befe0 ebp=079bf040 iopl=0nv up ei pl nz ac pe nccs=0023ss=002bds=002bes=002bfs=0053gs=002befl=00000216ntdll!RtlRaiseException:77207380 55pushebp0:013> !clrstackOS Thread Id: 0x3f7c (13)Child SPIP Call Site079bf0fc 77207380 [HelperMethodFrame: 079bf0fc]079bf1ac 78861902 System.Net.HttpWebRequest.GetResponse() [f:\dd\NDP\fx\src\net\System\Net\HttpWebRequest.cs @ 2254]079bf1fc 0a5a2e89 System.ServiceModel.Channels.HttpChannelFactory`1+HttpRequestChannel+HttpChannelRequest[[System.__Canon, mscorlib]].WaitForReply(System.TimeSpan)079bf24c 0a5a1199 System.ServiceModel.Channels.RequestChannel.Request(System.ServiceModel.Channels.Message, System.TimeSpan)079bf2c0 0a5a1026 System.ServiceModel.Dispatcher.RequestChannelBinder.Request(System.ServiceModel.Channels.Message, System.TimeSpan)079bf2d0 0a5703f3 System.ServiceModel.Channels.ServiceChannel.Call(System.String, Boolean, System.ServiceModel.Dispatcher.ProxyOperationRuntime, System.Object[], System.Object[], System.TimeSpan)079bf3cc 0a57010d System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(System.Runtime.Remoting.Messaging.IMethodCallMessage, System.ServiceModel.Dispatcher.ProxyOperationRuntime)079bf3f8 0a56f79e System.ServiceModel.Channels.ServiceChannelProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage)079bf438 7b224e24 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(System.Runtime.Remoting.Proxies.MessageData ByRef, Int32) [f:\dd\ndp\clr\src\BCL\system\runtime\remoting\realproxy.cs @ 823]079bf5d0 7a5df148 [TPMethodFrame: 079bf5d0] wfP8f24Vyfpc8suOyj.bBZbSsm9FOwaYWDWVc.Record1(System.String, System.String, System.String, System.String, System.String, System.String, System.String)079bf644 067c835f System.Base.ApplicationContext+c.b__19_0()079bf6b0 7b1dd4bb System.Threading.Tasks.Task.InnerInvoke() [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2884]...

从线程栈看，请求 http://m.365ey.net:13064/AssistLog.svc 是由 Record1 方法发起的，一看就是个 WCF 方法，参数名称和个数都和 Fiddler 中保持一致，截图如下：