UPX对Android上ELF加壳使用过程中的若干问题总结
1. UPX中使用的压缩算法有三种，最早是UCL，然后加入了NRV，3.91版本又加入了LZMA。按照UPX源码中的文档来说，UCL压缩效率是相对较低的，但是好处是OpenSource的，NRV效率较高，但是不开源，而LZMA算是这三种中压缩效率最高的了，在7Zip中就是使用的这种压缩算法。但是从UCL的官网来看，UCL是对NRV中的一些算法的重实现，这样来说的话应该压缩效率更高才对。这里不纠结这个了，具体信息见相关链接：http://www.redhat.com/archives/blinux-list/2003-September/msg00030.html
2. Packed programs will be byte-identical to the original after uncompression. UPX是安全的、没有数据损失的压缩工具。
3. UPX对ELF文件加壳要求ELF文件必须有_init导出函数，否则会报"UnknownExecutableFormatException"错误，问题定位到UPX源码的p_lx_elf.cpp文件的canPack()函数中：
- if (/*jni_onload_sym ||*/ elf_find_dynamic(Elf32_Dyn::DT_INIT)) {
- ......
也就是说Dynamic段中必须有类型为DT_INIT的字段，它指向ELF文件初始化函数在文件中的偏移。一般的so都不会有这个函数，要加上很简单，只要在你的代码中加入下面代码：
- #ifdef __cplusplus
- extern "C" {
- #endif
- void _init(void){}
- #ifdef __cplusplus
- }
- #endif
下面内容部分摘录自：http://www.cnblogs.com/fishou/p/4202061.html
5、相关问题总结
5.1、编译UPX出现“cannot find -lz”错误。
分析：原因是链接器LD没有找到编译出来的zlib库libz.so或libz.a。
解决方法：将libz.so或libz.a拷贝到系统默认的动态链接库路径下，比如/usr/lib,/usr/lib64 等。
5.2、编译UPX出现“CantPackException: DT_TEXTREL found; re-compile with -fPIC”错误。
分析：这是早期NDK版本的BUG。
解决方案：使用NDK9或以上的版本
5.3、编译UPX出现“NotCompressibleException”错误。
分析：UPX对被加壳的二进制文件有最小限制，太小的文件将无法被加壳。
解决方案：在native代码中定义足够大的数据变量，使得编译出来的二进制文件容易达 到UPX的要求（参考《加固步骤》之《修改native代码》章节）。
5.4、编译UPX出现“UnknownExecutableFormatException”错误。
分析：被加壳的二进制文件必须存在init段，否则UPX将无法脱壳还原原始代码。
解决方案：在native代码中定义_init()方法，需要注意C和C++的区别（参考《加固步 骤》之《修改native代码》章节）。
备注：查看二进制文件是否存在init段的命令：readelf –dynamic xxx.so，如下图：
5.5、使用UPX加壳的SO，在eclipse中启动Android程序时出现”Fatal signal…”错误，如图：
分析：此错误是因为UPX解析某些特殊字符处理不当导致的，该BUG已经有人提交UPX 官方解决，但是当前官方正式发布的正式版本（V3.91）并没有fix该问题，而是在未正 式发布的V3.92才解决了该问题，因此本文档使用源代码版本为V3.92而非V3.91。
解决方案：下载使用V3.92源码，下载入口请参考《创建加固环境》章节。
5.6、为何删除UPX源码中的软件信息，以及如何定位查找这些信息。
分析：UPX对文件进行加壳时会把这些信息写入壳内，通过静态反汇编可查看到这些壳信息，进而寻找对应的脱壳机进行脱壳，使得攻击难度降低。
解决方案：在UPX源码中删除这些信息，并重新编译，步骤如下：
5.6.1、使用原始版本对文件进行加壳。
5.5.2、使用IDA反汇编加壳文件，在反汇编文件的上下文中查找UPX壳特征字符串， 如下图所示：
5.5.3、在UPX源码中查找这些特征字符串（建议使用Search and Replace），并一一删除， 如下图：
5.5.4、重新编译UPX（参考“创建加固环境”章节）
UPX对Android上ELF加壳使用过程中的若干问题总结相关推荐
- android登陆加载加载_如何在Android上侧面加载应用
android登陆加载加载 Just because an app isn't available from the Google Play Store doesn't mean it's not a ...
- 计算机加电启动操作引导自举,在计算机加电启动过程中，加电自检程序、 操作系统、引导程序、自举装入程序，这四个的执行顺序为...
在计算机加电启动过程中四个程序的执行顺序应该为: 1.加电自检程序: 2.自举装入程序: 3.引导程序: 4.操作系统. 复位启动: "复位"是用硬件控制的方式对CPU进行复位操作 ...
- 开机启动加载驱动过程中调用PostMessage函数出错
今天在WINCE5.0+S3C2440系统调试检测出租车是否载客的驱动的时候遇到这样的问题: 发现在开机启动加载驱动过程中调用PostMessage函数时会导致调用的线程崩溃,比如如果下面的线程在创建 ...
- android音频系统(7)：通话过程中的音频输出设备切换
前言:由于通话比较特殊,Android对于通话过程中音频输出设备的切换做了特殊处理,它在上层也是通过切换音频播放状态来完成切换操作的,android用CallAudioState来封装通话过程中的音频 ...
- android的apk加壳工具对比
**市面上现在有许多的apk加壳或者叫加固工具,这些工具的作用和产生的目的都是为了能够防止apk被反编译,起到一定的保护作用.** 虽然现在有许多的加壳工具但是加密之后的效果有一点差异,对于十分变态的 ...
- Android之Apk加壳
基于ADT环境开发的的实现,请参考: Android中的Apk的加固(加壳)原理解析和实现 类加载和dex文件相关的内容,如:Android动态加载Dex机制解析 一.什么是加壳? 加壳是在二进制的 ...
- 【Android 逆向】加壳技术简介 ( 动态加载 | 第一代加壳技术 - DEX 整体加固 | 第二代加壳技术 - 函数抽取 | 第三代加壳技术 - VMP / Dex2C | 动态库加壳技术 )
文章目录 一.动态加载 二.第一代加壳技术 ( DEX 整体加固 ) 三.第二代加壳技术 ( 函数抽取 ) 四.第三代加壳技术 ( Java 函数 -> Native 函数 ) 五.so 动态库 ...
- 【Android 逆向】加壳的 Android 应用启动流程 | 使用反射替换 LoadedApk 中的类加载器流程
文章目录 一.加壳的 Android 应用启动流程 二.使用反射替换 LoadedApk 中的类加载器流程 一.加壳的 Android 应用启动流程 加壳的 Android 应用启动流程 : 加壳的 ...
- 【Android 逆向】加壳技术识别 ( 函数抽取 与 Native 化加壳的区分 | VMP 加壳与 Dex2C 加壳的区分 )
文章目录 一.加壳特征识别 1.函数抽取 与 Native 化加壳的区分 2.VMP 加壳与 Dex2C 加壳的区分 一.加壳特征识别 1.函数抽取 与 Native 化加壳的区分 函数抽取 与 Na ...
最新文章
- G.Eating Together(LIS,LDS)
- JDK版本不匹配...
- linux windows 域,linux加入windows域之完美解决方案
- ubuntu下安装、卸载软件命令
- const int和const int本质区别
- restTemplate设置访问超时
- 并发编程学习之JDK1.8的ConcurrentHashMap
- Android开发网上的一些重要知识点[经验分享]
- 早间简评：黄金亚盘快速下跌 1300关口岌岌可危？
- 啦啦啦啦啦啦啦啦啦啦啦啦
- 康奈尔rtems笔记（1）
- Android 9.0 蓝牙通讯录 BluetoothPbapClient
- Java 文字转拼音工具类
- 统计学、深度学习、机器学习、数据挖掘
- 人工智能之语音机器人
- 问题-fuxi job failed ,cased by:Invalid decimal format.
- MyEclipse2014全黑色主题
- 文件夹选择框 文件选择框
- greasemonkey_Firefox中Greasemonkey用户脚本的初学者指南
- 不使用机器学习的机器视觉_我关于使用机器学习进行体育博彩的发现使博彩公司总能胜出