Reconstructing the FireOS file system

Jonathan Levin,, 03/10/2018

Update: (Sep 6th, 2018): Integrated extraction code into ImgTool 0.7 so you can now expand all system.transfer.list files with stl=path_to_system_transfer_list, as I've seen this on other MTK (MediaTek) firmware. So it's an MTK thing, not an Android Thing

I couldn't resist getting myself another Kindle on Amazon so I could research how far their "FireOS" has evolved. The device came with 5.6.0 installed, and it provides ADB (using the standard Developer Options trick of tapping multiple times on build info), but no public root exists for it (yet). It does strike me as rootable, but part of the process requires reversing Amazon's custom binaries (and there are many of those). Problem - SELinux contexts restrict access to a lot of those. What to do?

Fortunately, there are already posted links to the FireOS filesystem images on XDA-Developers. Grabbing the 5.6.0 filesystem update, I decided to take a look at what it looks like . The file, a ".bin" is actually a zip, and is easily extractable:

morpheus@Zephyr (~/Downloads/kindle) % unzip ../update-kindle-       
Archive:  ../update-kindle-
signed by SignApk
 extracting: system.patch.dat        
  inflating: META-INF/com/amazon/android/check-binary  
  inflating: META-INF/com/amazon/android/target.blocklist  
  inflating: META-INF/com/amazon/android/  
  inflating: META-INF/com/amazon/android/target.system.devicepath  
  inflating: META-INF/com/amazon/android/  
  inflating: META-INF/com/amazon/android/  
  inflating: META-INF/com/android/metadata  
  inflating: META-INF/com/google/android/update-binary  
  inflating: META-INF/com/google/android/updater-script  
  inflating: boot.img                
  inflating: file_contexts           
  inflating: images/lk.bin           
  inflating: images/preloader.bin    
  inflating: images/preloader.hdr0   
  inflating: images/preloader.hdr1   
  inflating: images/tz.img           
  inflating: ota.prop                
  inflating: system.transfer.list    
  inflating: system/build.prop       
  inflating: META-INF/com/android/otacert  
  inflating: META-INF/MANIFEST.MF    
  inflating: META-INF/CERT.SF        
  inflating: META-INF/CERT.RSA  

The interesting part is, of course, the /system partition, which looks promising:

morpheus@Zephyr (~/Downloads/kindle) % file Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)

Moving over to a Linux and trying to mount it, however, we get errors:

[root@simulacrum hgfs]# mount -o loop /mnt/hgfs/Android/ /mnt1
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[root@simulacrum hgfs]# dmesg
[17784.635418] EXT4-fs (loop1): bad geometry: block count 413255 exceeds size of device (316916 blocks)

So this is obviously a sparse image of some type, since its size is smaller than the actual filesystem size. Simple math reveals the blocksize to be 1,298,087,936 / 316916 = 4,096. That means the actual image file, if extracted, should be 1,692,692,480. Trying my standard image extraction tool (imgtool), however, lamentably reports it's not a known sparse image. So it's a different format.

Rummaging around in the extracted files, however, we find some clues. Specifically, system.transfer.list:

morpheus@Zephyr (~/Downloads/kindle) % cat system.transfer.list
erase 2,0,413255
new 56,0,32767,32768,32770,32873,32875,33372,65535,65536,65538,66035,98303,98304,98306,98409,98411,98908,131071,131072,131074,131571,163839,163840,163842,163945,163947,164444,196607,196608,196610,197107,229302,229376,229378,229481,229483,229980,262143,262144,262146,262643,269673,294912,294914,295017,295019,295516,327679,327680,327682,360448,360450,393216,393218,393715,413254