We have captured a robot from behind, while he dropped some cooling liquid into the bushes. We tried to interrogate the robot, but he still refuses to speak. Luckily we could extract files from the android’s communication module. Hopefully we get some information about the robots’ motives, before every information is swiped away…
Here is the challenge: http://link.to.image.tar.gz
The description isn’t that helpful, but it still hints to Android and some kind of forensic task.
The first thing to do is always having a brief look at the file itself but it looked unsuspicios like a simple compressed tar file.
1
tar xaf image.tar.gz
Surprise! It seems to be a complete android rootfs.
So it is some Huawei phone. Another thing to check is the phonenumber and some logs (if they exist).
Sadly the image is too old and we cannot get a 1:1 copy of the original.
But nice enough, the image was expanded Sept 12 and changes were done Sept 13, so we can get a list of all changed files.
90% of those are default files, but some are “different” and suspicious, as /data/backup/\*, /data/system/\* and /system/etc/wifi/wpa_supplicant.conf
One could also sqlitebrowse all those DBs but we are still at the beginning so let us have a look at those plain files.
/data/backup/ seems to contain random named files with sha1 hashes inside
/system/etc/wifi/wpa_supplicant.conf contains some random WiFi credentials
There was one odd thing about those hashes in /data/backup/ because they where duplicates.
1234
for f in `find data/backup/ -maxdepth 1 -type f`; do cat $f; echo; done|wc -l
30
for f in `find data/backup/ -maxdepth 1 -type f`; do cat $f; echo; done|sort|uniq|wc -l
7
Since I had no idea what those hashes might be good for, Google was my friend and even gave me the needed hint.
23a6e7c835cd75c3f17ecc4d1cd7d840b74095251 led me to Lock Pattern et Android.. and assuming that the other hashes where also gestures (hence the hint in the gesture.key file) I setup oclHashcat to brute the other hashes.
12345678910111213141516171819202122232425262728
./oclHashcat-plus64.bin -m 100 -a 3 --outfile-format=3 -o result hash.txt --hex-charset -1 000102030405060708 ?1?1?1?1?1?1?1?1?1 --force -i
oclHashcat-plus v0.15 by atom starting...
Hashes: 7 total, 1 unique salts, 7 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Workload: 128 loops, 80 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Redwood, 512MB, 650Mhz, 5MCUDevice #1: Kernel ./kernels/4098/m0100_a3.Redwood_1311.2_1311.2.kernel (434972 bytes)Device #1: Kernel ./kernels/4098/markov_le_plus_v4.Redwood_1311.2_1311.2.kernel (322112 bytes)Device #1: Kernel ./kernels/4098/bzero.Redwood_1311.2_1311.2.kernel (33868 bytes)Session.Name...: oclHashcat-plus
Status.........: Cracked
Input.Mode.....: Mask (?1?1?1?1?1?1?1?1?1)[9]Hash.Target....: File (hash.txt)Hash.Type......: SHA1
Time.Started...: Sat Oct 26 19:53:04 2013 (2 secs)Speed.GPU.#1...: 267.3 MH/s
Recovered......: 7/7 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 381890688/387420489 (98.57%)Rejected.......: 0/381890688 (0.00%)HWMon.GPU.#1...: 0% Util, 46c Temp, N/A Fan
Started: Sat Oct 26 19:53:04 2013
Stopped: Sat Oct 26 19:53:10 2013
The resulting patterns could be visually mapped to numbers:
We first ordered them by filename which resulted in \d67\d87\d87\d76\d78\d57\d76\d63\d79\d35\d95\d52\d75\d56\d67 which already looked like ASCII but made no sense (CWWLN9L?O#_4K8C), but when ordered by creation date the ASCII begins to make sense and results in the flag: kill_all_humans