menu arrow_back 湛蓝安全空间 |狂野湛蓝,暴躁每天 chevron_right ... chevron_right 002-binary chevron_right 006-分析配置文件的格式解密加密数据.md
  • home 首页
  • brightness_4 暗黑模式
  • cloud
    xLIYhHS7e34ez7Ma
    cloud
    湛蓝安全
    code
    Github
    006-分析配置文件的格式解密加密数据.md
    9.52 KB / 2021-07-17 00:01:36
        # 分析配置文件的格式解密加密数据
    
    0x00 前言
    =======
    
    * * *
    
    分析某程序配置文件的格式以解密加密数据。
    
    需要分析的文件为../config/ADF-Server.srv文件。先使用WinHex打开文件先看看有啥内容。
    
    说实话,由于经验不足其实也没看出啥,我猜吧0x~0x30为字符串信息,0x40~0xC0也是一段字符串。然后就是一些零散的数据了。哦,中间还有段网址端口。然后0x15C~文件尾都是一些加密数据了。至于目测就这样吧。。。打开程序来玩玩。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/42d54b8df84d274d093b2a9b0002699c1c98be90.jpg)
    
    0x01 分析
    =======
    
    * * *
    
    打开程序后弹出了一个对话框,是需要登陆的。发现登陆信息中有config目录下的ADF-Server.srv文件。那么肯定在程序运行时会加载ADF-Server.srv文件。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/338e36a9d2bab0ebc80ec1a90313d60510aa7d28.jpg)
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/fb37d2a1148c86595d15222530b4503dbbc7e5a9.jpg)
    
    不过还是想试试吧config下的所有ADF-ServerX.srv删除掉呢?保存后删除ADF-ServerX.srv除了一个默认的ADF-Server.srv其余的都没有了。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/d4ea96be1c1c8045d1e71f4796df9e6eb1ce39b4.jpg)
    
    好吧,知道会读取ADF-Server.srv文件后那么问题来了。我没有登录密码。。。好吧,取消后随便看看。在文件中找到了注册的地方。那就注册个新账户吧。。找到地方后注册时发现有个选择服务器,里面的内容有点眼熟啊。。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/d4146eb6c93094daad853bfb6593a4d2c65c34c2.jpg)
    
    诶,ADF-Server.srv文件中0x0~0x30不就是地址字符串么,0x40~0xB0不就是公司么。。我把ADF-Server.srv的地址改成HENGHENG,公司名改成HAHA试试。。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/05f55295e0578af986de5f321a12789035d8224e.jpg)
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/af588ebf3eefbe514145d902607a4c683d531794.jpg)
    
    那么可以证明0x00~0x30保存的是地址字符串,0x40~0xB0保存的是公司字符串。
    
    0x02 开始调试
    =========
    
    * * *
    
    注册号账户后感觉也没啥看头了。那么这样吧,既然会读文件那么那么可以开始动态调试了。
    
    用OD载入,对CreateFile的参考断点,但是在进程基址上CTRL+N中查找CreateFile只能找到A版本没有W版本。当时我对A版本下参考断点没用,断下后打开的也不是我想要的打开文件。这明显不科学,由于经验不足想了一会儿才想记起从哪看到的提升是“函数皆可W断下来”也就是对CreateFileW下断点。CreateFileW在Kernel32.dll中,对着Kernel32.dll,Ctrl+N查找CreateFileW,没有参考断点那么就直接在函数头int3。断下来之后F9,并且观察栈空间记录的打开文件的第一个参数字符串。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/39865cbc7a24d64f5ae4b0b495e27c4f44c003d6.jpg)
    
    找到需要查看打开的文件后往下翻滚栈到最后,找到返回地址。调用的是fopen()。。C库函数。。。。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/1d03f7a9e19bee4950af295b10a1695f4c87ad64.jpg)
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/1e01d4fc48934e862e59122a506f52a9f8b462c7.jpg)
    
    程序打开成功, 返回值不为0。走CALL 004C2E90这个函数。传递参数0x160。这个CALL内就是调用了mallo()申请一块0x160大小的内存空间。(我就不抓图了)。既然申请了空间那么肯定要读文件的,这会儿知道了是使用C库函数来对文件操作那么可以直接对fread()来下参考断点了。下好断点后就直接F9。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/ef8477df725f48e2bfbcf778659e6cbee9c0bf01.jpg)
    
    fread(ReadBuff, Length, ReadSize, pFile);
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/1ff466e4d53aadeb364258b8e542a1608fd37d54.jpg)
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/76afcf503a9c0b9e57097075ef10243b96c22c6a.jpg)
    
    只读取了上面差不多文件的一半吧。。既然只读这么多那么肯定是有用的。对内存下访问断点。断下后会对这些进行操作,其中ESI是BuffHead。
    
    ```
    0042CB53  |> \8A06          |mov     al, byte ptr [esi]
    0042CB55  |.  885E 3F       |mov     byte ptr [esi+3F], bl
    0042CB58  |.  3AC3          |cmp     al, bl
    0042CB5A  |.  889E BF000000 |mov     byte ptr [esi+BF], bl
    0042CB60  |.  889E 17010000 |mov     byte ptr [esi+117], bl
    0042CB66  |.  899E D0000000 |mov     dword ptr [esi+D0], ebx
    0042CB6C  |.  899E 5C010000 |mov     dword ptr [esi+15C], ebx
    
    ```
    
    上面这些步骤对内存中0xD0,以及0X15C以及其他的地方清0。其余的+0xXX都在文件中是以0存放,那么在文件中0xD0以及0x15C两处数据是无用的。然后继续往下跟
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/25a6ed1ba8b3f3ccdec537049dbc9dca33243c27.jpg)
    
    这段代码表示取0x4D位置的数据取出,并且判断它是否小于1或大于0x40。如果在这两个范围外则跳走,否则进行运算后调用下面的CALL。
    
    CALL内调用malloc()来申请堆空间,申请对空间的大小为0x460。这个0x460是对内存中0xD4位置取出来的值为0x7,进行运算后计算出来的结果。得知申请的内存地址为:0x10EA070然后继续F9。
    
    (补: 忘记了一步,所以这里的内存地址与下面的内存地址不同。)
    
    将申请的内存地址存入了0xD0的位置,然后继续F9
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/ae048e99800d81f188f0ce5ea1070a3256a8c79d.jpg)
    
    在0042CBE1处读取了0xD4,并且使用这个参数调用fread。那么Buff为EAX寄存器保存。通过OD插件提供的跳转的红线。得知是从上一步申请内存成功后跳转过来的。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/ca607bcfd7efe8b14a6bb8449104f50054d2a80a.jpg)
    
    fread(eax(Buff), 0x460(Length), 1, pFile(77CXXX))读文件,77CXXX为打开ADF-Server.srv的文件指针,这次读取的长度为0x460(0xD4位置的值并且通过运算得出)。读取的内容为。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/ca5526b9f7555f6899469d09bbecab9c835fb3c2.jpg)
    
    在文件中的内容为0x160偏移开始。并且从0x160开始到文件尾刚好是0x460大小。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/4d5912aec1bc45434430b757b2dd68428e85966f.jpg)
    
    那么我可以理解为,0x4D这里记录的数值是通过运算得出的是从0x160~EOF的大小。上面说了这里面有加密的内容。
    
    那么读取完文件余下部分后,对于加密数据肯定是会需要进行解密的。解密要么就在当前读取的Buff中直接解密,要么就先将数据拷贝到一个新的Buff中在对新Buff内容进行解密。要做这两个操作就需要对内存进行修改或者访问。那么这里我的想法是先对这块内存下内存写入。如果没有操作在对其进行内存访问。
    
    下完内存写入断点后F9。到了某个小函数中停止了
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/0b98cf2b2a15e41f224212f2f194faba44675598.jpg)
    
    貌似我运气是很好的,这段函数中我不停的F8,发现会从BuffHead开始从BuffHead循环取单字节值后进行运算得出结果并且复写回Buff中,而且写入的新数据貌似还是很有用的数据。既然这样的话我直接在循环结束为止下个int3,F9直接看结果。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/8062c46a80d1c65dbbf65d4c5df1f4e1787db14e.jpg)
    
    解密出来还是很有规律的,从IP开始到下一段IP开始一个段中的大小为0xA0,并且我数了数刚好有7块。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/353e1db4b3b0c201bed1b7ad89e7f408460c98ca.jpg)
    
    那么我能猜到,文件中0xD4这里记录的7是从文件0x160~EOF总共数据有7块。并且每块大小为0xA0。总长度为0x460(当然这里总长度是通过取0x4D的7然后对齐:(7+7*4)<< 5的计算的出来的。那么解密的函数为文章的目前位置倒数第三张图片。
    
    总结一下对ADF-Server.srv的结果分析
    
    ```
    0x0~0x3F:为服务器名称
    0x40~0xCF:为公司名称
    0xD0:文件中没用,内存中记录了读取文件0x160~E0F内存地址的Buff
    0xD4:记录了0x160~E0F的长度(通过(7+7*4)<<5获得)并且还是解密数据后块的数量,每块数量0xA0
    0xD8~0xEF:网站以及端口号。
    0x118:并没有使用
    0x15C:文件中没有使用,内存中清0
    0x160~EOF:被加密的数据。
    
    ```
    
    0x03 结语
    =======
    
    * * *
    
    得知解密函数后那么还得逆向一下解密函数时如何解密的。不过看样子解密函数是非常简单的。最主要的就是0x56B734地址内的内容了。
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/5fa59919eb3e16bd7b96e6f2cf1962b7fdb409c1.jpg)
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/8d1e6ab06cb85c11004a18b640930d25f9afc3af.jpg)
    
    ![enter image description here](http://drops.javaweb.org/uploads/images/8740f989ae7a9a30b878585bc41acd1d008d43fc.jpg)
    
    上面就是解密函数逆向后的内容,并且测试成功过。
    
    文章就到这里结束吧。。。。ByBy
    
    links
    file_download