作者归档：hhjack

Android系统下的SUID标记

发表于由
回复

Android内核基于linux内核开发，但一些安全访问限制有所不同。

如果是Linux系统，可执行文件设置了suid标记，则该程序运行时可以拥有创建者的euid，比如自己编写的一个idpie程序

$ ls -l /system/bin/idpie
-rwsr-xr-x root	shell	651379 2013-10-30 15:21 idpie

这个程序运行时会显示自己的uid和euid，然后尝试利用setuid，seteuid等提权，再输出提权后的uid和euid

$ idpie
uid:2000,euid:0
uid:0,euid:0

目前来看，Android和Linux的情况相同，但Android系统下如果将这个程序放到/data/local/tmp目录执行，执行结果：

$ /data/local/tmp/idpie
uid:2000,euid:2000

结论是：Android下，suid位并不是程序权限提升的唯一因素，程序所在目录也会限制，虽然没有全面测试，但至少/system/bin目录下的suid标记可以生效，/data/local/tmp目录下则不行

Update:

参考Ron的研究

suid程序不能放在nosuid挂载点的文件夹，否则无法获取相应的权限

$ cat /proc/mounts | grep nosuid 可以获取mount挂载文件夹到底支不支持suid

显然 /data 和 /cache 都不行

给我一杯忘情水

发表于由
2

一个人的时候，却难再享受 独自 带来的乐趣。

弹琴，偏偏练的源自我推荐的那段搭配四手，一双玩魔术，一双演奏。你从虫虫网下载了曲谱，练习这个曲目，我就研究那魔术怎么变。

那一段，远在天边近在眼前。而今，不远处却隔着贯穿地幔的裂痕。

听歌，韩国风的曲目都是AIR里的收藏。男女共学~哎，也是打你那儿来。站起来再跟着跳一会儿，却发现最初也是你鼓动我跟MV学舞，大半段学罢却没能跳给你看。

“你也擅长跳吗？不，我善诱”

黑白颠倒，却寻求着日月更替之际的执手。同一地平线，却背向疾走，木然回首。

做饭，柜子里的半包米线居然还没吃完，拿起来几根，想想又放下，吃完是不是就什么都不剩了。和写满韩语的类酱油瓶一样，都是五道口的韩国店出口。

几次我也许路过，但从未曾见过这个神秘的地方，也猜不出这个瓶子里面到底装的是什么。只是，它看起来很像酱油。我以为我爱吃酱油。

…

越是不去想，越是长嗟。尤其安静得只剩下我的思绪。去恨，去抵消习惯成自然的喜欢。可是，oh my，一觉醒来，脑袋里居然浮现txstc的字符串。不怪，银行，邮箱，QQ，迅雷，衣食住行的口令都脱不了干系。”给自己留个退路”，曾我以为是耸人听闻，真是用心没用脑。

毒瘾烟瘾戒得掉吗？换作是十几年养成的习惯呢？

晚上还赶着写项目申请，听着音乐，间歇浏览网页，总是地三鲜–老三样，从前烙下的毛病，不管干什么，脑袋里都反复念着一个名字。

我以为要戒的只是一个习惯，结果却是一个人静下来生活每时每刻的全部。

病情反复，康复光芒闪耀，假象假象，只是回光返照。

喜欢，喜欢了整整一个曾经。只是，何时我才能过完曾经。

gdb on Android

发表于由
1

临时需要分析一下android下一个so库的崩溃原因，因此需要一个调试环境。经典的方法是用NDK提供的环境实现，当然如果是做jni开发调试的话这个方法无可厚非，无可替代。但如果仅仅是对某个二进制的崩溃迹象进行轻量级分析的话，搞一套NDK就太劳民伤财了。原理上就是Android的gdbserver连接PC端gdb即可，折腾了一大圈，总算找到了编译好的binary，点击下载

Android端：

gdbserver :9999 yourprogram

PC端：

adb forward tcp:9990 tcp:9999

arm-linux-androideabi-gdb

(gdb) target remote:9999

Shake it baby~~

Android模拟器重启后不还原

发表于由
回复

Android自带的模拟器每次开启都会还原/system等文件系统解决方案很粗暴，但绝对有效~在sdk的目录下找到/sdk/platforms/android-X (比如我的虚拟机基于android 2.1，X取值为7) 这个目录下面的system.img和ramdisk.img就是模拟器每次启动时加载的文件系统了。只要解压他们，按意愿修改再打包，替换原有的文件就OK了


system.img
需要用到mkyaffs2image.exe和unyaffs.exe，用于打包和解包，需要在cygwin环境下使用，可以在这里下载


ramdisk.img
这个稍微麻烦一些，同样我是在cygwin下进行的操作
将ramdisk.img复制到/tmp目录，重命名为ramdisk.img.gz

gunzip ramdisk.img.gz
mkdir ramdisk
cd ramdisk
cpio -i -F ../ramdisk.img

然后开始你想要进行的修改吧，修改完事儿后

cpio -i -t -F ../ramdisk.img > list
cpio -o -H newc -O temp.img > list
gzip -c temp.img < ../ramdisk.img

这样就在/tmp目录下面生成了打包好的ramdisk.img了，替换回去即可

netcat for windows

发表于由
回复

用公司的新电脑调试一个远程的exploit，需要用到nc (netcat)。以前每次都是随便上网搜索一个版本，这次打算亲自编译一下。不过原始的代码仅考虑了Linux环境，windows没办法直接产生exe，首先想到的是使用cygwin来解决这个矛盾。但安装了包含gcc，make的环境的cygwin以后，编译仍旧失败，提示是某个源码用到的结构体缺东西。后来发现在讨论区有人给出了patch修正这个问题，修复后只要

./configure && make

netcat.exe就在源码的src目录产生了。缺点是这个netcat.exe需要cygwin三个动态链接库的支持(cygiconv-2.dll + cygintl-8.dll + cygwin1.dll)，所以编译好的netcat如果需要使用就得背着这仨dll。另外一个option是找一个被人修改过，专用于windows的netcat。Rootsecure的源码直接放在VC 6.0新建的工程下面就可以编译，但需要在主文件增加

#pragma comment(lib,”ws2_32.lib”)

否则编译失败

附件里面是两种方案的源代码和编译好的可执行文件

反编译doswf加密的Flash

发表于由
1

使用诸如Sothink SWF Decompiler等软件可以很容易反编译不加保护的Flash程序。如果Flash内使用了秘密的网络通信或引入了一段漏洞利用代码，编写者不会希望自己的劳动成果被轻易获取的。

doswf用于给Flash程序加壳，混淆变量、函数和类名，增加逆向的难度。最近拿到了一份使用Flash编写的exploit，想要分析当中触发代码，但Flash已经使用doswf做了处理，直接反编译查看代码行不通。

根据近一段时间的分析，doswf在加密Flash时做了以下三个工作：

  1. 在原始的Flash程序中加入花指令，混淆变量函数类名
  2. 使用ByteArray的压缩算法压缩原始Flash，并针对压缩后数组做逐字节的加密处理，并将加密后的ByteArray附到doswf生成的一个Flash程序中，doswf的Flash程序会动态解码释放原始Flash
  3. 在doswf生成的Flash程序中加入花指令，混淆变量函数类名

花指令主要用于对抗反编译引擎。

Flash中的ActionScript源码被编译成字节码，类似于C语言代码被编译成机器码。对于C语言编写的可执行程序，由于汇编指令长度可变，通过在机器码中加入花指令（je jne 的组合等）可以造成反汇编引擎错误的解释机器码。

对于Flash编译的字节码，由于指令长度固定为一个字节，无法通过加入花指令实现字节码级别的解析错误，但反编译引擎在尝试将包含花指令的字节码转化为ActionScript源码时会发生错乱，导致Sothink SWF Decompiler无法正常工作（程序停止响应）。

混淆变量函数和类型名是一种不可逆的过程，doswf直接修改了Flash的常数表，用一些特殊符号替代用户自定义的名称。不过名称的混淆对分析代码影响有限，毕竟ActionScript的运行时类、成员函数和成员变量的调用仍然保持了原有名字。

压缩与加密Flash虽然很靠静态处理很棘手，但考虑到Flash最后一定会被动态解码加载到内存中，处理它可以靠动态内存抓取。

综合上述的特性，下面通过实际的例子说明如何得到原始Flash的反编译结果。

其实整个问题的关键就是针对1和3中提到的花指令的去除，而且对于3和2，除非你对doswf的加解密算法感兴趣，不然使用动态抓取就很容易绕过了。

我使用debug版的flashplayer加载执行目标Flash程序，相比使用浏览器，干扰更少，内存更小，抓取速度和准确度都会快很多。在内存中搜索FWS和CWS（Flash的文件头部的magic word）字样可以找到疑似的Flash程序，根据Flash文件格式中标识长度的字段能够从内存中将它直接Dump出来。实现类似功能的有很多类似软件，比如SwfReader.jar。Dump结果可能有二三十个，文件过小过大都能迅速排除，再使用swfretools格式解析器观察每个SWF文件，如果解析正确，并且包含DoABC（Flash程序的代码段），则予以保留。

通过动态抓取可以得到加花后的原始Flash程序。我分析的这个由doswf处理的Flash程序并没有使用过于复杂多样的加花指令，仅是把

原始代码A

原始代码B

转化为

原始代码A

jmp [OFFSET]

一些奇怪的字节码

label: [OFFSET]

原始代码B

每隔几十行字节码就会出现一次这种插入，也正是它们导致Sothink Decompiler崩溃。

去掉它们的算法也很基本，对代码段中的所有ActionScript方法进行扫描，将原始代码A和B之间的字节码全部使用空指令代替（0x02）。我写了个一个Python脚本完成这个工作，使用时需要修改Python代码中的两个偏移值，指向method_bodies的开始和结尾。

处理后的Flash文件就可以用Sothink反编译了。上述方法不见得universal，也许只是我遇到的一个特殊情况，doswf如果引入多种花指令，去花更为繁琐。或者新版本的Sothink如果已经更为强大，能够自行避开花指令，分析Flash也就不需要这么折腾了。

Android内核源码下载

发表于由
回复

今天下午抽了会儿疯把电脑清理了一遍，删掉了之前的android源码和内核源码。不过事后想想，万一想编译个驱动啥的还是得用，就又切到linux下面开始下载android内核源码（tegra）。

下载的教程按照官方的走就行，

git clone https://android.googlesource.com/kernel/tegra.git

可惜速度是要多慢有多慢，估计又是伟大的GFW在作祟，还好教育网内有些不是特敏感的内容用ipv6都能很好的绕过。

做法就是找到android.googlesource.com的ipv6地址，添加到/etc/hosts，然后用Network manger关闭ipv4出口，仅保留ipv6就可以高速免流量的下载源码了。

具体操作如下：

windows cmd下输入：

nslookup -qt=aaaa android.googlesource.com 2001:470:20::2

-qt用于指定查询类型（a，mx，ns…）

2001:470:20::2 是一个公益组织的dns服务器，仅返回被查域名的ipv6地址

比如我查询结果：2404:6800:4005:c00::52

切回linux，添加到/etc/hosts

2404:6800:4005:c00::52 android.googlesource.com

以此类推，将cache.pack.google.com，www.googlesource.com也添加到hosts中

然后使用Network manager关闭ipv4通道

再git clone就能以4-5M的速度下载内核源码了~ enjoy

Android kernel编译与刷机

发表于由
回复
RT3070的驱动在交叉编译时发现过程十分纠结，且网上说法不一，但辗转反侧折腾中发现了新的契机。原来Nexus 7的3.1.10内核本身就支持Ralink RT3070，只需要开启后编译产生新内核刷入Nexus 7就可以了，至于能不能让网卡支持混杂模式还有待测试。
编译内核比编译Android本身还容易，源码量小，对系统要求也比较低。参考[这里]下载编译内核有关代码
接下来为了编译内核，需要从Nexus 7下面把/proc/config.gz拽回来，并且解压得到.config放到kernel代码的根目录
cat config.gz | gunzip >.config
直接用git下载回来的Nexus 内核源码里面只有一个.git文件夹，需要使用git checkout才能将特定版本的源码解包释放。版本的选择可以参考下设备上的内核版本标注。比如我的为3.1.10-g009b6d1，就可以使用
git checkout 009b6d1
 
来释放对应版本的内核代码。然后 make menuconfig 可以调整内核模块，开启上述模块
make ARCH=arm CROSS_COMPILE=arm-eabi- menuconfig 
 
Networking support –> Wireless
[*] Generic IEEE 802.11 Networking Stack (mac80211) 
// 只有开启这个选项才能看到RT3070的驱动模块
device drivers –>
network device support ->
wireless lan –>
ralink driver support
 
最后make一下就产生了zImage在arch/arm/boot/下面
接下来需要把这个zImage打包成boot.img然后刷入Nexus 7中
打包方法可以参看[这里] ，所需的解压包工具从[这里]下载
 
我的做法是用Nexus 7 toolkit把系统的boot.img提取，然后用unpackbootimg解包，然后把我的zImage和ramdisk重新打包成成boot.img，就能够刷入系统了。刷入的方法就是用
fastboot flash boot boot.img
 
推荐在做一切前hack工作前，用Nexus-7-toolkit先备份好，fastboot，adb这类工具toolkit里面也提供了

Jelly Bean 编译

发表于由
回复

由于需要移植RT3070的驱动到Nexus 7，因此Android的源码是必须要有的。为了保证源码的正确性，就先把Android编译出来练练手吧。主要过程看[这里]

我是在LiveUSB模式的Backtrack 5 r3 (ubuntu 10.0.4) 下面进行的代码下载和编译，代码都放在了mount过来的Windows分区(NTFS)下面。

整体思路和参考链接相同，但由于是在mount过来的分区上搞，所以PATH环境变量的设置要有所区别。

再来就是需要sun-java6-jdk安装到位，具体方法：

###############

gedit /ect/apt/sources.list 

添加一行: deb http://us.archive.ubuntu.com/ubuntu/ hardy multiverse

apt-get update

apt-get install sun-java6-jdk 

############### 

另一点就是repo工具的下载，在不同城市测试了一下，原文链接已经被墙了。如果是教育网用ipv6就能绕过这个微墙。否则就在windows下先用代理下载好。repo实际上就是一段python代码。

使用repo下载全部JellyBean过程特别慢，花了有两三天吧，经常有错误产生，可能是dns导致的。如果你也遇到可以考虑修改host文件：

#########

gedit /etc/hosts

然后把 android.googlesource.com 和 googlesource.com 先用 nslookup 查好ip地址添加进来。

#########

这样可以减少代码下载中的DNS请求数量

至于编译的话只要按照参考链接的步骤来就没什么问题。虽然在这个过程中遇到了很多错误，但后来发现归根结底都是系统配置不够导致的。下面几点是容易被忽略的, 但却是编译过程所必须的~

需要64位的主机配64位的操作系统来进行编译

增加swap分区，Backtrack 默认不带，增加方法：

mount 一个windows分区过来，最好和代码存放的分区不同，然后增加一个swap文件就可以了，比如windows分区mount到了/media/D

##########

dd if=/dev/zero of=/media/D/swapfile bs=1024 count=4096k   #这样就增加了一个4G的swap文件

mkswap /media/D/swapfile #格式化这个文件

swapon /media/D/swapfile #开启swap

swapon -S #用于查看swap是否已经被正确开启

##########

我的电脑是intel i7 8核的，内存4G 但为了保证编译过程中不至于卡死，使用了 make -j4 命令进行编译 (只用4个核免得系统太忙碌)，如此这般，system.img就会被编译出来了

NFC Day One

发表于由
1

最近大采购啊，买了Nexus 7，OTG线，ACR122U，两张M1卡，一张特种卡。

目标：

  • Nexus 7+OTG+RT3070 跑 airodump，需要交叉编译驱动，需要在手机上构建debian或ubuntu环境
  • Nexus 7+NFC实现Mifare卡读取和写入，已经使用NFC_WAR和Mifare Scanner初步实现 
  • Backtrack+libnfc+nfc-tools (或RadioWar liveCD) 实现RFID卡口令获取，并结合Nexus 7和特种卡实现卡复制

这两天尝试了 Backtrack 下使用MFOC获取RFID卡口令和数据，环境搭建和相关驱动安装在Backtrack Wiki 有参考，但实际过程有些小细节还需要一波三四折了一下

整体过程可以参考[HERE]

apt-get install flex libpcsclite-dev libusb-dev checkinstall
cd ~
wget http://www.acs.com.hk/drivers/eng/ ACR122U_driver_Lnx_Mac10.5_10.6_1.02_P.zip
unzip -d acr122u ACR122U_driver_Lnx_Mac10.5_10.6_1.02_P.zip
cd acr122u
tar -jxvf acsccid-1.0.2.tar.bz2
cd acsccid-1.0.2
./configure
make
checkinstall -D -y –install
cd ~
apt-get install -y debhelper libtool && wget http://libnfc.googlecode.com/files/libnfc-1.4.2.tar.gz
tar xfvz libnfc-1.4.2.tar.gz &&cd libnfc-1.4.2
svn checkout http://libnfc.googlecode.com/svn/tags/libnfc-1.4.2/debian
dpkg-buildpackage -rfakeroot
dpkg -i ../libnfc*.deb
cd ~
wget http://nfc-tools.googlecode.com/files/mfoc-0.10.2.tar.gz && tar -xvzf mfoc-0.10.2.tar.gz
cd mfoc-0.10.2
autoreconf -vis
./configure
make
checkinstall -D -y –install

在第二步之后（第二个cd~后面）libnfc装好了，就可以使用nfc-list查看设备信息了，但执行后居然是 

root@bt:~/libnfc-1.4.2# nfc-list
nfc-list use libnfc 1.4.2 (r891)
No NFC device found.

这不是说没识别我的ACR122U吗~果然读卡器灯也不亮，归根结底是因为pcscd没有运行，虽然这是个啥现在还没搞清楚，但看来应该是某种硬件驱动层的wrapper。另开一个窗口执行pcscd -f 再回来执行nfc-list，

root@bt:~/libnfc-1.4.2# nfc-list
nfc-list use libnfc 1.4.2 (r891)
nfc-list: ERROR: No ACR122 firmware received, Error: 80100016
nfc-list: ERROR: Unable to connect to NFC device.

看来还是不太正常，深思熟虑过后，原来是还没有放卡片，再来nfc-list

root@bt:~/libnfc-1.4.2# nfc-list
nfc-list use libnfc 1.4.2 (r891)
Connected to NFC device: ACS ACR122U 00 00 / ACR122U210 – PN532 v1.6 (0x07)
1 ISO14443A passive target(s) was found:
ATQA (SENS_RES): 00  04 
UID (NFCID1): fe  05  0f  0f 
SAK (SEL_RES): 08 

总算出结果了，然后完成第三步安装好mfoc等nfc-tools套件

执行mfoc，却出现如下信息

root@bt:~/mfoc-0.10.2# mfoc -O dump
nfc_initiator_select_passive_target: Success

查了半天，好像是libnfc的bug，Backtrack Wiki里面提到的libnfc-1.4.2已经不是最新版本了，至少1.5.0已经出来了，所以重启后（Live CD模式），重新执行上述命令，但把第二步的所有1.4.2换成1.5.0，

cd ~
apt-get install -y debhelper libtool && wget http://libnfc.googlecode.com/files/libnfc-1.5.0.tar.gz
tar xfvz libnfc-1.5.0.tar.gz &&cd libnfc-1.5.0
svn checkout http://libnfc.googlecode.com/svn/tags/libnfc-1.5.0/debian
dpkg-buildpackage -rfakeroot
dpkg -i ../libnfc*.deb

mfoc就也工作了~

没有什么新东西，只有新问题~后续工作等到十一回家慢慢玩吧~折腾他们太操心了