推荐使用rpx替代upx的公告

分类：uni-app

rpx upx

upx在2018年就推出了，其初衷是为了让微信的rpx机制可以跨全端使用。

在普通css写法里，upx会被编译器编译。但动态绑定时，upx无法被准确编译，此时官方提出了使用uni.upx2px()方法，用来动态计算。

后来其他几家小程序平台陆续都兼容了rpx机制，rpx不再是微信的专用单位，而成为了这个行业的通用单位。

最近官方收到很多开发小程序的用户投诉upx不能像rpx那样直接支持动态绑定，还得再使用uni.upx2px方法。

官方反思了策略，既然微信不可能支持upx的动态绑定，不如我们在App端和H5端来支持rpx的动态绑定。这样rpx就可以全端通用，且支持动态绑定，不再需要uni.upx2px方法。

从HBuilderX 2.0.5起，已经支持rpx的正常着色和px2rpx的ide代码提示转换功能。

官方也修改了uni-app文档中关于尺寸单位的介绍，不再推荐upx的使用，而推荐rpx。

这个策略调整，不影响开发者的已有代码正常运行。

开发者仍然可以使用upx和uni.upx2px，也可以改用rpx，都可以。没有必要批量调整老代码。但新开发还是应该使用rpx。

顺便提醒另一个事情，很多开发者对响应式单位依赖太严重了，比如组件高度或字体大小也使用upx/rpx。

注意只有当你需要某元素的单位要根据屏幕宽度大小变化时，才需要rpx这类动态宽度单位。

一般情况下高度和字体大小是不应该根据屏幕宽度变化的。

 一 前言

 

 


 

       加固厂商SO的加壳，一般都是采用UPX壳实现的。如果用原生的进行加壳，可以使用原生UPX进行脱壳。但是对于定制的UPX壳使用原生UPX是无法脱壳的。定制版的UPX一般有以下2种形式：

   

       1  将里面的魔术字符串改掉。下图是UPX源码中定义的魔术字以及修改后的例子：

 

                                  源码中的魔术字                                                                                           修改后的例子


                   

                 2 加密算法改掉或数据结构进行更改。  

 

                 这里讨论是如何手脱一个定制的UPX壳，尤其是更改加密算法或者数据结构的定制的UPX壳（以AJM为例）。先看一下脱壳后的样子：

          

                                                             脱壳前                                                                                                               脱壳后

                       

                 


二  UPX壳loader

        加壳一般需要加密和解密2个过程，UPX壳也不例外。UPX壳的解密是由 upx loader实现的。在UPX加壳过程中，将loader放在init段，确保loader先获得程序执行的控制权。

        Loader程序是由汇编代码实现的，下面是upx源码中针对arm平台的汇编代码：
                                                          

        在 dynamic段中，init标志值为：0x0C,见下图：

                                                            


        下面是loader在dynamic中的位置：

                                                                      

        当loader开始运行时的步骤如下：

 
                                                             


        从loader执行流程可以看到如下：

        1、loader是由汇编代码内嵌实现的，因此要解决重定位的问题，所以其中的函数调用都是使用系统调用实现的，比如mmap 以及mprotect等函数。        

        2、loader 程序要将加密数据解密，解密后的数据要覆盖加密数据。

        3、由于upx使用的是压缩算法，因此解密后的数据会比加密的数据大，此时loader程序也会被解密后的数据覆盖，所以loader在解密前要拷贝到内存中执行。

 

三  linker加载so

       Android系统的linker加载是通过dlopen函数实现的。以4.4源码为例如下：

                                                               

四  手脱UPX壳的原理

        前面说加壳一般需要加密和解密2个过程，UPX壳也一样。我们手脱指的是不用研究加密算法，动态脱壳。当upx的loader执行完后，代码也解密完成了，并且加密的数据被解密后的数据覆盖，是否可以直接在这个时间点，将SO从内存中dump出来就可以了呢？
       

 

        确实可以在这个时间点将so从内存中dump出来，但是只有这样是不行的，需要解决以下4个问题：

             ●  由于此时代码已经重定位完成，dump后plt段等信息已经包含了重定位后的信息，也就是绝对地址，此时静态用IDA打开，很多函数都无法识别。

 

 

             ●  Segment段中的Load段需要恢复，UPX加密后将原始的load段的大小由原来的加密前的大小改成了加密后的大小，因此需要修复。

             ●  Segment段中的 dynamic段在文件中的偏移需要修复。UPX将dynamic在文件中的偏移改变了。

             ●  section 段修复。对于section段的修复论坛里面有很多，这里就不讲了。

 

        因此解决了前面三个问题就可以实现手脱UPX壳了。

 

       

1 解决重定位的问题

 

        我们的目标是手脱UPX壳，因此我们可以将linker中执行重定位代码nop掉，就是不让linker执行重定位的操作，自然PLT等段中就不会带有重定位的信息。

        通过前面分析linker加载so的过程，soinfo_link_image调用soinfo_relocate实现重定位，下图是源码中相关调用：

                                                                      

       下面是在linker中的对应的汇编代码（ 对于如何找到对应汇编代码，只要在IDA中搜索字符串“[ relocating %s plt ]”就可以找到）：

 
                                                                            


        直接将上面的对sub_1464函数改成对应的”c0 46 c0 46”（thumb nop指令） 就可以。我们知道如果SO本身又调用了其他的SO，此时会优先加载其他的SO，因此注意nop的时机，避免将不是UPX壳的其它SO重定位也执行不了。

 

2 如何恢复segment段的load的大小

        我们知道upx壳的loader会对加密的数据进行解密，解密后的数据大小，就是对应load段的大小。

下面是UPX壳部分数据排列顺序：
                                                    

        下面是对应SO文件init入口数据：

                                                     


       l_info p_info b_info结构大小都为12个字节，如下：


                                                           


        根据上面的loader地址我们知道第一个l_info结构的地址为0x6508。见下图：

                                                               

 

 

       我们先不关心l_info和p_info结构，我们只关心b_info结构。对于b_info结构，第一个成员是压缩前的大小，第二个成员是压缩后的大小。因此我们可以通过b_info获取到被压缩数据的压缩前的大小：

       从上图可知，第一个b_info结构对应的压缩块：

               ● 压缩的前大小为:0x154

               ● 压缩后大小为0xA2

      这个块是对应ehdr和phdr的，我们跳过这个块，到达第一个load段对应的b_info结构。其地址为 :0x652C+0xA2 = 0x65CE，见下图：

                                                              

       从上图中对应的b_info结构，我们知道第一个load段压缩前大小为：0XDDC58。

 

 

3 内存dump的时机

        我们必须在UPX解密后，并执行原始SO的init前进行dump。因此我们就在linker执行完第一个init函数，也就是upx的loader函数后开始dump。因此断点的位置下图中的0x274A位置：

 

                                                                   

4 修复load段

                                                                  

       将上图中第一个load段的0x8B290改为我们之前获得0Xddc58。同时将第二个段的文件偏移和虚拟地址偏移改成一样，都为E5C60。

 

5 修复dynamic段
       对于UPX壳，原始的dymic段的文件位置被修改了，但是对应加载后的内存的位置并没有修改，因此我们直接将其在文件中的偏移改成与内存偏移一致就OK。如下图： 

                                                                   

 

      将0x8E888改成0xE6888。
 

 

 

四 总结

        1 将linker中的 soinfo_link_image函数中对soinfo_relocate调用 NOP（避免重定位造成内存dump后IDA分析问题）

        2 在upx init（loader）入口处找到第一个l_info地址，从而获取到第一个b_info结构地址；

        3 跳过第一个b_info对应的压缩数据块，到下一个压缩段的b_info；

        4 从b_info结构中获得压缩前的大小；

        5 执行完upx的解压后，从内存中dump UPX壳；

        6 将第一个load段的文件大小 虚拟地址大小，物理地址大小都改成压缩前的大小；

        7 将第二个段的文件大小，虚拟地址大小，物理地址大小都改成相同；

        8 将dysmic修正（将文件偏移改成与虚拟地址偏移一致）；

        9 将sht清0（后者在文件结尾找个位置，同时将sht_size清0）。（也可以根据dynamic修复）。

 

 


转自：https://bbs.pediy.com/thread-221997.htm

1、canvas无效，出不来

修改前：
let ctx = uni.createCanvasContext('shareCanvas');

修改后：
let ctx = uni.createCanvasContext('shareCanvas', this);

在自定义组件下，第二个参数传入组件实例this，若不传，则无法显示
2、canvas绘制图片（drawImage）无效，显示不了

修改前：
let imageW=uni.upx2px(456)//图片的尺寸
let imgUrl=this.shareData.image//动态的图片，网络路径
ctx.drawImage(imgUrl,0,0,imageW,imageW)
ctx.draw();

修改后：
let imageW=uni.upx2px(456)//图片的尺寸
let imgUrl=this.shareData.image//动态的图片，网络路径
uni.downloadFile({
	url:imgUrl,
	success(res){
		ctx.drawImage(res.tempFilePath,0,0,imageW,imageW)
		ctx.draw();
	}
})

uniapp的drawImage绘制图片和微信小程序一样，图片路径不能使用网络路径，必须先下载到本地（使用uni.downloadFile()下载成临时文件路径也行）

这是我自己写的一个简单程序，放到PE工具里观察输入表：



然后我们随便用一个加壳工具给原本的程序加壳，再次观察它的输入表内容，发现已经有了变化（少了很多）：



所以我们就要尝试脱壳，读取它正确的输入表内容，下面以 “租号玩.exe”（假的） 这个程序为例。首先用 PE 工具查壳，发现是 UPX（顿时有了信心 ? )

用 OD 打开 租号玩.exe ，选择 “否”

我们尝试使用 ESP 定律法脱壳，留意 ESP 的值：



单步 F8 一次，发现 ESP 有变化：



数据窗口中跟随 ESP，在这个地址下硬件访问断点：



F9 运行程序，在如下位置断下：

（留意我下断点的红色地方，这个 jmp 是一个大跳转，很可疑）



记录下 jmp 的地址，到内存窗口看下，发现这个地址位于 .text区段，说明这里就很可能跳转到了 OEP。



跟进去看一看，发现果然是 OEP 的样子：



然后我们就可以保存找到的 OEP 位置了，在反汇编窗口右键 - 用 OllyDump 脱壳调试进程 - 脱壳。



再次使用 PE 工具观察，发现已经脱壳成功，而输入表也恢复了正常：