我正在为多媒体设备构建替代控制器应用程序。
原始控制器可用于Windows（我针对）以及mac，ios和android。
设备与控制器应用程序之间的大多数通信与UPnP协议相似，因此以XML格式传输，并以明文形式可读。
设备在其中一种情况下发送给控制器的某种令牌（控制器随后使用该令牌对其他服务进行身份验证），并且此传输似乎已被编码/加密/混淆（在本文中称为“编码”）。
此编码形式已传输在正常的UPnP响应的XML字段中。
在监视编码形式的几种传输时，我做了以下观察：
它总是以2开头：和后面跟的似乎是base64编码的st ring
当多次发送时，即使内容没有改变，字符串也会改变（这是在假设编码之前不包括时间戳等其他变量的前提下）。因此可能存在某种盐。
如果不更改数据，字符串的长度将保持不变。
如果从控制器中删除所有令牌，则在此字段中还会传输一些编码数据。这使我想到要么发生填充，要么（更可能是）编码的字符串解码为数据结构（甚至是XML）的序列化自。
用于身份验证的令牌（因此为解码形式）即使编码版本不同，它仍然保持不变。
应用程序本身是用C＃编写的，但是所有与安全相关的内容（包括解码/处理令牌）似乎都是使用DLL的pINVOKE调用的，而该DLL并不是用.net编写的。
我怀疑要进行编码的dll，但是返回了很多可能的结果（超过30个）。
查看dll时，似乎openssl库已编译到其中，因此可能会有很多误报。
DLL还处理HTTPS通信，因此openssl不一定与我正在寻找的编码方法有关。
我试图研究ida pro和windbg，但是我从教程中读到的内容这主要围绕设置断点，然后单击一个激活按钮，例如
但是，在我的情况下，控制器应用程序在应用程序启动时（包含数十个其他UPnP数据包）一次接收到此数据，我的猜测是解码是在接收到数据包时发生的，因此无法设置断点到一个按钮。
但是我能弄清楚的是解码的令牌存在于内存中（但是每次启动应用程序时偏移量都不同）。似乎在运行时内存中没有编码的版本。
（表示）表示相同数据的三个字符串： />
#1 楼
不能评论，所以答案是:)-如果您知道它是什么dll并且需要用.net编写，则IDA可能不是最好的选择（个人而言）经验）。
但是，如果您仍在寻找需要反编译的dll，则可能需要给APImon和procmon一个镜头，以查找确切需要反编译的内容。
我建议尝试使用.net反编译器，例如dotPeek或任何其他。通常，您可以从任何.net程序中读取代码（不会混淆/加密）。
如果混淆了dll，则可以尝试使用de4dot对其进行混淆或从内存中转储并分析它。 />上面的字符串绝对是base64编码的，因此您可能会寻找object.binary.base64
评论
抱歉，我不清楚。通用程序是用.net编写的，我已经使用dotPeek进行了研究。但是，与接收编码的字符串，对其进行解码并将其用于针对远程服务进行身份验证有关的所有事情都在非.net DLL中完成。从我的分析看来，解码后的字符串永远不会离开此DLL。
–leepfrog
2014年1月27日12:35
明白了：）我将从查看该dll的导出开始，以查看名称是否足够暗示并在其中进行一些谷歌搜索。另外，您也许可以将加密的字符串作为参数传递给dll导出（尝试ollydbg），并对其进行调试以查看整个操作过程。
– Sigtran
2014年1月27日14:26
#2 楼
看看IDA Pro的插件IDA Scope。它具有一种加密识别功能，我认为这会为您提供帮助。
评论
您是否尝试反编译.net部分？它会被混淆吗？我可以使用dotPeek打开.net部分，而不会出现问题。问题是，接收/解码和使用字符串是在非.net DLL中完全处理的。