安卓逆向(1) | FightingTree

安全安卓逆向

安全

发布日期: 2020-08-26

文章字数: 1.3k

阅读时长: 4 分

阅读次数:

apk文件结构

assets文件夹(可选)：用来存放需要打包到android应用程序的静态资源文件，不需要通过appt编译的资源，没有索引
lib文件夹(可选)：存放当前app用得到的so文件，so文件是利用C/C++代码实现的
META-INF文件就是证书签名文件 (必须):
- MANIFEST.MF(摘要文件)：程序遍历APK包中的所有文件，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再使用Base64进行编码，如果APK包的文件被修改，在APK安装校验时，被修改的文件与MANIFSET.MF的校验信息不同，程序将无法正常安装
- CERT.SF(对摘要文件的签名文件)：对生成的MANIFEST.MF文件利用SHA1-RSA算法对开发者的私钥进行签名。在安装时只有公共密钥才能对其解密。解密之后将其与未加密的摘要信息进行比对，如果相符则文件没有被修改。修改文件之后要重新签名才能安装成功。
- INDEX.LIST APK索引文件目录
- CERT.RSA 保存公钥、加密算法等信息
res文件夹：存放应用的资源文件，包括图片资源、字符串资源、颜色资源、尺寸资源等，这个目录下的资源都会出现在资源清单文件R.java的索引中，需要通过appt编译的资源，在资源索引表中会生成索引
AndroidManifest.xml：Android项目的系统清单文件，Android应用的四大组件(Activity/Service/BroadcastReceiver/ContentProvide)均在此配置和声明
classes.dex:存放Java代码，应用程序的可执行文件，如果当前APP的方法数超过65535，就会进行分包处理(有多个dex文件)，如果没有超过，则只有一个dex文件。Android的所有代码都集中于此，可以通过反编译工具dex2jar转化为jar包，再通过jd-hgui查看其代码
resources.arsc:资源索引表，用来描述具有ID值的资源的配置信息。

APK打包流程

APK安装流程

涉及目录

system/app: 系统自带的应用程序，获得adb root权限才能删除
data/app: 用户程序安装的目录，安装时把apk文件复制到此目录
data/data: 存放应用程序的数据
data/dalvik-cache: 将apk中的dex文件安装到dalvik-cache目录下(dex文件是dalvik虚拟机的可执行文件，其大小约为原始apk文件大小的四分之一)

安装过程

复制APK安装包到data/app目录下，解压并扫描安装包
把dex文件(Dalvik字节码)保存到dalvik-cache目录
在data/data目录下创建对应的应用数据目录

卸载过程

删除安装过程中在上述三个目录下创建的文件及目录

分析ELF文件

操作系统 | 可执行文件 | 动态链接库

-|-|-

windows | PE文件 |.dll文件

linux | ELF可执行文件 | .so文件

Android操作系统(linux内核) | ELF/.dex文件 |

Android系统架构

android runtime包括安卓开发核心库和dalvik虚拟机

Android开发

利用android studio生成app项目，项目结构(https://www.jianshu.com/p/4962b4eeec63)

Android四大组件

活动(activity):用于表现功能
服务(service): 后台运行服务，不提供界面呈现
广播接收者(Broadcast Receive): 用于接收广播
内容提供者(Content Provider):支持多个应用中存储和读取数据相当于数据库

Activity 活动

activity代表一次app的运行过程

activity生命周期

对话框不调用onStop()

创建activity

活动必须继承activity类

public class MainActivity extends AppCompatActivity {
          protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);//绑定布局
}

服务Service

Android中的服务，与Activity不同，它是不能与用户交互，不能自己启动，运行在后台的程序，如果我们退出应用时，Service进程并没有结束，它仍然在后台运行，比如音乐播放，我们将音乐软件最小化，就可以一边听音乐一边干其他的事，如果不用Service，我们就听不到歌了。

Service生命周期

Service只继承了onCreate(),onStart(),onDestroy()三个方法，当我们第一次启动Service时，先后调用了onCreate(),onStart()两个方法，当停止Service时，则执行onDestroy()方法，如果Service已经启动，当我们再次启动Service时，不会执行onCreate()方法，而是执行onStart()方法。

startService启动Service的生命周期

执行startService时，Service会经历onCrteate()->onStartCommand。当执行stopService时，直接调用onDestroy方法，调用者如果没有stopService，Service会一直在后台运行，下次调用者再起来仍然可以stopService。

bindService启动Service的生命周期

执行bindService时，Service会经历onCreate->onBind，这个时候调用者和Service绑定在一起。调用者调用unbindService()方法或者调用者Context不存在了，Service就会调用onUnbind->onDestroy。这里的绑定在一起就是说两者共存亡了。