Reproduction of Joying boot images

[lbdroid]

Joying uses non-standard boot and recovery images.
The 6.0 boot.img appears to be a lot "closer" to standard than previously, but still off.

Utilities;
unmkbootimg: https://forum.xda-developers.com/showthread.php?t=1877807
mkbootimg: https://android.googlesource.com/platform/system/core/+/android-7.1.2_r11/mkbootimg/mkbootimg

The 6.0 boot.img is pretty easy to deal with.
unmkbootimg boot.img spits out this;

unmkbootimg version 1.2 - Mikael Q Kuisma <kuisma@ping.se>
Kernel size 8388608
Kernel address 0x2600000
Ramdisk size 5400125
Ramdisk address 0x400000
Secondary size 0
Secondary address 0x2400010
Kernel tags address 0x100
Flash page size 4096
Board name is ""
Command line "idle=halt notsc androidboot.hardware=sofiaboard apic=sofia nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=disabled nolapic_timer x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=0 uvcvideo.en_autosuspend=0 console=ttyFIQ0,115200n8 earlyprintk=xgold"

*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0x02600000
OFF_RAMDISK_ADDR is 0x00400000
OFF_SECOND_ADDR is 0x02400010
Please modify mkbootimg.c using the above values to build your image.
****************

Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
  mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x0 --cmdline 'idle=halt notsc androidboot.hardware=sofiaboard apic=sofia nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=disabled nolapic_timer x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=0 uvcvideo.en_autosuspend=0 console=ttyFIQ0,115200n8 earlyprintk=xgold' --pagesize 4096 -o new_boot.img
---------------

Nice thing is that it doesn't actually know what its talking about when it is telling you to modify bootimg.c. This is not needed in the newer mkbootimg, which is actually a python script.

The command to recompile is close to what is needed, you just need to add in the offsets.

--kernel_offset 0x02600000 --ramdisk_offset 0x00400000 --second_offset 0x02400010

The result is a new_boot.img that is byte for byte identical to the original.

$ md5sum *.img
3cb4ecb1cf9b3a2924e725fe1d91ccd3  boot.img
3cb4ecb1cf9b3a2924e725fe1d91ccd3  new_boot.img

[lbdroid]

The recovery is a bit more challenging.
If we do the exact same procedure, we end up with a file that is quite significantly different.

unmkbootimg recovery.img:

unmkbootimg version 1.2 - Mikael Q Kuisma <kuisma@ping.se>
Kernel size 8388608
Kernel address 0x2600000
Ramdisk size 3334559
Ramdisk address 0x500000
Secondary size 204249
Secondary address 0x2400010
Kernel tags address 0x100
Flash page size 4096
Board name is ""
Command line "idle=halt notsc androidboot.hardware=sofiaboard apic=sofia nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=disabled nolapic_timer x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=0 uvcvideo.en_autosuspend=0 console=ttyFIQ0,115200n8 earlyprintk=xgold"

*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0x02600000
OFF_RAMDISK_ADDR is 0x00500000
OFF_SECOND_ADDR is 0x02400010
Please modify mkbootimg.c using the above values to build your image.
****************

Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
Extracting second to file second.gz ...
All done.
---------------
To recompile this image, use:
  mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x0 --cmdline 'idle=halt notsc androidboot.hardware=sofiaboard apic=sofia nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=disabled nolapic_timer x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=0 uvcvideo.en_autosuspend=0 console=ttyFIQ0,115200n8 earlyprintk=xgold' --pagesize 4096 -o new_boot.img
---------------

And then make it back up:
(NOTE: The unmkbootimg command is too stupid to add in the --second parameter, so it completely forgets about adding that part in. Don't forget to add it!!!)

mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x0 --cmdline 'idle=halt notsc androidboot.hardware=sofiaboard apic=sofia nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=disabled nolapic_timer x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=0 uvcvideo.en_autosuspend=0 console=ttyFIQ0,115200n8 earlyprintk=xgold' --pagesize 4096 --kernel_offset 0x02600000 --ramdisk_offset 0x00500000 --second second.gz --second_offset 0x02400010 -o new_boot.img

But we don't even need md5sum to see that they are different;

$ ls -l *.img
-rw-rw-r--. 1 user group 11935744 May 12 10:27 new_boot.img
-rw-rw-r--. 1 user group 16777216 May 12 10:25 recovery.img

So, what is going on here?

Well, a quick visual scan of the two files shows that the starting parts are pretty similar, if not identical, so checking on that more precisely....

$ dd if=recovery.img bs=1 count=11935744 > rec_front.img
$ md5sum *.img
8d0cd8125f975c2edba343cd02e6e836  new_boot.img
8d0cd8125f975c2edba343cd02e6e836  recovery_front.img
715e08287db6c7605bb115e4112ad560  recovery.img

This means that we are doing good. We are able to at least fully reproduce the "first bit" of the recovery.img.

Now the thing is, we've actually cut off a big chunk of the end of the file. Everything from 0x00b62000 onwards. It looks like the end of the file is actually at roughly 0x00be4fff. The rest of it is just 00's padding.

So lets just cut the original recovery.img off there.

dd if=recovery.img bs=1 count=12472320 > recovery.img.truncated
dd if=recovery.img.truncated bs=1 skip=11935744 > extra_blob.bin

Note: 12472320 is 0x00be5000 in base-10.

$ cp new_boot.img new_boot_scratch.img
$ cat extra_blob.bin >> new_boot_scratch.img
$ md5sum recovery.img.truncated new_boot_scratch.img 
d4b3039edd182d0adcb226c1abddf226  recovery.img.truncated
d4b3039edd182d0adcb226c1abddf226  new_boot_scratch.img

So now at least we can reproduce it by appending this extra blob onto the end of the file.

[lbdroid]

Now that extra_blob.bin... just what the heck IS IT?

It appears to be divided into three distinct sections;

Start 0-0x5ff: has some stuff about mountainview california US and android@android.com. Sounds pretty googly. Is that the test key?

Middle 0x600-0x4ffff: No idea.

End 0x5000-end: Appears to be a DTB. Does that mean that the middle part is a kernel?

[lbdroid]

I think that the right way to modify the recovery ramdisk is this;

1. unmkbootimg
2. edit the initramfs.cpio.gz in the usual way
3. mkbootimg as;

mkbootimg --kernel zImage --ramdisk initramfs_new.cpio.gz --base 0x0 --cmdline 'idle=halt notsc androidboot.hardware=sofiaboard apic=sofia nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=disabled nolapic_timer x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=0 uvcvideo.en_autosuspend=0 console=ttyFIQ0,115200n8 earlyprintk=xgold' --pagesize 4096 --kernel_offset 0x02600000 --ramdisk_offset 0x00500000 --second second.gz --second_offset 0x02400010 -o new_boot.img

4. cat extra_blob.bin >> new_boot.img

[lbdroid]

Uploaded the extra blob here;
https://github.com/lbdroid/JoyingIntelStuff/blob/master/extra_blob.bin

[gtxaspec]

6.0 stock does not enumerate the UVC device. :(

[lbdroid]

Thanks for checking. I'll double down on repackaging the hand edited kernel.

…

On May 12, 2017 5:51 PM, "gtxent" ***@***.***> wrote: 6.0 stock does not enumerate the UVC device. :( — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADN0xlmSwuW5KHHGL4po_114mNqJbJDkks5r5NRzgaJpZM4NZWjI> .

[gtxaspec]

Sure, I'm stuck at work for the next few days, but I have the vehicle with me, as soon as you got it I will flash it.

[lbdroid]

You know, another option we may have is to build a 6.0 boot image with the 5.1 kernel...

…

On May 12, 2017 6:02:05 PM EDT, gtxent ***@***.***> wrote: Sure, I'm stuck at work for the next few days, but I have the vehicle with me, as soon as you got it I will flash it. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #2 (comment)

[gtxaspec]

Yeah, thats possible, if it will work with Android 6.0 . Otherwise, we can compile one, as long as we can repack, and TRY it...

[gtxaspec]

OK, the mkbootimg recovery.img WORKS flashed to unit. I will try to modify the cpio now and reflash.

[gtxaspec]

new firmware posted tonight, the crruptoff file has some new variables:

fixwifi
don
fapklogon

i believe don is "debug on"

[gtxaspec]

I was able to extract fwu_image.bin which is included inside of 5009_60.zip using:
https://github.com/InvisiBot/fwu-shredder

this file contains all the partition .bin INCLUDING mobilvisior files used by intel flash tools!

-rw-rw-r-- 1 aag aag 14320936 May 12 23:21 boot.bin
-rw-rw-r-- 1 aag aag 1019384 May 12 23:21 mobilevisor.bin
-rw-rw-r-- 1 aag aag 42902 May 12 23:21 mvconfig_smp.bin
-rw-rw-r-- 1 aag aag 114492 May 12 23:21 psi_flash.bin
-rw-rw-r-- 1 aag aag 11937064 May 12 23:21 recovery.bin
-rw-rw-r-- 1 aag aag 603144 May 12 23:21 secvm.bin
-rw-rw-r-- 1 aag aag 1020824 May 12 23:21 slb.bin
-rw-rw-r-- 1 aag aag 2666496 May 12 23:21 splash_img.bin
-rw-rw-r-- 1 aag aag 7168 May 12 23:21 ucode_patch.bin
-rw-rw-r-- 1 aag aag 131072 May 12 23:21 vrl.bin

it appears that this file is is written to partition id 122 ( as noted in updater-script )

package_extract_file("fwu_image.bin", "/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID122");
intel_install_firmware_update("fwu_image.bin", "/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID122");

THIS is how they update the recovery, which is what I was wondering how they did during 5.1.1 to 6.0.1 update.

Note that the recovery.bin included here DOES NOT include the device tree, the size of the recovery.bin is only 11.9M. (what mkbootimg spits out when you dont add the extra_blob!)

It appears that when this file is dumped into this partition, the mobilvisor will flash all the files contained!

stay tuned.

[lbdroid]

I'm not sure we need to worry too much about writing the fwu_image to the device. From the shredder page readme, it looks like those can just be fastboot (or dd'd) to the proper locations on the device for the same effect.

Maybe what we can do instead of trying to RE the intel_install_... command, we just incorporate fwu_shredder into recovery.

[gtxaspec]

This:
https://downloadcenter.intel.com/download/26840

has some very useful information about generating images and signing them, including dev keys. I'm still looking into everything.