另一种黑科技保活方法
几个月前，我写了一篇Android 黑科技保活实现原理揭秘，当时我们提到，现在的进程保活基本上分为两类，一种是想尽办法提升进程的优先级，保证进程不会轻易被系统杀死；另一种是确保进程被杀死之后能通过各种方式复活。
Android 黑科技保活实现原理揭秘 中的进程永生术是第二种，它通过钻 Android 杀进程的空子实现了涅槃永生；不了解的同学可以参考一下 PoC。归根结底，所谓的黑科技就是利用系统漏洞。那么，既然我们可以利用漏洞逃过追杀，那何不更进一步，利用系统漏洞提权？
实际上，在 Android 系统中，这样的漏洞广泛地存在着。Google 会在每个月初公布其更新的安全漏洞，这些漏洞各种各样。通常情况下，更受人关注的是那些 RCE 或者 EoP 类型的漏洞，它们要么可以远程控制系统，要么可以直接获取操作系统最高权限（Root）。不过，这种类型的漏洞利用起来往往比较困难，要稳定地运行不是一件容易事，而且由于他们危害大，往往很快就会被修复。
太极的少阳模式实际上就是使用这种方法，通过利用 1 Day 漏洞（如水滴，CVE-2020-0423等）直接获取系统最高权限，然后进行注入和拦截，这种方式不需要解锁和刷机就能实现太极阳的完整功能。
但是，如果想要实现保活，可以大大降低这个要求：只需要提权到 system 就可以为所欲为了。当然，我们也不一定要提权，比如说想办法让系统帮忙启动一个服务，比如骗系统帮我们提升进程优先级都是可以的。
接下来，我们介绍一下最近公布的有关 Android 前台服务的漏洞。他们的编号分别是 CVE-2020-0108，CVE-2020-0313。
如果小伙伴们有印象的话，Android 上存在一个广为流传的灰色保活方法：创建两个 Service 来启动通知，最后可以创建一个没有通知栏的前台服务，从而提升进程的优先级。接下来要介绍的这个漏洞与此类似，实际上还有一个 CVE-2020-0313也是前台服务相关。。这块代码实在是写的稀烂，漏洞百出。好了回到正题，我们先介绍一下前台服务：
前台服务执行一些用户能注意到的操作。例如，音频应用会使用前台服务来播放音频曲目。前台服务必须显示通知。即使用户停止与应用的交互，前台服务仍会继续运行。
前台服务所在的进程优先级非常高，一般不会被系统轻易杀死；因此如果有条件创建一个前台服务，就可以实现保活。不过，Android 有一个很强的限制，那就是前台服务必须要显示一个通知；对那些既想要在后台偷偷地跑，又不想被人发现的 App 来说，这个限制实在是让人头大。有没有办法让系统既能启动一个前台服务，又不显示通知呢？
如果我们创建通知的时候，故意出错，系统会有什么反应？
以下是我们创建前台服务的样例代码：
String CHANNEL_ID = "demo_channel";
NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
NotificationChannel Channel = new NotificationChannel(CHANNEL_ID, getString(R.string.app_name), NotificationManager.IMPORTANCE_HIGH);
Channel.setLockscreenVisibility(Notification.VISIBILITY_PUBLIC); //设置锁屏可见 VISIBILITY_PUBLIC=可见
if (manager != null) {
manager.createNotificationChannel(Channel);
}
Notification notification = new Notification.Builder(this, CHANNEL_ID)
.setAutoCancel(false)
.setContentTitle(getString(R.string.app_name))
.setContentText("运行中...")
.setWhen(System.currentTimeMillis())
.setSmallIcon(R.mipmap.ic_launcher_round)
.setLargeIcon(BitmapFactory.decodeResource(getResources(), R.mipmap.ic_launcher))
.build();
startForeground(1, notification);可以看到，我们创建前台服务的时候需要创建一个 NotificationChannel，如果我随便搞一个channel 或者干脆传递一个错误的或者压根不存在的 channel 给系统会咋样？我们简单跟踪一下系统的前台服务启动流程，在真正要创建通知的时候，是在 ServiceRecord.postNotification
try {
// 忽略..
if (nm.getNotificationChannel(localPackageName, appUid,
localForegroundNoti.getChannelId()) == null) {
int targetSdkVersion = Build.VERSION_CODES.O_MR1;
try {
final ApplicationInfo applicationInfo =
ams.mContext.getPackageManager().getApplicationInfoAsUser(
appInfo.packageName, 0, userId);
targetSdkVersion = applicationInfo.targetSdkVersion;
} catch (PackageManager.NameNotFoundException e) {
}
if (targetSdkVersion >= Build.VERSION_CODES.O_MR1) {
throw new RuntimeException(
"invalid channel for service notification: "
+ foregroundNoti);
}
}
// 忽略..
} catch (RuntimeException e) {
ams.setServiceForeground(name, ServiceRecord.this,
0, null, 0);
ams.crashApplication(appUid, appPid, localPackageName, -1,
"Bad notification for startForeground: " + e);
}看到这里其实就知道，我们传递了一个不存在的 channel，系统getNotificationChannel会发现不对劲，然后直接抛出一个异常invalid channel for service notification，捕获了异常之后，系统会调用 ams.crashApplication，我们看一下这个 ams.crashApplicaiton，一路跟踪，我们会发现代码调用到了这里：
void scheduleCrash(String message) {
// Checking killedbyAm should keep it from showing the crash dialog if the process
// was already dead for a good / normal reason.
if (!killedByAm) {
if (thread != null) {
if (pid == Process.myPid()) {
Slog.w(TAG, "scheduleCrash: trying to crash system process!");
return;
}
long ident = Binder.clearCallingIdentity();
try {
thread.scheduleCrash(message);
} catch (RemoteException e) {
// If it's already dead our work is done. If it's wedged just kill it.
// We won't get the crash dialog or the error reporting.
kill("scheduleCrash for '" + message + "' failed", true);
} finally {
Binder.restoreCallingIdentity(ident);
}
}
}
}哇，我们的系统真的是太温柔了！系统要让咱们进程去死的时候，不是直接提刀把咱砍了，而是赐了一杯毒酒就不管了：爱卿，你自己去死吧。不过，要是咱们进程不听话，把毒就扔了不就逍遥法外了吗！！
这个过程就是 CVE-2020-0108 的原理：创建一个前台服务，但是在他需要前台通知的时候给它一个子虚乌有的 channel，这样前台服务实际上创建好了，不过系统发现不对劲会让咱去死，咱厚着脸皮不死，最终就拥有了一个没有通知的前台服务。
你以为到这就完了？No！这个前台服务代码 Bug 一堆，咱还有个别的姿势同样能达到目的。
我们的总体思路是创建前台服务的时候，给它传递非法的参数让系统创建失败；上面我们给了它一个不合法的 channel，我们实际上还可以在别的地方动手脚：创建通知的时候是可以自定义布局的，如果我们给系统一个错误的布局会咋样？废话不多说我们直接跟踪代码，最终会到这里:
@Override
public void onNotificationError(int callingUid, int callingPid, String pkg, String tag, int id, int uid, int initialPid, String message, int userId) {
int uid, int initialPid, String message, int userId)
cancelNotification(callingUid, callingPid, pkg, tag, id, 0, 0, false, userId,
REASON_ERROR, null);
}这里就更搞笑了，通知创建失败了，系统就是单纯把通知取消了；后面服务该咋运行还是咋运行，系统压根就不管！
好了写到这里，有关前台服务的漏洞我们已经介绍完了。Google 已经在 8 月份的安全更新中修复了这个漏洞；简单看一下修复办法：
void scheduleAppCrashLocked(int uid, int initialPid, String packageName, int userId,- String message) {
- String message)
+ String message, boolean force) {
ProcessRecord proc = null;
// Figure out which process to kill. We don't trust that initialPid
@@ -374,6 +378,14 @@
}
proc.scheduleCrash(message);
+ if (force) {
+ // If the app is responsive, the scheduled crash will happen as expected
+ // and then the delayed summary kill will be a no-op.
+ final ProcessRecord p = proc;
+ mService.mHandler.postDelayed(
+ () -> killAppImmediateLocked(p, "forced", "killed for invalid state"),
+ 5000L);
+ }
}很好，系统现在在赐死之后，过了五秒钟回来看一下是不是真的死了，如果没有死了再自己动手砍一刀；这才是正常的赐死逻辑嘛，哈哈。
如果你是一个普通用户，很可能会觉得奇怪，使用这么广泛的 Android 系统竟然存在着这么多低级漏洞？是的，任何软件系统都不可能没有 BUG，这是没法避免的客观事实。我们唯一能做到的是：如果手机有安全性更新，一定要及时更新!!千万不要觉得旧系统不是挺好的嘛，越升级越难用；否则，如果这些公开的漏洞被人利用，后果不敢设想。另外， 千万不要选择那些万年不更新安全补丁的辣鸡手机！！