Android下的permission和gid

Android是在linux基础上构建的,权限的管理即要依赖apk中的permission,也要考虑和linux的uid/gid的方式结合。虽然很多操作可以在java层完成,但诸如设备文件的访问,又要回归到传统的uid/gid管理模式,比如设备文件

net_bt_stack组对设备文件是可以操作的,如果查看/system/etc/permissions/platform.xml

可以看到,如果apk申请了android.permission.BLUETOOTH_STACK权限,它的进程将具备linux的uid/gid管理体系下的net_bt_stack组权限

运行该apk,然后查看/proc/pid/status,Groups中也直接阐明了这一点

但这并不意味着,直接su app_id得到的shell具备该gid。Android下的su并不是基于/etc/passwd等文件实现的完整权限切换,仅保留了uid的信息。不过Android提供的run-as可以完整切换权限,得到具备该gid的shell

Immunity Debugger设置JIT

Windows 7以后,Immunity Debugger毕竟不再更新了,很多人开始转用x64dbg了。但用习惯了,除非是x64代码,不然还是不想换呢。Immunity Debugger一直有个不大不小的问题,就是当其他应用crash时,它的即时调试器模式总是启动不起来。

如果直接查看注册表,会发现是程序当前路径获取失败;只要人为添加如下信息到注册表即可让Immunity Debugger成为JIT:

 

 

FlashPlayer针对dll劫持的缓解措施

不知道Adobe究竟是受什么启发,在FlashPlayer的23版本开始引入了针对dll劫持的缓解措施。

FlashPlayer 22的启动参数处理流程示意如下:

而23版本在GetCommandLineA前插入了新的缓解代码,如下所示:

插入的代码功能:FlashPlayer在运行的时候,会检测当前目录是否包含*.dll文件,如果包含,就拷贝自身到temp目录,然后以-relaunched参数启动。

如果以-relaunched启动后的FlashPlayer检测到目录仍然包含*.dll就会弹出错误对话框,然后终止运行。

所以包含dll时,查看进程管理器,看到的FlashPlayer都是这样的形式:

“C:\Users\admin\AppData\Local\Temp\{F0CF3F41-B0CC-44A3-B59F-EA1D57B9DF7C}\FlashPlayer.exe” -relaunched

osx下编译android内核

如果是在linux系统下编译android的内核,基本不会有什么大的问题,但osx就稍微顽皮一些。

以nexus 5的内核编译为例,首先下载编译内核用的arm-eabi-gcc工具:

然后下载内核源代码

之后切换代码到需要的branch

以上都是常规步骤,针对osx还有一些必须的改动:


增加两个头文件elf.h和features.h到内核源码的scripts/mod下面,头文件下载

修改scripts/mod/mk_elfconfig.c和scripts/mod/modpost.h两个文件,将<elf.h>改成 “elf.h”

将scripts/recordmcount.c中的<elf.h>修改为 “mod/elf.h”

修改kernel/timeconst.pl,将defined(@array)的修改为@array


最后再编译即可:

 

逆向ARM64内核zImage

主流的旗舰Android手机已经尽数升级到64位,相应的,内核镜像zImage也发生了改变。如果想要用IDA Pro逆向分析arm64的手机内核,特别是完成内核符号的加载,着实需要折腾一番功夫。

从/dev/block或ROM包中提取boot.img,然后用abootimg -x解开得到zImage

如果zImage是gzip压缩的,就gzip -d解压得到kernel

以上两部都是常规项目,下面重点是要从kernel中提取本应显示在/proc/kallsyms下的内核符号,这样IDA Pro加载分析时才更得心应手。参考Bits, Please!的文章中32位的kernel符号提取方法,可以很快想到64位的解决方案:

首先要知道内核加载时的虚拟地址,一种投机的方法是,手机开机后执行:

由于现在手机还没有开启KASLR,所以基地址基本上总是0xffffffc000080000,有了这个地址就可以从kernel中找到symbol table了。内核导出的前两个符号stext,_text等总是指向0xffffffc000080000,所以搜索连续的两个0xffffffc000080000就能找到symbol table。之后按照Bits, Please!的方法就可以导出所有符号了,唯一要注意的是32位到64位,地址长度变成了8字节,内存对齐也从0x10变成了0x100。修改原来的Python脚本,开发了一个arm64解析符号的脚本:

输出的符号会按照/proc/kallsyms打印出来,同时会写入当前目录syms文件。接下来就是让IDA Pro识别syms文件了,我的做法是针对每个符号尝试给特定地址重命名,如果失败就undefine以后再试一次,对于代码段的函数都重新makecode一次:

 

 

暴力破解Android锁屏口令

JellyBean开始,Android的锁屏口令以hash形式存放,口令通常是4位数字(对于多位复杂口令方法也是一样的),暴力破解完全可行

锁屏口令的hash存放在/data/system/password.key,形如

1136656D5C6718C1DEFC71B431B2CB5652A8AD550E20BDCF52B00002C8DF35C963B71298

共72个字符,包含Sha1和MD5两个hash,参考Android源码

前40位是Sha1,后32位是MD5,计算(口令+salt)得到hash

salt的存放位置为/data/system/locksettings.db,使用sqlite3打开数据库,输入

就得到形如3582477098377895419的salt值了,最后将其转化为小写的16进制64位整数31b783f0b0c95dfb

有了这些信息用就可以用hashcat跑了,用MD5部分(0E20BDCF52B00002C8DF35C963B71298)爆破的指令为

 

OSX下调试Flash插件

其实无论调试什么,都会发现lldb的功能朴实的让人心急如焚。比如Windows调试器基本都会自动记录上一次的断点信息,每次调试时根据模块位置重新下好端点。

lldb可能天生就是为源码调试准备的,一旦没有源码,根据模块名+偏移的下端点方式它是无论如何都不能识别。好在它提供了python接口,方便开发调试插件弥补自身的缺陷。

所以与其说lldb是个调试器,不说它是个SDK,只有基于它开发出来的图形调试器才具备实用性。

那就来看看一些在Windows调试时不值得一提的简单操作,在lldb下该如何达阵

 

附加Flash进程


用Safari打开指定页面后,执行以下脚本lldb就会附加到包含Flash的进程上了

 

搜索内存中的指定常数


由于没有查看memory layout的命令,只能借助vmmap,先找到比如malloc的内存区域,然后再逐一生成查找命令。以下命令用于从WebKit找到HeapSpray的特定字符:

 

在模块固定偏移下断点


这个听起来是最稀松平常的任务了,比如打算在Flash的0x78A4C0偏移处下一个断点,而且要在每次lldb附加后自动完成。首先要编写一个lldb的插件,完成Flash模块基地址的查找和断点地址的计算,最后下断点:

更多内容

OSX下调试WebKit

Safari的解析和渲染引擎WebKit是开源的项目,并提供了很多脚本方便调试。在OSX下分析一个漏洞还是头一回,用到的技巧大都取自WebKit官方的一篇JS引擎漏洞分析

 

准备环境


首先当然是要下载Webkit的源码,以前写过如何在Ubuntu环境里下载编译WebKit,当时只考虑了最新版本,所以直接从官网下载代码压缩包。

但如果是分析漏洞,一般要根据testcase的描述找到对应版本的WebKit,然后用svn和git下载指定版本的代码。

官方的建议的命令是

由于我查看的testcase信息来自于WebKit的Github镜像,所以用git下载的源码。

不过国内访问git的速度实在不怎么样,最后就用VPS从美国先git clone好整个源码树,然后压缩传回本地

根据testcases找到对应的branch编号以后,再切换过去

更多内容

编译avm

2013年时Adobe停止了对Tarmain项目的维护,不想2016年三月居然重新更新了代码,近几年AVM的变化终于又能借此一窥究竟了。

linux下编译avmplus是最容易的:

Windows下无论是用VS2010还是VS2015都无法顺利编译通过,基本上会遇到两类问题,一个是字符不识别,一个是函数未解析
1. 字符问题在Windows 10时已经不存在了,但Windows 7与到时候也非常容易解决,删掉ErrorConstant文件中非英语部分就OK了
2. 至于 unresolved symbol 问题,可以先查找到缺失类所属的文件,然后把它们加入到工程的对应目录也就OK了,这个错误按说真是很奇怪,怎么会漏掉文件没有加入到项目中呢

获取斗鱼直播视频的下载地址

斗鱼直播应该火了好一阵了,和每一个互联网新兴业务一样,人气激增到国家都专门为其制定管理政策了。对流行节拍有意而为之的后知后觉,让我近一两个月才关注了几个主播。女主播看脸蛋,也插科打诨来几个污段子,才美兼备的自是不多。男主播的话,就看他套路其他女主播的真人秀,或视频或夜店。

只是直播时间都太晚,看几次就觉得严重影响睡眠,能自动录播就好了。

网页里的播放器自然是用Flash开发的,P2P式的NetStream。如果找到主播房间号对应的NetStream传输地址就可以使用第三方软件去下载视频流了。虽然播放器的主程序是加密传输到本地后载入内存的,但毕竟Loader真正开始加载的时候,该解密的都解了。播放器外部代码还做了混淆,但主程序因为加密放下戒备,真Dump下来的话,可读性极高。

开源的FFDEC出现以后,SWF Decompiler和As3 Sorcerer都再没用过。直播开始后,FFDEC去Dump浏览器进程中的Flash文件,大小1.5M左右的就是解密后的播放器主程序。反编译可以看见代码本身包含调试信息,只要当前页面的URL中包含dydebug的字样,播放器就会调用浏览器的console.log输出不同阶段的中间结果,这当中就包含了NetStream流的地址,形如:

组合RtmpUrl和LiveID就得到了视频地址,直接粘贴到浏览器地址栏就下载视频到本地了。

正好新装了Visual Studio 2015,就写了个下载地址解析的工具,距离上一次使用C#写点什么已经四五年了。Anyway,webBrowser控件很方便,可以自动调用IE引擎打开附加dydebug的直播地址。由于console是浏览器自定义的调试模块,webBrowser作为一个控件需要自行实现一个console供Flash调用。其实也就是在页面加载完毕后,添加一段javascript,声明一个window.console.log,内部调用external.log就能传递消息调试信息给C#代码了。 更多内容