内容
内容还是相当简单的。Theodo的工资单被外包给了另一家公司：Silaexpert。我们已经获得了访问权限，以及一个访问假期数目和工资单的url。
这一切都要从这个链接开始：http://www.silaexpert01.fr/silae。
此链接不能在Chrome、 Firefox 和 Safari上打开，也不能在windows10系统中运行。
似乎只能在windows7的IE浏览器中打开，对于所有在Theodo中运行Linux或OSX的开发者来说这不是个好消息。
黑匣子
我们可以从Microsoft 中下载一个免费的虚拟机︰ https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/。为此特定目的，VM 与 IE9 在 Windows 7 上会效果更好。
所以，拥有了虚拟机，也可以运行了，那就可以访问那个url了吧。可是它正在下载一个fat客户端，并且已经开始了某种安装进程。
最后就可以登录并下载你最后的工资单了。然后下个月这样的过程要再来一遍。如果重置虚拟机，也不行的，因为你没有许可证。
正式开始
如果你想在不经过VM的情况下直接在自己的Mac或Linux计算机中下载文件。你必须要将正确的请求发送给远程服务器（我还不知道具体的地址，可能被下载的fat客户端编码加密过了）。
所以，让我们先嗅探一下VM出来的所有网络通信。
可以在自己的平台上使用任意的嗅探工具：
· Wireshark，可用于大多数系统，但是也有可能矫枉过正。
· Charles Proxy，可用于Mac。
· mitmproxy ，喜欢使用python的人可以选择。
· Fiddler，在windows中使用（试用版可用于Mac和Linux）。
这里用proxy举例：
1.首先在主机上启动HTTP代理。进入代理，然后代理设置，注意所使用的端口。
2.启动VM
1)打开命令行，运行 ipconfig /all，注意默认网关IP。这是你的主机IP。
2）打开IE浏览器，找到互联网选项>连接>LAN设置，然后设置代理服务器IP和端口。
3）完成了！现在可以在Charles上看到所有VM出来的通信了。
现在，如果你登陆到fat客户端下载一张工资单，应该就会有足够的数据来考虑接下来的问题了。
数据分析
现在已经拥有客户端和服务器之间完整的交换信息了。
最先注意到的就是所有的通信都没有进行SSL/TLS 加密，真是轻松获得的数据！也就是说，我们还是可以通过虚拟机上的代理服务器生成假CA来嗅探加密通信。
我们还会注意到这几件事：
1.单一的web服务终结点：
http://www.silaexpert01.fr/SILAE/IWCF/IWCF.svc，所有请求都会转到这个url。
2.使用的协议是SOAP，没有使用任何的web安全模块。
3.登录请求似乎不同于所有其他请求，虽然看起来都很像。
4.还有一堆base64加密数据。
可以尝试解码这些base64加密数据，但是解码得到的只是一堆不可读的数据，它可能只是加密的二进制数据。
登录请求
向服务器发出的第一个请求只包含了一个有趣的数据，那就是一个密钥k：
<RSAKeyValue>
<Modulus>odfDJj...pEQ2RQ==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
此密钥k是由客户端使用的RSA公钥。响应中还包含一个密钥，使用的是同样的格式和某种类型的标示符$USR。这个密钥是服务器使用的RSA公钥。
我们刚刚见证了RSA的密钥交换。RSA不能用于加密大量数据，数据大小具体取决于所使用的填充技术，在这里我们使用的是2048位密钥，最多可以加密245个字节，不能再多了。
常用的技术是使用公/私 RSA 密钥来加密对称密钥，然后使用对称密钥加密交换过程。
很好，现在有了客户端和RSA密钥，下面做什么呢？
这是个好问题。下面要做的事情就是解码第二条信息的base64二进制。
echo "AQABAAAOE6jZqMmDnFHefXddjDq...W5A=" | base64 -D | hexdump -C
如果已经做过这件事好几次了，在发送出好多次登录请求之后，你可能会发现这样一个场景。
开头几个字节都是 01 00 01 00 00。这可以直接在 base64 中看到︰开头的几个字母都是"AQABAA"。很有趣的是00 01 00 00 是二进制表示形式，转换成十进制就是256。
我们可能会注意到的另一个就是261 (1 + 4 + 256) 的偏移量，字节总是 20 00 00 00，这是十进制的 32。
这是天才操作的一部分。一种常见的对称加密系统就是 AES 256，它使用一个初始化向量 (IV) 的32 个字节。
小小的总结一下：
· 第一个字节总是01。
· 接下来的4个字节是AES密钥的大小：256个字节。
· 下面的256字节代表的是实际的AES密钥，使用RSA公钥k加密，这会在第一阶段发送给服务器。
· 再下面4个字节是IV的大小：32字节。
· 下面的32个字节定义IV。
· 剩余的部分还是未知的，可能使用 AES 密钥进行加密的登录名/密码。
虽然只有一个AES，但是有很多变种。可以将这些变种都试一遍，但是这需要很长的时间和大量的精力。
到现在为止，我们还没有使用完手中所有的筹码。还记得那个fat客户端吗？这是我们加密问题的关键。
客户端使用的是NET语言，当然java也是可以的。
让我们来看看这段代码。可以阅读其他 proxified 请求来获取访问.exe的url。导入反编译的.exe (我是在 Windows VM中使用的试用版.Net 反射器)，然后寻找一些有趣的代码，可惜没有发现什么。
除了这一个小小的 DLL，Sila.WCFDLL.dll。导出它，然后重新将其导入反编译。现在，所有的安全内容就都会被序列化/反序列化程序处理。
我们得获得正确的AES。它使用的是 AES 加密的 Rijndael 256 变量与自定义序列化程序。
获取信息
我们没办法解密任何一个AES密钥，因为解密需要使用私人的RSA密钥。要想获取此AES密钥的唯一办法就是编写一个MITM服务器，借此来截获每个客户端和服务器之间的请求。
一旦该服务器编写完成（ https://github.com/kraynel/sila-cli/blob/master/server.js ），并且已经解决了固定缓冲区/字节转换/RSA/mcrypt 的所有问题，就可以再一次重新加载您的 VM 和登录了。
接下来使用Charles proxy的"地图远程"选项重定向所有 http://www.silaexpert01.fr/SILAE/IWCF/IWCF.svc 到你的本地终结点之间的通信，这些通信将会反过来解密通信并且暴露真正的终结点。
现在我们已经解密了所有二进制形式的请求。
序列化/反序列化
请求不是直接可读的。它们不使用 xml 序列化，而是使用序列化技术自定义编写的。 但是我们现在有代码在手，所以可以仔细研究一下。
现在，我们获取了所有的请求及其响应，和一个可读的JS。通过使用不同的参数，我们可以发现两个有趣的请求：
· AcquisitionBulletins，列出可用工资单；
· GenererPdf，下载工资单的pdf文件。