[Miscellaneous Android Development] amrmo:
Thanks, no need for special tools yet.

Just download & unzip the default Asus firmware archive UL-P01M-JP-4.6.1.0-user.zip from the "Support..." website.

The standard Linux command 'file' recognizes the 'droidboot.img' file as a Linux kernel + 2 extra concatenated images:

$ file droidboot.img

droidboot.img: Android bootimg, kernel (0x10008000), ramdisk (0x11000000), second stage (0x10f00000), page size: 2048, cmdline (init=/init pci=noearly loglevel=0 vmalloc=384M androidboot.hard)

The ramdisks can be extracted with i.e. the perl script split_bootimg.pl from https://gist.github.com/jberkel/1087743

$ perl split_bootimg.pl droidboot.img

Page size: 2048 (0x00000800)

Kernel size: 5781904 (0x00583990)

Ramdisk size: 6716449 (0x00667c21)

Second size: 8192 (0x00002000)

Board name:

Command line: init=/init pci=noearly loglevel=0 vmalloc=384M androidboot.hardware=mofd_v1 console=logk0 watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789 snd_pcm.maximum_substreams=8 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0:on debug_locks=0 n_gsm.mux_base_conf="ttyACM0,0 ttyXMM0,1" bootboost=1 build_version=3 androidboot.selinux=permissive

Writing droidboot.img-kernel ... complete.

Writing droidboot.img-ramdisk.gz ... complete.

Writing droidboot.img-second.gz ... complete.

The 'first stage' droidboot.img ramdisk.gz is a compressed CPIO file, which can be extracted via i.e.:

$ zcat droidboot.img-ramdisk.gz | cpio -i

The program of interest within that image, which appears to be run when the device is rebooted into 'adb reboot-bootloader', is the file:

system/bin/droidboot

Without even disassembling it, a simple peek with the 'strings' command:

$ strings system/bin/droidboot | less

... allows to see various OEM commands, possible error messages and text fields.

Hope it helps! In principles, there may be two possible ways to gain full device control. One would be making a custom recovery image permanent, i.e. disabling its automatic overwriting in a (already working & bootable) custom de-bloated firmware, http://hckohwnotes.blogspot.jp/2016/02/de-bloating-customized-stock-rom-howto.html

Alternatively, I'd suspect a bootloader lock, if present, might be very similar to the ZenFone one. The official unlock app by Asus contains, inside i.e. the UnlockApp_ze551ml_20150723.apk file, a classes.dex archive which tries to contact the website: https://mdm.asus.com/DMServer/DeviceState

Some actual disassembly in this case could reveal which security token gets exchanged in the ZenFone case; and perhaps it could be replaced with that of the ZenPad S8.0 CA.

However, I would like to be really positive that a signed bootloader problem really exists. So far I haven't really been prevented from flashing a modified firmware (although not changing the kernel yet), or of course installing the temporary recovery image proposed in this thread first post for rooting. In particular, I've never seen security restrictions -due error messages such as these ones: http://23pin.logdown.com/posts/233350-zenfone-unlocked-device-interesting-discovery

It would be nice, to try recompiling Cyanogenmod and porting that over / see at least exactly where an upload or boot attempt would stop, and more efforts needed...