无节操非程序猿

莫催稿,催稿也不交

[翻译] Android O 中的 seccomp 过滤器

在 Android 的设备中,强制执行 Android 安全模式的重任交由内核承担。由于安全团队已努力加强 Android 的用户空间,并隔离和削弱进程的权限。因此内核已成为更多安全攻击的焦点。系统调用是攻击者攻击内核的常用方式。所有 Android 软件都使用系统调用(简写为 syscall)与 Linux 内核通信。内核提供许多基于设备和 SOC 的系统调用,让用户空间的进程(包括应用程序)直接与内核交互。所有应用都依赖此机制,通过唯一的系统调用来检索访问对应的行为,例如打开文件或发送一条

NDK 线程的一些坑与解决

自从换了某个版本的 NDK 后,就一直坑不断,踩了几天之后,发现在线程部分坑已然变多,必须好好解决一下了首先讲一下线程的问题,目前建议将所有可能会耗时的函数都放进线程,原因是现在的 NDK 似乎可能好像也许会在意料不到的地方 ANR,比如以下代码:clsContext := env^^.FindClass(env, 'android/content/Context'); getServiceContet := env^^.Get

[翻译]使用 Soong 来进行 Android 模块的构建

Soong 是原基于 make 的构建系统的替代品。它使用 Android.bp 来取代 Android.mk,并使用类似于 JSON 的格式来描述一个模块的构建方案。Android.bp 文件格式Android.bp 的设计非常简单,没有条件判断或控制流语句。在 Go 语言中编写的构建逻辑没有任何复杂度。Android.bp 的语法和语义可能也类似于 Bazel BUILD 文件。模块模块在 Android.bp 文件中以一个模块类型开始,后面跟着一组属性,以名值对(name: value)表

NDK Mapping 发布啦

首先感谢一下医生,若是没有你催命般的催稿,还真就没有这篇了。作为催我的代价,请客可乐是没跑的了:)首先,给出章鱼猫地址:rarnu/ndkmappingNDK Mapping 的主要工作就是完成 class 从 JVM 层到 JNI 层的映射。通常情况下,当我们进行 JNI 开发时,无可避免的要进行类的传递操作,而 JNI 提供的 API 却让代码简单不起来,大量的容易出错的体力劳动也是这么来的。来看看以下的代码:DemoInc *ret = NULL; if&n

Xposed加载JNI库

在项目开发中,时常会用到 JNI 库,以提供一些特定的功能,而在 xposed 开发中,也会有这样的需求,然而,在 xposed 的条件下,要加载一个 so 可不是一件容易的事。首先的问题是跨进程,由于 xposed 程序在执行时,xposed 模块与主包并不在同一进程,因此无法直接使用以下代码对 JNI 库进行加载:init {     System.loadLibrary("xpjni") }如果这么做,那么只会得到一

Android NDK层发起 HTTP 请求的问题及解决

事件的起因不说了,总之是需要实现一个 NDK 层的网络请求。为了多端适用,还是选择了 CodeTyphon 作为跨平台方案。关于 CodeTyphon 此处不述,感兴趣的可以直接去其官网查看(传送门)。


CodeTyphon 自带的 fcl-web 库可以直接完成对于 HTTP 请求的支持,虽然我很想这么说... 在实际使用中,的确可以通过引入 fcl-web 来完成跨平台的网络请求,然而在 Android 端实际测试时,却发生了奇怪的错误。


比如说请求我自己的服务器 www.rarnu.com,会发生以下错误:\n\n

Error resolving host www.rarnu.com (-1)


而当我换用 IP 地址来请求时,却是可以成功的。


输入的域名是实际存在的,可以排除掉域名本身的问题。而使用 adb shell 连入设备,并使用 ping 命令访问该域名,也是正常的。那么问题可能就出在,找不到 nameserver。我们都知道,在 Linux 下,nameserver 由 resolv.conf 决定,这个文件通常保存在 /etc 下。于是看了一下,Android 里并没有这个文件,应该就是这个原因引起的了,因为读不到 resolv.conf 所以才导致了无法解释域名。接下来就是去找 Android 下,原本该是 resolv.conf 的东西保存在哪里。


不卖关子了,其实 Android 很早就把 resolv.conf 的内容改成了 key-value 的形式,采用 SystemProperties 进行存储,而其关键的 key 是 net.dns1 和 net.dns2。


尝试使用 adb 连接手机,并对以上两个 key 进行取值:

$ adb shell
$ getprop net.dns1
$ 208.67.222.222
$ getprop net.dns2
$ 208.67.220.220


我的手机上取出来的是 OpenDNS 的值,自己设置过。好了,既然已经知道了 nameserver 的所在,接下去就是修改代码以使程序识别和加载。


Android核心破解原理详解

玩 Android 时,我们经常会听到核心破解这个词,在部分第三方 ROM 里,也有一些作者会直接完成核心破解,以使 Android 拥有更大的可玩性。那么倒底什么是核心破解,它又对系统产生什么样的影响?首先让我们看一下核心破解后可以做什么:功能点破解前破解后应用降级只能由高版本应用覆盖低版本无视版本号随意覆盖覆盖安装签名不一致不能覆盖无视签名直接覆盖无签名安装不允许允许从这些功能点上也可以知道,这些限制的破解,对于使用破解版的软件是有极大的影响的,正常情况下,软件被破解后,无法签回原始签名,因

解决MIUI8的冻结反弹

看到这个标题我觉得某司的程序员又要紧张一下了,怎么好不容易搞出了个冻结反弹又被人搞了。恩,要搞的就是这种流氓行为。首先来看一下具体的现象,所谓的冻结反弹,就是当你使用 pm disable 使一个 APP 处于冻结状态后,重启手机,APP 自动解冻了。典型的例子就是 MIUI 内置的音乐、视频等。另外还有删除指定 APP 重启就卡 MIUI Logo 不能进系统的,这对于取了 root 想自己改改系统的人来说,简直不可忍。那么废话不多说,直接来看解决方案,可靠的解决方案有三种

实现 APK 保护时常见的坑和解决方案

对 APK 进行保护是我们经常需要做的事,而且似乎也是每个公司必备的技能了。在使用如 ProGuard,DexGuard 等常见的产品之余,也有很多公司自行研发了一些保护的方案,专门来针对自家产品做出保护,比如说我司也开发了专门防止二次打包的工具。


在开发这款产品,并用于实战的过程中,也发现了很多坑,下面一一细数过来,希望对同样也希望开发一款 APK 保护类产品的人们能有所启发。


去除 MIUI 的负一屏

首先声明,我并非米粉也并非米黑,只是个玩技术的。为什么要拿 MIUI 负一屏开刀呢,因为我不想看到广告,仅此而已。 可以先看一下负一屏长啥样,然后再决定是否要干掉它(MIUI 并没有提供关闭它的入口)。   好了,反正我个人是很不喜欢这种东东的,想个办法干掉它。在 MIUI 论坛上已经有人提出,root 后用老版本的 MiuiHome.apk 替换掉新的,这是一条不错的路,但是会体验不到 MIU

Powered By Z-BlogPHP 1.5.1 Zero

Copyright Rarnu 2017. All Rights Reserved.