行业新闻

Typora解密之跳动的二进制

Typora解密之跳动的二进制

磨刀霍霍 :准备工作

开发环境识别

用IDA打开 Typora.exe (不建议,可能是我电脑问题,IDA分析了三四个小时),打开后发现程序中有 electron ,V8字样,由于前几天刚好分析了一个IE漏洞,由V8联想到 JavaScript引擎,此时猜测与JS语言有关。

打开程序目录,查看一下有没有JS代码,一番查找,看到了asar文件以及node字样,感觉有些眼熟哪里见过。问一下度娘,百度搜索asar,electron,nodemodules

不搜不知道,一搜吓一跳,原来这是使用 NodeJs的electron框架开发的桌面应用,JS也能写桌面程序了。

继续搜索相关资料,得到以下信息:

1.electron 使用了谷歌的 V8引擎以及渲染引擎(意思是这种程序跟个浏览器差不多呗)

2.electron 有主进程与渲染进程 ,通过IPC交换信息,渲染进程只负责渲染(难怪我附加调试有好几个进程。。)

3.Typora.exe是electron框架,基本与开发者的代码无关(修改框架复杂度太高,一般人不会去动,所以别去逆向它了)

4.查看目录发现,在app.asar.unpacked中发现了一个 main.node ,看名字很奇怪,.node文件是啥东西

5.app.asar是打包的JS代码,并且只是简单的打包,没有任何加密措施,且electron也没有代码保护措施(圈起来要考)

根据第五条信息,笔者尝试使用工具对asar进行解包,解包失败不知道什么原因(或许必须使用NodeJS自带的解包工具?但是解包也是加密文件,我又懒得下载nodejs,需要的时候再解吧),放进010editor查看,得到文件名与一些密文,此时陷入了僵局。

尝试调试

打开typora进程,x64dbg附加,查看有没有有用的信息(刚开始我不知道这个是NodeJS开发,想着通过注册窗口跟踪程序流程,好家伙差点就逆到引擎去了),发现了有好几个进程,后面命令行参数可以看到渲染gpu等关键字,并且目录参数指向了app.asar。

根据前面得到的信息,这些进程都是由主进程创建的,程序逻辑是由主进程处理,那么附加主进程看一下(没参数的那个)

看到了主进程加载了main.node模块,什么.node也能当dll加载 ? 或许它本来就是一个dll呢(也不排除加壳后,手动加载的情况)

那么使用PE工具查一下,VS2017编译的64位DLL。

梅开二度 :逻辑分析

到这一步,已知信息:

1.JS文件被加密

2.框架为electron

3.框架会加载main.node模块

4.解析JS脚本的是V8引擎

5.c++支持node api进行开发

根据我们的已知信息,来对程序的整体逻辑进行一个简单的分析。

1.框架对代码无保护且修改框架难度过高,V8引擎不支持解析加密的JS代码,那么JS代码如何运行?

站在一个开发者的角度,我可能会想到由框架加载我的解密代码,把js代码解密后送到js引擎去执行就可以了

2.那么解密代码放在哪里合适呢?

既然框架被编译为二进制了,且根据之前的分析,妥妥的c++开发,想要最简单的方法实现解密,加载同样为c/c++编译的二进制代码即可。在Windows平台上,想要加载代码执行,也就剩动态链接库了。由此可以推测,之前找到的main.node,可能就是解密模块。

逻辑总结

  • 框架加载解密模块
  • 解密模块对app.asar进行解密(解密后会不会把文件写出来呢,如果写出来可以直接拷走。。)
  • 解密后的代码送入JS引擎执行
  • 另外的逻辑 :由解密模块解密app.asar的xxx.js代码,xxx.js代码执行后,由它来负责解密剩下的js代码并执行,可以提高破解难度

精益求精 :main.node分析

1.根据之前的推测,main.node负责解密,按照程序员开发习惯,Ctrl CV实现,也就是使用公开的一些算法

2.IDA加载main.node,按照逆向惯例,先搜索一波字符串

此时看到了buffer,base64,app.asar等关键字。猜测一下,app.asar加载到buffer然后进行base64解密。 

3.继续开展搜索工作,base64未免太过简单了吧,使用FindCrypt3插件 ,搜索一下算法常量吧。

此时找到了AES的算法常量,前两个是重复的,可能是插件问题。

4.好的,现在面临一个问题,我不懂算法,怎么解密。。。只能去问度娘了,搜索一下AES加密解密原理与 C 实现代码。

5.根据搜索得知:

  • AES使用最后那个常量数组进行解密
  • AES有五种加密模式,常用的为ECB CBC模式
  • 根据AES密钥长度,有不同的加密轮数(不是很懂哈。。)

6.对解密常量进行交叉引用跟踪,找到这个函数以后,继续对函数进行交叉引用跟踪。

大概经过三四次的跟踪,发现了这个函数,在这个函数里F5查看反编译代码,发现了app.asar字符串的引用。

7.此时进行推测,这个函数加载了app.asar的内容,并且调用 SUB_180003E40进行解密。

8.跟进SUB_180003E40 进行查看 ,此时发现了base64字符串的引用,推测对buffer进行了base64解密。

9.看到很多不认识的API,百度搜索得知,这是Node API,简单去看一下函数功能http://nodejs.cn/api/n-api.html#napi_call_function

NAPI_EXTERN napi_status napi_call_function(napi_env env,            //环境                                           napi_value recv,         //名为global的值                                           napi_value func,            //要调用的javascript函数                                           size_t argc,                //JavaScript函数的参数个数  类似argc                                           const napi_value* argv,  //JavaScript函数的参数数组  类似argv                                           napi_value* result);     //返回的JavaScript对象

10.根据文档得到的信息,参照这一部分Node API,得到了如下信息(猜测调用了此函数)笔者对这语法难以理解,程序的目的是把对象进行base64编码?但是看这代码,base64也没有被当作参数传递进去

Buffer.from( object, encoding )object:此参数可以包含字符串,缓冲区,数组或arrayBuffer。encoding:如果对象是字符串,则用于指定其编码。它是可选参数。其默认值为utf8。 Buffer.from(string[, encoding]):返回一个被 string 的值初始化的新的 Buffer 实例

11.暂时先不管node api的语法与功能,继续往下看。

看到了这部分的函数调用,进入查看,发现与 C实现AES算法结构相似,推测这部分为AES解密。

分析总结

根据目前的分析,得到如下信息

  • main.node模块使用node api 进行js函数调用
  • main.node模块使用了AES解密算法(模式未知)

到了这一步,想要继续破解,首先要得到js代码,有两个办法以及面临的问题。

1.分析算法,找到密钥,如果是CBC模式,还需要找到IV ,之后使用解密算法,解密app.asar的js代码

2.分析程序执行流程,找到解密后的缓冲区,直接拷走,得到彻底解密后的js代码。

 

面临的问题:

  • nodejs语法不懂,这些api调用的具体js函数不清晰
  • AES解密流程不熟悉,找到密钥或者iv的难度较高(通过加密轮数判断密钥长度,通过算法部分判断加密模式,并找到相关数据)
  • 就算你找到解密AES的办法,它会不会还有别的加密措施与防护措施,例如密钥需经过hash摘要,文件完整性校验等(如果还有加密保护措施,那还得继续分析别的算法,一步一步还原,对于算法不熟悉的人时间成本太大了)

大海捞针 :寻找JS代码

1.根据之前的分析,我选择第二种获得js代码的办法,分析程序执行流程得到解密后的 JS代码。

2.分析解密前的 js函数调用,由之前的分析得知,参数有两个,在V27的位置,V27是由参数 a3 +8 得来的,动态调式一波。

3.x64dbg打开typora.exe,下一个dll断点,根据之前分析,他是动态加载的(多打了个a 懒得换图了)

4.断点设置完成后,断在loadlibrary,进入模块入口后,去IDA计算偏移,定位到前面分析的函数位置。

对了,记得使用x64dbg自带的 PEB隐藏功能,并忽略所有异常,这个模块有简单的反调试手段(查看导入表可知,太过简单不分析反调试手段了)

定位函数位置,直接看后4位即可,同样为模块偏移 674A的位置。

5.下断后查看decrypt(命名一下方便)函数的参数,x64架构下,函数参数为 rcx rdx r8 r9 rsp+0x20

前四个从左到右,超过四个则入栈,rsp+0x20为起始地址,详情可参考微软x64调用约定。

 

6.r8 = a3 查看 *(a3 + 8)的值, ,这个值为之前分析的 v27 地址,也就是argv 继续查看指针指向内容。

现在得到了buffer.from js函数的两个参数 ,第一个像是密文,第二个没看出来,不是预料中的base64,所以之前的推断貌似是错的?

7.关注一下这两个地址 0000079908482119 00000799083CFEA5 在调用完js函数会有什么改变,直接来到调用的位置,调试器同步来到这个位置。

来到这个位置再次确认参数,第五个参数为 rsp+20,也就是rax的值,rax为argv,进入内存查看得到前面同样的地址,也就是 (a3 + 8),步过这个函数,查看对参数的改变。

8.执行完后查看刚才记录的位置,好的好的,耍我呢,啥都没变,并且后续也没调用相关数据(或许是最后一个参数返回了一个对象,忘记看了,如果返回的话应该是密文相关的东西,并且放到了某个数据结构中,所以在IDA中没看到直接使用的行为)

继续分析,到了AES解密代码部分,既然是解密,那肯定得把密文的缓冲区拿过来吧。

首先看到一串16进制的赋值,v46开头的数组 刚好32个字节,也就是256bit有点像是AES-256的样子了。然后看到申请了 32字节的内存,v32

之后调用了 sub_18000B060函数,对v46 与 v32进行操作, 目测参数为 (目标地址,源地址,大小)

进入 sub_18000B060函数查看,一大堆运算,根本不想看,根据之前的推测,可能是作者感觉直接把密钥放在程序中有些不妥,所以对密钥进行一个类似于解密或hash运算的工作(不展开分析了)

9.继续分析

可以看到sub_180007000 函数 ,参数v45 IDA提示我是一个 char[256]的数组,v32为32字节的地址,v10为一串神秘数据。

可以得到一个结论,在经过 v46的一系列运算,得到了一个同样大小 32字节的数据,再把数据 与 v10神秘数据进行操作,放入v45的256字节的数组中(好家伙 这是密钥吗 搞这么复杂)

跟进sub_180007000 查看, 把v10放到了 v45数组的0xF0的位置

之后调用了sub_180007800函数对自己的PE文件有些操作,简单看了下前面的汇编,主要内容为,把v32 放到 v45中,大小为32字节

10.继续分析

接下来看一下sub_180005c00 函数,使用了v27,之前分析出来的密文地址就在v27中,v30没看出来,应该是传出参数后面用到了。

猜测这个函数对密文进行一波操作,看一下返回值用来做什么,这个伪代码看的头疼,汇编看一下。

.text:0000000180004021                 call    sub_180005C00.text:0000000180004026                 mov     rbx, rax.text:0000000180004029                 mov     r14, [rax+8]    ;返回值+8的内容给 r14.text:000000018000402D                 sub     r14, [rax]       ; r14 - 返回值的内容.text:0000000180004030                 mov     rcx, r14        ; 得到一个大小 Size

人工反编译一下 首先确定rax为一个指针 *(rax+8) - *rax 就是这个地址里面存储了两个值,拿第二个值减第一个值得到一个size。

此时猜测,这两个值或许是 密文的开始地址与结束地址?

然后用这个size 申请了一块内存 , IDA 命名为 Block , sub_18000B060 之前分析过, 对*v12进行操作, 结果给到Block

把V12代入rax中 , *(v12+8) - *v12 , 结束地址减去开始地址得到 size

由此可以验证猜测, *v12 为密文开始地址 ,V13为密文大小

11.继续分析第三个方框的内容

以v13 + 1 的大小 申请了一块内存 v14 , sub_18000B060 对 Block 再次进行操作, 结果给到v14。

v14的最后一个字节置为0 ,推测已经把密文转换为字符串了 , 需要一个 NULL 结尾。

;v15 = r8d   rcx = v13    rbx = v14 .text:0000000180004094                 movsxd  rcx, r14d.text:0000000180004097                 movzx   r8d, byte ptr [rcx+rbx-1]

由上可得 v15 = v14[v13-1] , 也就是从v14中取了一个字节的值 ,位置在null字符的前一byte。

12.继续分析sub_180006AC0

可以看到,sub_180006AC0 的参数 , v45(256字节数组),block ,v13。

结合之前对 sub_180007000的分析,可以得知, 目前v45的状态 ,v45[0-31]为32字节的类似密钥的东西 v45[0xF0] 为 v10的神秘数据 ,v13为Block大小。

跟进简单查看 ,查看后感觉可读性不好,笔者对照汇编代码,重新修改了一下反编译代码。

__int64 __fastcall sub_180006AC0(v45,block,block_size){   if ( block_size )  {    v3 = block;    v5 = v45 + 0xF0 - (_QWORD)block;           //v45+0xF0的地址  减去  block的地址得到v5    v6 = ((block_size - 1) >> 4) + 1;          //做为外圈循环的次数    do    {      v7 = *v3;                  //v7为 xmmword 16字节浮点寄存器 ,把block的内容取16字节给v7  16字节符合AES块大小      //由此推测block是真正的密文,将在这个函数中进行解密操作       sub_180007320(v3, v45);    //用到了AES解密常量  应该是解密相关  并且对推测的key  也就是前32字节有一些操作      v8 = 16i64;                //内圈循环16次      do      {        result = *((char*)(v3 + v5));       //block地址 + v5偏移  取一个字节内容        *(char*)v3 ^= result;               //取block的1字节数据,与block地址 + v5偏移  进行异或        v3 = (__int128 *)((char *)v3 + 1);  //block += 1        --v8;                                //总共16次 也就是16个字节异或      }      while ( v8 );      v5 -= 16i64;                          //外圈循环  v5 每次-16  也就是每次异或 异或的值都会变化 范围为-16字节      v45 + 0xF0 = v7;                        //block的16字节内容  给到v45+0xF0      --v6;                                    //外圈循环次数    }    while ( v6 );  }  return result;  }

根据目前的分析,可以推测 ,sub_180006AC0函数为 主要的解密算法函数,看着像是 AES CBC模式,因为对算法不熟悉,大胆猜测一下。

key存放在v45中, 前32字节 ,也就是256位 , iv存放在 block+v5中 (不清楚对不对)

13.继续分析剩下的内容

 

 

好的好的,看着有点头疼,后面的代码大概意思就是,又对解密后的数据进行了一系列操作,最后返回了一个缓冲区。

读者感兴趣可以自行分析,实在是写不动了。

釜底抽薪 :得到JS代码

1.根据前面的分析,我们已经大致了解了程序流程,来到调用解密函数的函数,只需要在彻底解密后,送到JS引擎执行的时候,拿到解密的JS代码即可。

 

2.根据上层调用代码,可以得到,解密后返回了一个值,作为调用JS函数的参数 ,定位到678F偏移处,x64dbg同步定位。

3.断下后查看v28的内容 , RSP+20 的位置,然后继续查看这个指针的指针的内容,最后得到了解密后unicode形式的JS代码。

4.把内容拷走,拿到010editor,把00去掉,变成ascii形式,检查一下得到的数据。

看起来跟密钥有关的一串字符编码数据:

搜索一下license相关的数据, 找到不少,看起来也像是代码,应该没问题

指鹿为马 :破解可行性分析

修改文件破解

如果懂算法与NodeJS,可以通过分析,找到关键的key等数据,对app.asar进行解包解密操作得到JS代码进行修改后,打包回去即可

可能遇到的问题:对app.asar进行完整性校验。

内存破解

简单说几种思路,由于main.node是后加载的模块,所以内存破解有些难度。

  1. 调试器加载 :参照上述手段,在模块加载通知中断下,定位到解密函数下断,修改内存中的JS代码
  2. 导出表HOOK:参考病毒木马使用的进程替换(傀儡进程)技术,创建进程后挂起,由于main.node中的node api是使用框架中的导出api,所以可以替换导出函数为自己的函数,在调用时进行参数判断,如果为JS代码,则修改
  3. DLL劫持:替换main.node,由自己加载真正的main.node并调用,调用时,定位到解密函数并hook,等待JS代码并修改
  4. PE代码注入 :修改框架的PE文件,并加载自己的DLL,加载后进行导出表hook

可能遇到的问题:对main.node或者框架进行完整性校验,更加强大的反调试手段。

方法还有很多,不再一一列举,这里只能提出思路

点到为止 :总结

  1. 通过这次逆向分析,踩了不少坑,学到了不少东西,并且加深了逆向技术的基础。
  2. 作为一个逆向练习生,遇到不懂的,不会的,应该迎难而上,扬长避短,不可轻言放弃。
  3. 遇到一个纠结的地方,不要过度停留,逆向分析应该是分析大方向,站在开发者角度,根据分析出来的功能猜测作者的意图,以找到关键突破点。

结语

  1. 由于笔者对算法与Node Js开发并不熟悉,所以没办法得到密钥与其它解密数据(文章中关于算法的一些操作皆为推测,相信熟悉算法的大佬可以看出来密钥所在)
  2. 对于最后得到的JS代码也没办法判断到底完不完整,是否还有未解密的部分,所以只能到此为止了(看起来是完整了)
  3. 经过笔者一段时间的努力,已经成功实现内存破解,详情见下篇。
关闭