没有反编译资源之前,AndroidManifest.xml和activity_main.xml这样的资源文件都是非明文的,无法阅读。
smali文件夹的目录结构和我们源码中src的目录结构是几乎一样的,主要的区别就是所有的java文件都变成了smali文件。smali文件其实也是真正的源代码,只不过它的语法和java完全不同, 它有点类似于汇编的语法,是Android虚拟机所使用的寄存器语言 。
使用smali语法,修改代码,就能重新编译自己的apk。但是apk还不能安全,因为还没签名。
因为无法获得原来正版的签名,可以使用Android Studio生成自己的签名,进行打包,生成自己的apk。
blog.csdn.net/guolin_blog…
android { buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } 复制代码
true
来开启混淆 true
来开启资源的压缩。 枚举类内部存在 values
方法,混淆后该方法会被重新命名,并抛出 NoSuchMethodException
。Android 系统默认的混淆规则中已经添加了对于枚举类的处理,我们无需再去做额外工作。
原因在于:代码混淆过程中,被反射使用的元素会被重命名,然而 反射依旧是按照先前的名称去寻找元素 ,所以会经常发生 NoSuchMethodException
和 NoSuchFiledException
问题。
实体类即我们常说的"数据类",当然经常伴随着 序列化 与 反序列化 操作。很多人也应该都想到了,混淆是将原本有特定含义的"元素"转变为无意义的名称,所以,经过混淆的"洗礼"之后,序列化之后的 value
对应的 key
已然变为没有意义的字段,这肯定是我们不希望的。
反序列化的过程创建对象从根本上来说还是借助于 反射 ,混淆之后 key
会被改变,所以也会违背我们预期的效果。
Android 中的四大组件同样不应该被混淆。原因在于:
manifest
中注册的类并不匹配,故而出错。 当 JNI 调用的 Java 方法被混淆后,方法名会变成无意义的名称,这就与 C++ 中原本的 Java 方法名不匹配,因而会无法找到所调用的方法。
郭霖: blog.csdn.net/guolin_blog…
juejin.im/post/5d1717…
此类配置应当妥善存放,不要在类中硬编码敏感信息,可以使用 JNI将敏感信息写到Native层 。
首先 不应当使用SharePreferences来存放敏感信息 ,sharedpreferces存储的xml文件数据可能被反编译拿到。存储一些配置信息时也要配置好访问权限,如私有的访问权限 MODE_PRIVATE(Activity.MODE_PRIVATE,/ /默认操作模式 ,代表该文件是私有数据,只能被应用本身访问,在该模式下,写入的内容会覆盖原文件的内容),避免配置信息被篡改。
3、SQLite数据库文件的安全性– 描述:敏感信息是否明文存储 – 检测:检测数据库里面的重要信息,比如账号密码之类的是否明文存储 – 建议:重要信息进行 加密存储
www.jianshu.com/p/79b30238b…
zhuanlan.zhihu.com/p/35100057
上面可以看到,https并不能阻挡攻击者分析请求接口并发起恶意请求攻击,为了增加攻击者分析请求的难度,通常可以采用两种方式:
使用签名。
数据加密。
www.jianshu.com/p/fe0206f8b…
www.jianshu.com/p/fe0206f8b…
zhuanlan.zhihu.com/p/34902225
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
无论是编译java代码生成的dex文件,还是编译C/C++代码生成的so文件,反编译成本都不是特别的高。
加壳直观理解就是给程序加一层壳,可以用来对原程序进行资源压缩、防调试、防注入、防反编译,也就是说通过一个壳把原来的程序保护了起来。
我们知道一个常规Android程序它的所有代码都在dex文件中,程序启动时要先把这个dex文件载入到内存中,所以如果要加壳的话,主要工作就是把 原dex文件加密 或者隐藏起来,放一个新的壳dex到apk中,程序启动时运行这个壳dex,然后这个壳dex在运行时再加载原dex,用一张图表示如下:
xposed框架这样的hook技术,类似于降维打击,可以绕过加固技术轻松获取到dex文件。目前的乐固、360等大厂加固都可以绕过。
Hook 又叫“钩子”,它可以在事件传送的过程中截获并监控事件的传输,将自身的代码与系统方法进行融入。这样当这些方法被调用时,也就可以执行我们自己的代码。
install
的时候需要 root
权限,但是运行时不需要 root
权限 通过替换 /system/bin/app_process 程序控制 Zygote 进程,使得 app_process 在启动过程中会加载 XposedBridge.jar 这个 Jar 包,从而完成对 Zygote 进程及其创建的 Dalvik 虚拟机的劫持。 Xposed 在开机的时候完成对所有的 Hook Function 的劫持,在原 Function 执行的前后加上自定义代码
Xposed
框架介绍以及原理 Xposed
是 Github
上 rovo89
大佬设计的一个针对 Android平台
的动态劫持项目,通过替换 /system/bin/app_process
程序控制 Zygote
进程,使得 app_process
在启动过程中会加载 XposedBridge.jar
这个 jar
包,从而完成对 Zygote
进程及其创建的 Dalvik虚拟机
的劫持。
因为 Xposed
工作原理是在 /system/bin
目录下替换文件,在 install
的时候需要 root
权限,但是运行时不需要 root
权限。
看到这里很多人会很懵,什么是 Zygote
?简单来说在 Android
系统中,应用程序进程都是由 Zygote
进程孵化出来的,而 Zygote
进程是由 Init
进程启动的。 Zygote
进程在启动时会创建一个 Dalvik
虚拟机实例,每当它孵化一个新的应用程序进程时,都会将这个 Dalvik
虚拟机实例复制到新的应用程序进程里面去,而一个应用程序进程被 Zygote
进程孵化出来的时候,不仅会获得 Zygote
进程中的 Dalvik
虚拟机实例拷贝,还会与 Zygote
一起共享 Java运行时
库。这也就是可以将 XposedBridge
这个 jar
包加载到每一个 Android
应用程序中的原因。 XposedBridge
有一个私有的 Native(JNI)
方法 hookMethodNative
,这个方法也在 app_process
中使用。这个函数提供一个方法对象利用 Java
的 Reflection
机制来对内置方法覆写。。。。等等这些都会借鉴各路大神的思路和分析,总而言之,就是从底层替换方法,可以让我们在不修改 APK
源码的情况下,通过自己编写的模块来影响程序运行的框架服务,实现类似于自动抢红包、微信消息自动回复等功能。 其实,从本质上来讲, Xposed
模块也是一个 Android
程序。但与普通程序不同的是,想要让写出的 Android
程序成为一个``Xposed 模块,要额外多完成以下四个硬性任务:
1、让手机上的xposed框架知道我们安装的这个程序是个xposed模块。 2、模块里要包含有xposed的API的jar包,以实现下一步的hook操作。 3、这个模块里面要有对目标程序进行hook操作的方法。 4、要让手机上的xposed框架知道,我们编写的xposed模块中,哪一个方法是实现hook操作的。 复制代码
www.jianshu.com/p/fe0206f8b…
加密主要有对称加密、非对称加密,不可逆加密。
AES主要是用在数据本身的加密,即使传输过程中被截取了,也是加密过后的数据。但AES的弊端的是,客户端加密的话,密钥肯定是储存在app中,如果app被成功破解了,数据也就被暴露了。所以只有app本身程序的安全也解决了,app才能相对安全。
因为RSA加密有个长度限制,这就导致了RSA加密不能用于所有的数据交互。但是可以用到一些 短数据 ,比如用户个人信息之类的,在交易中,一次订单的数据也不是很大等。