Database Info

[Q] Building Harmony/GTablet CyanogenMod from source?

I'm getting pretty far along building CyanogenMod for the GTablet on Mandriva Linux x86_64, I pulled the latest source and did the following from a bash shell:
Code:
cd device/nvidia/harmony
./extract-files.sh
cd ../../..
cp ./vendor/cyanogen/products/cyanogen_harmony.mk ./buildspec.mk
. build/envsetup.sh
lunch cyanogen_harmony-eng
cd vendor/cyanogen
./get-rommanager
./get-google-files -v hdpi
cd ../..
make -j6 CYANOGEN_WITH_GOOGLE=true bacon
I'm wondering if I should have gotten the mdpi-tegra google apps instead? get-google-files requires the following change if so:
Code:
FILENAME=["gapps-hdpi-20101114-signed.zip","gapps-mdpi-20101020-signed.zip","gapps-mdpi-tiny-20101020-signed.zip","gapps-mdpi-tegra-20101020-signed.zip"]
VERSIONS=["hdpi","mdpi","mdpi-tiny","mdpi-tegra"]
then do:
Code:
./get-google-files -v mdpi-tegra
Has anyone gotten this working?

I'm almost 100% positive that you cannot use HDPI gapps. MDPI gapps are the ones that you need to use for CM6.1 for this device.

Good to know, I just got it built but now clockwork doesn't see the update-cm-6.1.0-Beta4-Harmony-signed.zip on the sdcard?!? I can mount and verify the .zip from linux, the file should be in the root directory, correct?
Weird, I tried copying over the clockwork update.zip and recovery/ dirs, now I can see LOST.DIR but nothing else from the recovery install from sdcard option...

Dumb question....but did you mount the sdcard? I've seen that happen if the card is not mounted to /sdcard

Possible /sdcard and /sdcard2 mount confusion?

Nope, from adb shell I can see /mnt/sdcard with the files (which match md5 checksums):
Code:
# ls -lF /mnt/sdcard
d---rwxr-x 3 system sdcard_r 4096 Jan 25 06:51 Android/
d---rwxr-x 2 system sdcard_r 4096 Jan 25 06:51 LOST.DIR/
d---rwxr-x 2 system sdcard_r 4096 Oct 29 2010 recovery/
----rwxr-x 1 system sdcard_r 83928334 Dec 5 2010 update-cm-6.1.0-Beta4-Harmony-signed.zip*
----rwxr-x 1 system sdcard_r 4003082 Nov 9 2010 update.zip*
Is there anything special that needs to be done with permissions? I did have to repartition the sd card, somehow it got really messed up when I tried formatting it from the tablet's setup app.
edit: I found out that the .zip needs to be on /mnt/emmc (which I guess shows up as sdcard from clockwork recovery).

[R&D] Unlock Bootloaders

Rules:
Do not post in here unless you have something constructive to say. "Thanks", "Hey this is wonderful", and any other comments like that are not wanted. They take up space and make it more difficult to find information. I'm requesting that this thread be heavily moderated. In order to work efficiently, information density must be kept high. We are all guilty of adding in a few off-topic sentances from time-to-time, but this thread is strictly business and I expect the moderators to moderate me as well.
What is this?
This is the place where we can research and develop a method to unlock the bootloader of the Verizon Galaxy SIII. Hopefully, this will be development at its finest.
Why not just buy a developer edition
GTFO! Not a single person got started developing by buying a developer phone. They started developing because they were unhappy with the features of their device and wanted something better. They wanted something more. This developer phone is a tax on developer innovation. We do not stand for that. We will break the security and we will enable XDA-Developers to do what they do best.
Until security is broken and available for everyone, this device will get updates last, users will be unhappy because there are no additional features and Samsung violates the spirit of Open Source and copyright laws. Take a look at the bottom line of GPL-Violations.org FAQ located here: http://gpl-violations.org/faq/sourcecode-faq.html
What are the goals?
Attain a bootloader recovery - 75% JTAG (the extra 25% will be for a user-friendly method)
The Galaxy S3 is bootable from SDCard. In case of emergency this is needed. We need to verify that this works on the Verizon GS3 to bring up Odin. This will set up infrastructure for research.
Attain a full stock restoration via Odin or Heimdall - 90%
For use with Odin3.
Bootloader - BOOTLOADER_I535VRALF2_618049_REV09_user_low_ship.tar.md5 - 1.97 MB - Thanks nbsdx
PDA - SCH-I535_VZW_1_20120705143513_fti2qg2lmf.zip
NEED CSC PACKAGE (MODEM, PARAMS and Other Miscellaneous partitions). This is enough to recover a device though.
To include bootloaders and recovery to a working and stock condition with the EMMC wiped entirely. Heimdall is a work in progress for this device. This will complete the infrastructure needed for research.
Collect information
This will be the longest and most difficult part of this development. The information provided by Qualcomm is not readily available. Samsung is notoriously secretive about their bootloaders. Mainly we, as a community, will generate information. Please post any relevant datasheets, theory-of-operation, or manuals which you can find.
Provide a way to remove security checks from Odin3.] 100% - insecure aboot.img which may break in the future
By removing security checks from Odin3 on the computer or the Loki daemon on the device we can flash anything through Odin or Heimdall.
Provide a way to bypass security checks within bootloaders. 200% we have two exploits, only one has been released.
This is the ultimate goal. Once we can bypass the security checks, kernels can be flashed giving us the control required to develop
Initial information
[BOOTLOADER] Locked bootloader research and news: http://forum.xda-developers.com/showthread.php?t=1756919
My own research
SBL1 is the first booting partition. Qualcomm provides the Modem partition so it comes first on the EMMC. SBL1 is the first bootloader and that is specified by Qualcomm standards. Qualcom mmake sthe primitive bootloader and allows their customers (Samsung) to make a Secondary bootloader. Samsung chose to use three secondary bootloaders.
The following 0p* are located in /dev/block/mmcblk*
0p1 = modem
Built by se.infra
HUDSON_GA_D2_USA-VZW-HARDKEY-PROD-USER
I take this to mean this Qualcomm modem was built in Hudson Georgia.
I was not able to find signatures on this block . This does NOT mean that there are no signatures on this block. The file is 33 megs. The file is unencrypted.
The modem uses the BLAST Kernerl ver : 02.04.02.02.00 Unfortunately we need someone who speaks French(???) to understand how this works http://blast.darkphpbb.com/faq.php
Judging by the contents of this file, it is an operating system of it's own including keyboard, mouse and a lot of debugging information. We need to find out more about the BLAST Kernel and this partition.
Samsung Proprietary partitions SBL1,2,3
Overall I'm not entirely familiar with this new 3 SBL setup. If someone could help me out, that would be great. This 3 SBL setup looks like they tried to adapt (slopily) their IBL+PBL+SBL setup to the Qualcomm and added overhead.
op2=sbl1
This block is signed by Samsung, we will not be able to modify it.
Some Strings we expect to see on UART are:
0p3=sbl2
This block is signed by Samsung, we will not be able to modify it.
Some of the strings we may see over UART are:
Code:
RPM loading is successful.
cancel RPM loading!
SBL2, End
SBL2, Delta
.sbl2_hw.c
sbl2_hw_init, Start
sbl2_hw_init, Delta
sbl2_hw_init_secondary, Start
h/w version : %d
sbl2_hw_init_secondary, Delta
.SBL2, Start
scatterload_region & ram_init, Start
.scatterload_region & ram_init, Delta
.sbl2_mc.c
sbl2_retrieve_shared_info_from_sbl1, Start
.sbl2_retrieve_shared_info_from_sbl1, Delta
0p4=sbl3
This block is signed by Samsung, we will not be able to modify it.
Possibly useful information:
SVC: R1-R14
FIQ:R13-R14
IRQ:R13-R14
UND:R13-R14
ABT:R13-R14
SYS:R13-R14
This block appears to be a full OS of its own. I'm not sure of its purpose.
op5= aboot
This block is signed by Samsung, we will not be able to modify it
This block contains HTML information. It would appear that it is possible to put the device into a mode where it will provide a webserver which displays state information.
This block appears to be a complete operating system
This block contains the Loke Daemon which communicates with Odin3.
0p6= rpm
This block is signed by Samsung we will not be able to modify it
0p7= boot
This is the kernel. There are several things we can do here... I belive this package itself is not signed, but the zImage itself is... here is the bootimg.cfg file
Code:
[email protected]:~/Desktop/VZWGS3$ cat ./bootimg.cfg
bootsize = 0xa00000
pagesize = 0x800
kerneladdr = 0x80208000
ramdiskaddr = 0x81500000
secondaddr = 0x81100000
tagsaddr = 0x80200100
name =
cmdline = console=null androidboot.hardware=qcom user_debug=31
It may be possible to use that cmdline variable as an exploit.
0p8= tzTrust Zone
0p9= pad
0p10= param -boot mode parameters - this could be a potential exploitation point.
0p11= efs -serial numbers
I've honestly got no clue about most of the following partitions.
0p12= modemst1
0p13= modemst2
0p14= system - Android stuff
0p15= userdata - App Stuff
0p16= persist
0p17= cache - Storage for updates
0p18= recovery - recovery partition
0p19= fota
0p20= backup
0p21= fsg
0p22= ssd
0p23= grow
External UART log from initial power up:
Code:
[1630] AST_POWERON
[ 0.000000] heap->name mm, mb->start c0000000
[ 0.000000] Reserving memory at address ea000000 size: 100000
[ 0.000000] sec_dbg_setup: [email protected]
[ 0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
[ 0.000000] sec_dbg_setup: secdbg_size = 0x40000
[ 0.000000] etb_buf_setup: [email protected]
[ 0.000000] etb_buf_setup: secdbg_paddr = 0x8fffb9c0
[ 0.000000] etb_buf_setup: secdbg_size = 0x4000
[ 0.174515] rdev_init_debugfs: Error-Bad Function Input
[ 0.174881] AXI: msm_bus_fabric_init_driver(): msm_bus_fabric_init_driver
[ 0.176957] sec_debug_init: enable=0
[ 0.177475] ec_debug_nit: restrt_reason: 0xdf0085c
[ .216358] msm8960_iit_cam:292]settingdone!!
[ 0.25006] i2c 2c-14: Inalid 7-bi I2C addrss 0x00
0.25237] i2c ic-14: Can' create evice at x00
[ 0.252220]i2c i2c-1: Failed o registeri2c clien cmc624 t 0x38 (-6)
[ .252250] 2c i2c-19:Can't crete deviceat 0x38
0.25433] rdevinit_debufs: Error-ad Functin Input
0.25222] max892 19-006: DVS mode disabledbecause VD0 and VI1 do not ave prope control.
[ 0.79536] ms_etm msm_tm: ETM tacing is ot enable beacaussec_debug s not enaled!
[ 0.284449 smd_chanel_probe_orker: alocation tble not iitialized
[ 0.38766] pm_untime: fil to wak up
[ 0.362032]hdmi_msm dmi_msm.1 externalcommon_stte_create sysfs grup de39e68
[ 0362673] Iside writback_drivr_init
[ 0.36275] Insidewritebackprobe
[ 1.244803] TZCOM: unable to get bus clk
[ 1.431680] cm36651_setup_reg: initial proximity value = 3
[ 1.549671] msm_otg msm_otg: request irq succeed for otg_power
[ 1.566702] mms_ts 3-0048: [TSP] ISC Ver [0xbb] [0x20] [0x20]
[ 1.571341] mms_ts 3-0048: [TSP] fw is latest. Do not update.
[ 1.583488] [__s5c73m3_probe:3818] S5C73M3 probe
[ 1.587089] [s5c73m3_sensor_probe_cb:3793] Entered
[ 1.591942] [s5c73m3_i2c_probe:3675] Entered
[ 1.596123] [s5c73m3_init_client:3381] Entered
[ 1.600579] [s5c73m3_i2c_probe:3695] Exit
[ 1.604608] [s5c73m3_sensor_probe:3726] Entered
[ 1.609095] [s5c73m3_spi_init:226] Entered
[ 1.613154] [s5c73m3_spi_probe:191] Entered
[ 1.617335] [s5c73m3_spi_probe:201] s5c73m3_spi successfully probed
[ 1.623561] [s5c73m3_sensor_probe : 3749] Probe_done!!
[ 1.672638] mmc0: No card detect facilities available
[ 1.682984] aat1290a_led_probe : Probe
[ 1.693850] msm_soc_platform_init
[ 1.697298] msm_afe_afe_probe
[ 1.843064] msm_asoc_pcm_new
[ 1.849748] msm_asoc_pcm_new
[ 2.023134] set_dload_mode <1> ( c00176d4 )
[ 2.052220] cypress_touchkey 16-0020: Touchkey FW Version: 0x06
[ 2.123851] init: /init.qcom.rc: 466: invalid command '/system/bin/log'
[ 2.129620] init: /init.qcom.rc: 573: ignored duplicate definition of service 'sdcard'
[ 2.137402] init: /init.qcom.rc: 586: ignored duplicate definition of service 'ftm_ptt'
[ 2.145490] init: /init.target.rc: 73: ignored duplicate definition of service 'thermald'
[ 2.154677] init: could not open /dev/keychord
[ 2.239951] init: Device Encryption status is (0)!!
[ 2.243705] init: [disk_config] :::: fsck -> /dev/block/mmcblk0p15 (ext4):::::
[ 2.251823] init: [disk_config] ext_check -> /system/bin/e2fsck -v -y /dev/block/mmcblk0p15
[ 2.588921] init: [disk_config] ext_check ->ok
[ 2.611597] init: [disk_config] :::: fsck -> /dev/block/mmcblk0p17 (ext4):::::
[ 2.617762] init: [disk_config] ext_check -> /system/bin/e2fsck -v -y /dev/block/mmcblk0p17
[ 2.655333] init: [disk_config] ext_check -> ok
[ 2.664947] init: [disk_config] :::: fsck -> /dev/block/mmcblk0p11 (ext4):::::
[ 2.671081] init: [disk_config] ext_check -> /system/bin/e2fsck -v -y /dev/block/mmcblk0p11
[ 2.704532] init: [disk_config] ext_check -> ok
[ 3.259056] init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
[ 3.270471] init: cannot find '/system/bin/dmbserver', disabling 'dmb'
External UART log from battery-pull and reinsert
Code:
[1630] AST_POWERON
[ 0.000000] heap->name mm, mb->start c0000000
[ 0.000000] Reserving memory at address ea000000 size: 100000
[ 0.000000] sec_dbg_setup: [email protected]
[ 0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
[ 0.000000] sec_dbg_setup: secdbg_size = 0x40000
[ 0.000000] etb_buf_setup: [email protected]
[ 0.000000] etb_buf_setup: secdbg_paddr = 0x8fffb9c0
[ 0.000000] etb_buf_setup: secdbg_size = 0x4000
[ 0.174484] rdev_init_debugfs: Error-Bad Function Input
[ 0.174851] AXI: msm_bus_fabric_init_driver(): msm_bus_fabric_init_driver
[ 0.176926] sec_debug_init: enable=0
[ 0.177445] sc_debug_iit: restat_reason 0xdf0086c
[ 0216206] [sm8960_int_cam:299]setting one!!
[ 0.217915 select_req_plan:ACPU PVS:Nominal
0.25206] i2c ic-14: Invaid 7-bit 2C addres 0x00
[ 0.25207] i2c i2-14: Can'tcreate deice at 0x0
[ 0252250] 2c i2c-19 Failed t register 2c clientcmc624 at0x38 (-16
[ 0252250] ic i2c-19: an't creae device t 0x38
[ 0.25243] rdev_iit_debugs: Error-Bd Functio Input
[ 0.25292] max895 19-0060:DVS modesdisabled ecause VI0 and VID do not hve propercontrols.
[ 0.29536] msmetm msm_em: ETM trcing is nt enable!
[ 0.35797] pm_rntime: fal to wakeupllcation tale not intialized
[ .362093] dmi_msm hmi_msm.1:external_ommon_stae_create:sysfs grop de39e60
[ 0.62734] Inide writeack_driverinit
[ 0.36285] Inside riteback_robe
[ 1.244803] TZCOM: unable to get bus clk
possible exploitations
Possible entry point MODEM - Someone with a JTAG setup test viability of modifying a single byte on /dev/block/mmcblk0p1
Possible entry point PARAMS - Samsung stores their boot parameters in PARAMS partition. It may be possible to modify PARAMS for insecure boot
Possible entry point BOOT - Modify CMDLINE parameter to load information from another location.
Possible entry point BOOT - We may be able to shove an insecure bootloader into memory, boot into that, and then use the recovery partition as our kernel partition. Bauwks 2nd U-Boot. U-Boot is available for the Exynos 4412, we need to find one for Qualcomm.
Possible entry point SYSTEM - It may be possible to use a 2nd init hack from this partition to load custom kernels into memory and reboot the kernel.
Current tasks
What do all of these partitions do?
Do we have a SDCard based recovery?
Where can we find an Odin3 CSC Flash?
Testing methods above is required

You may want to try using google translate for the French website. I gave it a shot and it translates pretty well. See attached (sorry, I'm not a developer, but am trying to help in anyway I can). You can also try this url, but you may need to re-enter yourself
http://translate.google.com/transla...tf=1&u=http://blast.darkphpbb.com/faq.php#f42

What I am looking into is the upload mode available in Odin. It has no signature checks from what I can tell. Also do you mean a stock Odin file which we do have.
Sent from my SCH-I535 using Tapatalk 2

Adam, appreciate you keeping us up to date. As an electrical/systems engineer the journey is great learning experience for me and all.
I'm not sure if you've come across this document. It talks about the MSM7xxx series security capabilities. I couldn't find one for the MSM8xxx, but this may give some insight into how Qualcomm approaches security.
MSM7xxx
Edit: Looks like you are aware of the concepts from your reference about IBL,PBL,SBL.

Not sure if this will be any help, but found this regarding the blast kernel:
http://www.anyclub.org/2012/06/how-to-add-more-physical-ram-memory.html
how to add more physical RAM memory section to Blast Kernel in the MDM9200/MDM9600
Blast Kernel has the capability to take more than one contiguous physical RAM space (section) and use it for its own system memory. In order to add more RAM mem section to Blast, the customer need to modify blast_config.c file.
Here is the example of adding 4MB additional RAM mem section.
In blast_config.c,
struct phys_mem_pool_config pool_configs[] __attribute__((weak)) = {
{"DEFAULT_PHYSPOOL", //name
{
{0x00c00000, 0x02f00000}, // 47MB, the first mem section
{0x00700000, 0x00400000} // adding 4MB, QC default value is {0}
}
},
In this example, additional 4MB is added starting from 0x700000 physical address offset.
Please note the start address has to be physical address.
By adding the second mem section, the Blast Kernel can now use 51MB in total, while it used only 47MB before adding the 4MB mem section
Click to expand...
Click to collapse
Found this http://code.google.com/p/blastkernel/ (locked down though, I couldn't get access) which was linked from here (also in french but translated through google) but I'm unsure as to if it is related to the blastkernel you are looking for as all the links for the source code are now broken.
Also, while looking through the vz source I found that the person responsible for a lot the vzw specific code also helped to develop this http://www.uclinux.org/ so maybe some of that source might be of some help too.

There are relatively large pins between the processor and the other larger chip on the back side of the board. I'm not sure what I'm looking at, but it's definitely communications of some kind. These were taken with the battery out of the device when plugged into USB. Each set starts a new unplug-plugin sequence.
Code:
:�0�0�0
�0
�0
�0
�0��0
�0
�0��0
�0��0
�0
�0
�0
�0��0
�0
�0
�0
�0
�0
�0
�0
�0��0�0
�0
�0
�0
�0
�0
�0 x
:�0�0�0
�0
�0
�0
�0��0
�0��0
�0
�0
�0
�0
�0��0
�0
�0
�0
�0
�0
�0
�0
�0
�0��0
�0
�0
�0
�0
�0��0
�0
�0 z
�0
p
:�0�0�0
�0
�0
�0��0
�0�0
�0
�0
�0
�0
�0
�0��0
�0
�0
�0
�0
�0
�0
�0
�0
�0
�0
�0
�0
�0
�0
�0��0
�0
�0 �
�0�
This is from another pin on the back. As soon as plugged in, a series of 2's come out at 115200BPS:
Code:
22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222
Here's another one:
Code:
2"DB"D""D""D""D""D""B""B""B""B"DB"DB"DB"D""D""D""D""D""B""B""B""B"DB"DB"DB"D""D""D""D""D""B""B""B""B"DB"DB"DB"D""D""D""D""D""B""B""B""B"DB"DB"DB"D""D""D""D""D""B""B""B""B"DB"DB"DB"D""D""D""D""D""B""B""B""B"DB"DB"DB"D""D""D""D""D""�
All of these were located between the processor and SDCard. I must examine these bettter. In particular, there are two points at the corner of the processor just above where my needle is located in this picture.
Code:
U��UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU�UUU��JUU��UUUU��UUU��Z���UUUU���UUUUU���UUUUUU���UUUU���UUUUUUٙ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
These points seem to be what I'm looking for. as far as UART.. Especially that last one. It moves just as you'd expect start-up checks to move, random strings of characters... While not intelligable in the above, after figuring out the bitrate I'm sure something will come through.
I need to analyze the bitrate at this point. I'm quitting for the night though.
I am at the wrong baud rate, but I think I pulled up some valuable boot data from the processor.

Just a sidenote - some of these testpoints might be CLK/PWM signals, the one with serie of "2222" seems like this.
Also - if UART coming out of FSA muxer is 115200bps - the same debug line, on testpoint before FSA must be aswell 115200bps. Unless bootloader output goes to other port with different baud rate, which sounds unlikely.

Rebellos said:
Just a sidenote - some of these testpoints might be CLK/PWM signals, the one with serie of "2222" seems like this.
Also - if UART coming out of FSA muxer is 115200bps - the same debug line, on testpoint before FSA must be aswell 115200bps. Unless bootloader output goes to other port with different baud rate, which sounds unlikely.
Click to expand...
Click to collapse
You're right about the 2's.. it's probly a sync signal or something....ie...
Code:
00000010
However, I don't believe the UART is all consistant. Here's my reasoning. Samsung does not control the processor or the initial bootloader on the processor. I've spoken to some engineers and they are frustrated because things must be sent to Qualcomm to get work done on the bootloaders. It's highly likely that they simply change the bps of the UART to match the Samsung standard.
Thanks to Josh Groce at MobileTechVideos for the heads up on this trick: I was able to mount the Qualcomm Modem partition which I also belive to be the PBL as a FAT partition
Code:
[email protected]:~/Desktop/VZWGS3$ sudo mount ./0p1 ./p1
[email protected]:~/Desktop/VZWGS3$ ls -l ./p1
total 16
drwxr-xr-x 2 root root 16384 Jul 5 2011 image
[email protected]:~/Desktop/VZWGS3$ ls -l ./p1/image
total 42464
-rwxr-xr-x 1 root root 244 Jun 15 08:33 dsps.b00
-rwxr-xr-x 1 root root 160 Jun 15 08:33 dsps.b01
-rwxr-xr-x 1 root root 147456 Jun 15 08:33 dsps.b02
-rwxr-xr-x 1 root root 31872 Jun 15 08:33 dsps.b03
-rwxr-xr-x 1 root root 6220 Jun 15 08:33 dsps.b04
-rwxr-xr-x 1 root root 13824 Jun 15 08:33 dsps.b05
-rwxr-xr-x 1 root root 404 Jun 15 08:33 dsps.mdt
-rwxr-xr-x 1 root root 180 Jun 15 07:50 dxhdcp2.b00
-rwxr-xr-x 1 root root 6520 Jun 15 07:50 dxhdcp2.b01
-rwxr-xr-x 1 root root 135168 Jun 15 07:50 dxhdcp2.b02
-rwxr-xr-x 1 root root 2100 Jun 15 07:50 dxhdcp2.b03
-rwxr-xr-x 1 root root 6700 Jun 15 07:50 dxhdcp2.mdt
-rwxr-xr-x 1 root root 308 Jun 15 08:33 modem.b00
-rwxr-xr-x 1 root root 6600 Jun 15 08:33 modem.b01
-rwxr-xr-x 1 root root 21960368 Jun 15 08:33 modem.b02
-rwxr-xr-x 1 root root 4962049 Jun 15 08:33 modem.b03
-rwxr-xr-x 1 root root 1358104 Jun 15 08:33 modem.b04
-rwxr-xr-x 1 root root 72208 Jun 15 08:33 modem.b06
-rwxr-xr-x 1 root root 707124 Jun 15 08:33 modem.b07
-rwxr-xr-x 1 root root 1044 Jun 15 08:25 modem_f1.b00
-rwxr-xr-x 1 root root 7060 Jun 15 08:25 modem_f1.b01
-rwxr-xr-x 1 root root 2676 Jun 15 08:25 modem_f1.b02
-rwxr-xr-x 1 root root 954800 Jun 15 08:25 modem_f1.b03
-rwxr-xr-x 1 root root 575208 Jun 15 08:25 modem_f1.b04
-rwxr-xr-x 1 root root 246484 Jun 15 08:25 modem_f1.b05
-rwxr-xr-x 1 root root 94208 Jun 15 08:25 modem_f1.b06
-rwxr-xr-x 1 root root 13568 Jun 15 08:25 modem_f1.b07
-rwxr-xr-x 1 root root 11212 Jun 15 08:25 modem_f1.b08
-rwxr-xr-x 1 root root 9548 Jun 15 08:25 modem_f1.b09
-rwxr-xr-x 1 root root 68223 Jun 15 08:25 modem_f1.b10
-rwxr-xr-x 1 root root 113468 Jun 15 08:25 modem_f1.b13
-rwxr-xr-x 1 root root 164412 Jun 15 08:25 modem_f1.b14
-rwxr-xr-x 1 root root 3604 Jun 15 08:25 modem_f1.b21
-rwxr-xr-x 1 root root 28156 Jun 15 08:25 modem_f1.b22
-rwxr-xr-x 1 root root 19136 Jun 15 08:25 modem_f1.b23
-rwxr-xr-x 1 root root 74360 Jun 15 08:25 modem_f1.b25
-rwxr-xr-x 1 root root 49740 Jun 15 08:25 modem_f1.b26
-rwxr-xr-x 1 root root 84476 Jun 15 08:25 modem_f1.b29
-rwxr-xr-x 1 root root 1064 Jun 15 08:25 modem_f1.fli
-rwxr-xr-x 1 root root 8104 Jun 15 08:25 modem_f1.mdt
-rwxr-xr-x 1 root root 1044 Jun 15 08:25 modem_f2.b00
-rwxr-xr-x 1 root root 7060 Jun 15 08:25 modem_f2.b01
-rwxr-xr-x 1 root root 2676 Jun 15 08:25 modem_f2.b02
-rwxr-xr-x 1 root root 955792 Jun 15 08:25 modem_f2.b03
-rwxr-xr-x 1 root root 579032 Jun 15 08:25 modem_f2.b04
-rwxr-xr-x 1 root root 239892 Jun 15 08:25 modem_f2.b05
-rwxr-xr-x 1 root root 94208 Jun 15 08:25 modem_f2.b06
-rwxr-xr-x 1 root root 13568 Jun 15 08:25 modem_f2.b07
-rwxr-xr-x 1 root root 11212 Jun 15 08:25 modem_f2.b08
-rwxr-xr-x 1 root root 9580 Jun 15 08:25 modem_f2.b09
-rwxr-xr-x 1 root root 68223 Jun 15 08:25 modem_f2.b10
-rwxr-xr-x 1 root root 116188 Jun 15 08:25 modem_f2.b13
-rwxr-xr-x 1 root root 158012 Jun 15 08:25 modem_f2.b14
-rwxr-xr-x 1 root root 3604 Jun 15 08:25 modem_f2.b21
-rwxr-xr-x 1 root root 28156 Jun 15 08:25 modem_f2.b22
-rwxr-xr-x 1 root root 19200 Jun 15 08:25 modem_f2.b23
-rwxr-xr-x 1 root root 74360 Jun 15 08:25 modem_f2.b25
-rwxr-xr-x 1 root root 49756 Jun 15 08:25 modem_f2.b26
-rwxr-xr-x 1 root root 84476 Jun 15 08:25 modem_f2.b29
-rwxr-xr-x 1 root root 1064 Jun 15 08:25 modem_f2.fli
-rwxr-xr-x 1 root root 8104 Jun 15 08:25 modem_f2.mdt
-rwxr-xr-x 1 root root 6908 Jun 15 08:33 modem.mdt
-rwxr-xr-x 1 root root 276 Jun 15 08:24 q6.b00
-rwxr-xr-x 1 root root 6580 Jun 15 08:24 q6.b01
-rwxr-xr-x 1 root root 3447760 Jun 15 08:24 q6.b03
-rwxr-xr-x 1 root root 1653278 Jun 15 08:24 q6.b04
-rwxr-xr-x 1 root root 757840 Jun 15 08:24 q6.b05
-rwxr-xr-x 1 root root 14472 Jun 15 08:24 q6.b06
-rwxr-xr-x 1 root root 6856 Jun 15 08:24 q6.mdt
-rwxr-xr-x 1 root root 180 Jun 15 07:50 tzapps.b00
-rwxr-xr-x 1 root root 6520 Jun 15 07:50 tzapps.b01
-rwxr-xr-x 1 root root 503808 Jun 15 07:50 tzapps.b02
-rwxr-xr-x 1 root root 452 Jun 15 07:50 tzapps.b03
-rwxr-xr-x 1 root root 6700 Jun 15 07:50 tzapps.mdt
-rwxr-xr-x 1 root root 212 Jun 15 07:44 wcnss.b00
-rwxr-xr-x 1 root root 140 Jun 15 07:44 wcnss.b01
-rwxr-xr-x 1 root root 8360 Jun 15 07:44 wcnss.b02
-rwxr-xr-x 1 root root 1778532 Jun 15 07:44 wcnss.b04
-rwxr-xr-x 1 root root 352 Jun 15 07:44 wcnss.mdt
[email protected]:~/Desktop/VZWGS3$

tz - is the trustzone, normal qualcomm
cache - should not be the dalvik cache, dalvik cache should be on teh userdata partition now on. (Could be wrong, dont have the device). Cache should be almost strictly for updates and recovery use now.
boot itself is signed, not the zImage.
I believe hopping on the developer device is a better option, not only is it made for such, it's also not purchasing a phone within Verizon's sales network (my favorite part of it all)

But google slapped on the GPLv3 i believe. And since GPL allows multiple licenses then the TIVO clause would still apply. Correct me if I am wrong.

Adam you may want to look at this its found in otacert.zip in this folder
http://db.tt/f4QYrK8x
Sent from my SCH-I535 using Tapatalk 2

In the uart dump in the op, the line stamped at 1.57 seems interesting. Looks like the modem (assuming that's still where the activity is going on then) is checking firmware. Makes me think that there might be something there that could be captured. I wonder where it is confirming the fw is updated.
This might not be useful, but it seems interesting.
Sent from my SCH-I535 using Xparent ICS Tapatalk 2

Why not try the Samsung flash utility instead of Odin.
Sent from my SCH-I535 using Tapatalk 2

tpike said:
In the uart dump in the op, the line stamped at 1.57 seems interesting. Looks like the modem (assuming that's still where the activity is going on then) is checking firmware.
Click to expand...
Click to collapse
Usually the firmware is loaded and checked in modem by modem RTOS kernel. But I don't know what modem (BP/CP) is used in the Verizon S3...

Errata to OP:
/efs partition on qualcomm models is as far as i know empty (not used)

AdamLange said:
Errata to OP:
/efs partition on qualcomm models is as far as i know empty (not used)
Click to expand...
Click to collapse
Many people on the forums here have stated IMEI information is stored in a file within /efs (at least on GSM models?) but I can't confirm myself.
There are several threads about attempting to restore lost IMEIs that might have more info.

papi92 said:
Adam you may want to look at this its found in otacert.zip in this folder
http://db.tt/f4QYrK8x
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
That's just the public key VZW uses to sign updates. Not of use to us.

I was playing around with Odin3. I'm a Linux guy so this was exploration for me.... I was able to make my own Odin package with signed Samsung images under Linux and flash it with Odin3 under Windows.
Code:
[email protected]:~/Desktop/Untitled Folder$ tar -cf OdinCustom.tar recovery.img boot.img
[email protected]:~/Desktop/Untitled Folder$ md5sum -t OdinCustom.tar >> OdinCustom.tar
[email protected]:~/Desktop/Untitled Folder$ mv ./OdinCustom.tar ./OdinCustom.tar.md5
[email protected]:~/Desktop/Untitled Folder$
The first command create a TAR (Tape ARchive format) of a recovery.img and a boot.img in a file called OdinCustom.tar. Then appends the MD5 to the end of the package. The third command renames it to OdinCustom.tar.md5. The resulting file is flashable by Odin.
This could prove useful if we can find another Qualcomm device which has a bootloader signed by Samsung.
Also, Odin3 has a cool inf file which can be modified to change the title and characteristics of Odin3 http://i49.tinypic.com/352q7t0.png
I found something in the qualcomm bootloader (first partition which is a fat32 and appears to be unsigned) in the tzapps.b02 file which may or may not be of use. apparently they are looking for something called "/file/file.dat" and it contains dummy data for executive test suite. May be a possible exploit.
Also, this is a very important excerpt from the Qualcomm manual mentioned earlier... http://www.scribd.com/doc/51789612/80-V9038-15-APPLICATION-NOTE-MSM7XXX-QFUSES-AND-SECURITY
Code:
The PBL performs the following functions during a cold boot:
■Performs the minimal hardware setup required for PBL execution
■Reads off-chip boot configuration data from the flash memory
■Processes configuration data setting up clocks and memory access based on this data
■Loads the QCSBL image from the flash memory into the RAM
■Authenticates the QCSBL image if authentication is enabled
■Branches execution to the QCSBL image
Reads off-chip boot configuration data from the flash memory!
I spent a lot of time tonight looking at the individual files on the MODEM partition. I got nowhere except to possibly add a test file I mentioned above. It was alot of data to go through. that MODEM is 60 megs!
So, I started loooking at the SBL1 file. Now, it appears that this file runs linearly and tells a story as it goes through...
Code:
[email protected]:~/Desktop/VZWGS3$ strings ./0p2|head -n 200
: 2q
: 4q
`" 2q
: 4q
: 4q
(R '
(R '
(R '
~}|{zyxwvvutsrqqponnmllkjjihhgffeddccbaa``__^^]]\\[[ZZYYXXWWVVUUUTTSSRRRQQPPPOOONNMMMLLLKKKJJJIIIHHHGGGGFFFEEEDDDDCCCCBBBBAAA
/!(
/!(0
/!(0
/!(
SDCC4 HAL v2.0.1
boot_error_handler.c
*[email protected]
*[email protected]
*[email protected]
*[email protected]
*[email protected]
*[email protected]
*[email protected]
boot_pbl_authenticator.c
boot_clobber_prot.c
boot_clobber_prot_local.c
boot_clobber_prot.c
boot_clobber_prot_local.c
boot_config.c
boot_config.c
*Image Loaded by %s, Start on 0x%x
Data Abort
boot_mc.c
boot_error_handler.c
*BOOT
SCL_SBL1_STACK_BASE-SCL_SBL1_STACK_SIZE
boot_error_handler.c
boot_flash_dev_if.c
boot_flash_dev_if.c
boot_flash_dev_if.c
boot_flash_dev_sdcc_if.c
boot_flash_dev_sdcc_if.c
boot_flash_dev_sdcc.c
boot_flash_init, Start
boot_flash_init, Delta
boot_flash_target.c
boot_flash_trans_sdcc.c
*[email protected]
boot_flash_trans_sdcc.c
boot_fota_restore_partition, Start
boot_fota_restore_partition, Delta
boot_fota_restore_partition, Start
restore_fota_partition fail
boot_fota_restore_partition, Delta
boot_error_handler.c
boot_error_handler.c
boot_loader.c
*[email protected]
*[email protected]
boot_pbl_authenticator.c
boot_pbl_v1.c
boot_pbl_v1.c
boot_pbl_v1.c
Prefetch Abort
boot_error_handler.c
boot_rollback_version.c
boot_flash_dev_sdcc.c
boot_error_handler.c
Undefined
boot_flash_dev_sdcc.c
boot_flash_dev_sdcc.c
boot_flash_dev_sdcc.c
boot_flash_dev_sdcc.c
boot_flash_dev_sdcc.c
boot_sdcc_hotplug.c
EFI PART
%sp%lu
%sh%d
%s%c%lu
*[email protected]
boot_sdcc_hotplug.c
boot_sdcc_hotplug.c
read fail
*hdev open fail: fota
hdev open fail: dest
size fail: src
size fail: too big
read fail: src
read fail: dest
write fail: signature clear
*[email protected]
*[email protected]
*[email protected]
*[email protected]
*[email protected]
*|@-
boot_sdcc_hotplug.c
%sp%lu
*[email protected]
*[email protected]
SBL1, End
SBL1, Delta
*[email protected]
sbl1_check_device_temp, Start
sbl1_check_device_temp, Delta
sbl1_hw.c
sbl1_hw_init, Start
sbl1_hw_init, Delta
*SBL1, Start
scatterload_region && ram_init, Start
*scatterload_region && ram_init, Delta
sbl1_mc.c
sbl1_mc.c
*[email protected]
*[email protected]
*[email protected]
*{%u}
n;^
Qkkbal
i]Wb
9a&g
MGiI
wn>Jj
#.zf
+o*7
[email protected]
[email protected]
SBL2 Image Loaded, Delta
SBL1
DSP1
RAMFS1
SBL2
DSP2
RAMFS2
SBL3
ADSP_Q5
NONE
NANDPRG
NORPRG
HASH
QCSBL
FSBL
OSBL
APPSBL
OEM_SBL
EHOSTDL
APPS_KERNEL
BACKUP_RAMFS
APPS
AMSS
SSD_KEYS
fs_hotplug_api.c
Assertion phy_hdev != NULL failed
boot_flash_trans_sdcc
boot_flash_trans_sdcc_factory
boot_flash_dev_sdcc
HAL_SBI_SSBI_V2_PMIC_ARBITER
fs_hotplug_iter.c
Assertion 0 failed
fs_hotplug_legacy_hdev.c
Assertion phy_hdev->legacy_hdev != NULL failed
fs_hotplug_partition.c
Assertion parti->is_locked == 0 failed
Assertion parti->is_formatting == 0 failed
Assertion parti->is_locked == 1 failed
Assertion parti->is_formatting == 1 failed
Assertion parti->ref_cnt >= 1 failed
Assertion hdev_name != NULL failed
Assertion parti != NULL failed
fs_hotplug_dev_state.c
Assertion phy_hdev->dev_state == HPDEV_UNDISCOVERED failed
Assertion phy_hdev->dev_state == HPDEV_DISCOVERED failed
Assertion phy_hdev->dev_state == HPDEV_UNMOUNTED failed
Assertion phy_hdev->dev_state == HPDEV_UNINITIALIZED || phy_hdev->dev_state == HPDEV_LOCKED || phy_hdev->dev_state == HPDEV_FORMATTING || phy_hdev->dev_state == HPDEV_UNMOUNTED failed
Assertion phy_hdev->dev_state == HPDEV_MOUNTED failed
Assertion phy_hdev->dev_state == HPDEV_UNINITIALIZED failed
fs_hotplug_poll.c
Assertion phy_hdev->bdev_handle == NULL failed
Assertion phy_hdev->parti_list == NULL failed
Assertion phy_hdev->hdev_list == NULL failed
fs_blockdev_devnull_driver.c
Assertion devnull_ops != NULL failed
/hdev/dev.null
BDEV_DEVNULL_DRIVER
BDEV_SD_DRIVER
/hdev/sdc1
/hdev/sdc2
/hdev/sdc3
/hdev/sdc4
fs_blockdev_sd_driver.c
Assertion sdcc_ops != NULL failed
fs_hotplug_parser.c
Assertion blk_cnt != 0 failed
fs_blockdev_sd.c
Assertion sd_data != NULL failed
Assertion handle != NULL failed
Assertion sdcc_handle != NULL failed
Assertion bytes_per_block != NULL failed
Assertion blocks != NULL failed
Assertion bdev != NULL failed
Assertion dev->driveno < max_sd_slots failed
@@@@@@@@@[email protected]@@@@@@@@@@@@@@@@@
Format: Log Type - Time(microsec) - Message
Log type: B - since boot(excluding boot rom). D - delta
OVERFLOW
........
Particularly "boot_fota_restore_partition, Start". It looks like one of the first things the GS3 does is check for information to be updated on FOTA partition. Whatever it choses to do, it performs security checks on the size, and a few other things.
I believe it then loads SBL2 as the rest of the partitions do not have this message.. "SBL2 Image Loaded, Delta".
SBL2:
Code:
[email protected]:~/Desktop/VZWGS3$ strings ./0p3
SVC: R1-R14
FIQ:R13-R14
IRQ:R13-R14
UND:R13-R14
ABT:R13-R14
SYS:R13-R14
[email protected]
K{DiF
K{DiF
D(b(F
hu)AF
019Ud
3F*[email protected]
G [email protected]
&_F F
h/F F
fJF)F F&`NF
F 9"
pJpO
: 4q
: 6q
: 8q
! 6q
`" 2q
: 4q
pG hJ
G [email protected]
bNE
G [email protected]
G [email protected]
j8D b F
02:Ud
3F*[email protected]
CreT
#L|D
!L|D
F)F F
5EC/
x0(
02bUm
#\b\cTI
FAF F
F!h
b h
G jv
G [email protected]
G [email protected]
,pp
2F!F
G [email protected]
1JzD
2FhF
2FiF
: 4q
: 6q
: 8q
bF9FN
RAIAK
bF9FN
RAIAK
bF9FN
~}|{zyxwvvutsrqqponnmllkjjihhgffeddccbaa``__^^]]\\[[ZZYYXXWWVVUUUTTSSRRRQQPPPOOONNMMMLLLKKKJJJIIIHHHGGGGFFFEEEDDDDCCCCBBBBAAA
! 3[B
[email protected]
[email protected]
SDCC4 HAL v2.0.1
pGxG
.boot_error_handler.c
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
.boot_auth_if.c
.boot_auth_if.c
.boot_sbl_authenticator.c
.boot_clobber_prot.c
.boot_clobber_prot_local.c
boot_clobber_prot.c
boot_clobber_prot_local.c
boot_config_data_table_init, Start
.boot_config_data_table_init, Delta
.boot_config.c
.boot_config.c
.Image Loaded by %s, Start on 0x%x
Data Abort
Ufw}3{
O*2PC~
[email protected]
.boot_mc.c
.0:ALL
.boot_error_handler.c
.BOOT
SCL_SBL2_STACK_BASE-SCL_SBL2_STACK_SIZE
.boot_error_handler.c
.boot_flash_dev_if.c
.boot_flash_dev_if.c
.boot_flash_dev_if.c
.boot_flash_dev_sdcc_if.c
.boot_flash_dev_sdcc_if.c
.boot_flash_dev_sdcc.c
boot_flash_init, Start
boot_flash_init, Delta
.boot_flash_target.c
.boot_flash_trans_sdcc.c
[email protected]
.boot_flash_trans_sdcc.c
.boot_hash.c
.boot_hash_if.c
.boot_hash_if.c
.boot_sys_loader.c
.boot_error_handler.c
.boot_error_handler.c
.boot_loader.c
.boot_loader.c
.boot_logger_ram.c
[email protected]
[email protected]
BRPMSignal SBL1 to Jump to RPM FW
.boot_sys_loader.c
.boot_pbl_v1.c
.boot_pbl_v1.c
.boot_pbl_v1.c
.boot_pbl_v1.c
Prefetch Abort
.boot_error_handler.c
.boot_rollback_version.c
.boot_sbl_authenticator.c
.boot_flash_dev_sdcc.c
[email protected]
.boot_ddr_info.c
.boot_sbl_authenticator.c
.boot_error_handler.c
Undefined
[email protected]
[email protected]
[email protected]
[email protected]
RDDL
Testing DDR Read/Write.
.Testing DDR Read/Write: Memory map.
Testing DDR Read/Write: Data lines.
Testing DDR Read/Write: Address lines.
Testing DDR Read/Write: Own-address algorithm.
Testing DDR Read/Write: Walking-ones algorithm.
Testing DDR Deep Power Down.
Testing DDR Deep Power Down: Entering deep power down.
Testing DDR Deep Power Down: In deep power down.
Testing DDR Deep Power Down: Exiting deep power down.
Testing DDR Deep Power Down: Read/write pass.
Testing DDR Self Refresh.
.Testing DDR Self Refresh: Write pass.
Testing DDR Self Refresh: Read pass.
Testing DDR Self Refresh: Entering self refresh.
Testing DDR Self Refresh: In self refresh.
Testing DDR Self Refresh: Exiting self refresh.
.boot_flash_dev_sdcc.c
.boot_flash_dev_sdcc.c
.boot_flash_dev_sdcc.c
.boot_flash_dev_sdcc.c
.boot_flash_dev_sdcc.c
[email protected]
.CDT
.Error: Platform ID EEPROM is not programmed
boot_config_data.c
.boot_sdcc_hotplug.c
[email protected]
EFI PART
%sp%lu
%sh%d
%s%c%lu
[email protected]
.boot_sdcc_hotplug.c
.boot_sdcc_hotplug.c
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
.|@-
.boot_sdcc_hotplug.c
%sp%lu
[email protected]
[email protected]
[email protected]
0!0
[email protected]
RPM loading is successful.
cancel RPM loading!
SBL2, End
SBL2, Delta
.sbl2_hw.c
sbl2_hw_init, Start
sbl2_hw_init, Delta
sbl2_hw_init_secondary, Start
h/w version : %d
sbl2_hw_init_secondary, Delta
.SBL2, Start
scatterload_region & ram_init, Start
.scatterload_region & ram_init, Delta
.sbl2_mc.c
sbl2_retrieve_shared_info_from_sbl1, Start
.sbl2_retrieve_shared_info_from_sbl1, Delta
.sbl2_mc.c
[email protected]
.sbl2_config.c
[email protected]
.boot_hash.c
[email protected]
[email protected]
[email protected]
[email protected]
.SHA256
[email protected]
LOGM
.{%u}
Tz Execution, Start
Tz Execution, Delta
pG B
0pGO
!pGO
sbl2_ddr_init
DalEnv
TargetCfg
SHA1
DEBUG
SW_ID
HW_ID
OEM_ID
SHA256
n;^
Qkkbal
i]Wb
9a&g
MGiI
wn>Jj
#.zf
+o*7
DEV_SDC1
DEV_SDC2
DEV_SDC3
DEV_SDC4
CHAN_SDC1
CHAN_SDC2
CHAN_SDC3
CHAN_SDC4
[email protected]
[email protected]
SBL3 Image Loaded, Delta
RPM Image Loaded, Delta
TZ Image Loaded, Delta
boot_auth
boot_hash
SBL1
DSP1
RAMFS1
SBL2
DSP2
RAMFS2
SBL3
ADSP_Q5
NONE
NANDPRG
NORPRG
HASH
QCSBL
FSBL
OSBL
APPSBL
OEM_SBL
EHOSTDL
APPS_KERNEL
BACKUP_RAMFS
APPS
AMSS
SSD_KEYS
fs_hotplug_api.c
Assertion phy_hdev != NULL failed
boot_flash_trans_sdcc
boot_flash_trans_sdcc_factory
boot_flash_dev_sdcc
fs_hotplug_iter.c
Assertion 0 failed
fs_hotplug_legacy_hdev.c
Assertion phy_hdev->legacy_hdev != NULL failed
fs_hotplug_partition.c
Assertion parti->is_locked == 0 failed
Assertion parti->is_formatting == 0 failed
Assertion parti->is_locked == 1 failed
Assertion parti->is_formatting == 1 failed
Assertion parti->ref_cnt >= 1 failed
Assertion hdev_name != NULL failed
Assertion parti != NULL failed
fs_hotplug_dev_state.c
Assertion phy_hdev->dev_state == HPDEV_UNDISCOVERED failed
Assertion phy_hdev->dev_state == HPDEV_DISCOVERED failed
Assertion phy_hdev->dev_state == HPDEV_UNMOUNTED failed
Assertion phy_hdev->dev_state == HPDEV_UNINITIALIZED || phy_hdev->dev_state == HPDEV_LOCKED || phy_hdev->dev_state == HPDEV_FORMATTING || phy_hdev->dev_state == HPDEV_UNMOUNTED failed
Assertion phy_hdev->dev_state == HPDEV_MOUNTED failed
Assertion phy_hdev->dev_state == HPDEV_UNINITIALIZED failed
fs_hotplug_poll.c
Assertion phy_hdev->bdev_handle == NULL failed
Assertion phy_hdev->parti_list == NULL failed
Assertion phy_hdev->hdev_list == NULL failed
fs_blockdev_devnull_driver.c
Assertion devnull_ops != NULL failed
/hdev/dev.null
BDEV_DEVNULL_DRIVER
BDEV_SD_DRIVER
/hdev/sdc1
/hdev/sdc2
/hdev/sdc3
/hdev/sdc4
fs_blockdev_sd_driver.c
Assertion sdcc_ops != NULL failed
fs_hotplug_parser.c
Assertion blk_cnt != 0 failed
fs_blockdev_sd.c
Assertion sd_data != NULL failed
Assertion handle != NULL failed
Assertion sdcc_handle != NULL failed
Assertion bytes_per_block != NULL failed
Assertion blocks != NULL failed
Assertion bdev != NULL failed
Assertion dev->driveno < max_sd_slots failed
@@@@@@@@@[email protected]@@@@@@@@@@@@@@@@@
Format: Log Type - Time(microsec) - Message
Log type: B - since boot(excluding boot rom). D - delta
OVERFLOW
AT24C128BN
:Hg~
D{L0
*gRn
0D,l}
b=Fe-+
gW6y
South Korea1
Suwon City1
Samsung Corporation1
DMC1#0!
Samsung AttestationCA cert1%0#
[email protected]
120614224636Z
320609224636Z0
KR1!0
Samsung Attestation CERT1
Suwon City1
Samsung Corporation1
South Korea1
04 0000 OEM_ID1%0#
[email protected]
05 0001E0C8 SW_SIZE1
06 0000 MODEL_ID1
07 0001 SHA2561"0
01 0000000000000005 SW_ID1"0
02 006B10E100000000 HW_ID1"0
03 0000000000000000 DEBUG0
y$_$
[OLW'}
Q^<T
&#xk#
z0x0:
3010/
)http://crl.qdst.com/crls/qctdevattest.crl0
6p5o
%e>I`
<dQ=#
South Korea1
Suwon City1
Samsung Corporation1
DMC1
Samsung Root CA cert1%0#
[email protected]
120412114438Z
320407114438Z0
South Korea1
Suwon City1
Samsung Corporation1
DMC1#0!
Samsung AttestationCA cert1%0#
[email protected]
&bMb
%pWj\
`0^0
#7ie
?f{M
South Korea1
Suwon City1
Samsung Corporation1
DMC1
Samsung Root CA cert1%0#
[email protected]
120412114438Z
320407114438Z0
South Korea1
Suwon City1
Samsung Corporation1
DMC1
Samsung Root CA cert1%0#
[email protected]
U)_|e}f
^AZp
<0:0
v)BT
zd0u
=j[P
As for SBL2. It looks like it starts up, performs security checks, then it can jump to "RPM" partition ", "RPM loading is successful.
cancel RPM loading!, .BRPM", "Signal SBL1 to Jump to RPM FW", This may be Odin, or some other undiscovered mode I'm not sure yet and it looks like "ABOOT" is actually Odin's partition... What is RPM?
It then executes "TZ" or "Trust Zone" which I need to do some reading on...
More to come later. It's late and I need to get some rest.

{i} PARAMS
AdamOutler said:
possible exploitations
Possible entry point PARAMS - Samsung stores their boot parameters in PARAMS partition. It may be possible to modify PARAMS for insecure boot
Click to expand...
Click to collapse
The PARAMS partition (from an adb dump) contains almost all 0's. Here are the first 32 bytes
(layed out in hex offsets of 0x00000000 && 0x00000010):
Code:
00000000 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
00000010 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
From what I understand, each occurance of 01 indicates a boot_mode variable that the SBL reads*. The rest of the file, about 10,485,739bytes of data, can contain information for other variables such as debug_level and switch_sel and maybe more, but I have too look more into dissembling the SBL patition image (sbl2.img) to see what other variables there are. I'll report back as soon as I have any more info on that.
*See this link for more info on the param.blk:
http://epiccm.blogspot.com/p/stock-firmware.html
I think its interesting that from an adb dump, BOOT, EFS, FOTA and PARAMS are all the same size. Only BOOT and PARAMS contain any data though. EFS and FOTA must be loaded from the BOOT partition depending on the boot variables loaded in the PARAMS partition, but I may be wrong on that.
As for booting from SDcard here's a link on how it was done with the Epic 4G:
http://epiccm.blogspot.com/2012/01/multiboot-android-for-debuggingtesting.html
The instructions seem like they should work, especially since they had to use kexec to load from the SDcard and the SGS3 will have to do the same for now. I haven't built this yet, but I will give it a go as soon as I have a spare moment.
EDIT: this might be what you're looking for as far as booting from SD --> http://forum.xda-developers.com/showthread.php?t=1774795 END EDIT
I am currently manually going through each hex offset in IDA and seaching for commands to disassemble aboot.img, I haven't gotten very far as this is extremely time intensive.
I can post any dissasm DB's that anyone wants. They can get rather large though.
On a side note, I'm using IDAPro6.1 for disassembly of the adb dumped partitions. If you have any pointers on using IDA for debugging/disassembling android partitions, that would be fantastic. I have an arm toolchain, but beyond that IDA I've only had experience poking at Window$ crap.
Ta,
ALQI

recovery kernel log
The recovery kernel log is in this path:
/data/log/recovery_kernel_log.txt​I'd post it in a code section here but it's just too long.
There's a few other interesting logs in that path as well.
As I understand it, this seems to be the log from the kernel loaded during the bootloader/Odin mode boot. Could reveal some of the variables set in the params partition. Plus it has juicy hex offsets for all kinds of things.
It's quite verbose.
K sleepy time now.
Ta,
ALQI

[KERNEL][TUTORIAL] Stock 10.4.4.25 + insecure + init.d + nodpi

I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment kernel-10.4.4.25-insecure.zip
Update 2013-01-21: Here is a version that does not set lcd_density, so that custom dpi set in /system/build.prop work. Verified to work with CROMI 3.2.
View attachment kernel-10.4.4.25-insecure-nodpi.zip
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
For the tutorial how to unpack and repack a kernel, see post #4.
Update 2013-01-21: Updated with info how to unlock DPI.

_that said:
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment 1657033
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
Click to expand...
Click to collapse
Nice work!!:good:

_that said:
I modified the new stock kernel with the ramdisk features from CleanROM:
- insecure adbd
- init.d support
Flashable ZIP:
View attachment 1657033
Working fine here with a mix of CleanROM 2.3, custom mods and some cherry-picked changes from CROMI. This kernel should be compatible with any stock ROM since 10.4.4.18 or CleanROM/Inheritance since 2.3.
My MicroSD card (Sandisk Mobile Ultra UHS-1) seems to work more stable now - will try All2SD tomorrow.
Click to expand...
Click to collapse
Many thanks - I've been struggling with linux to unpack the blob.LNX file. Blob tools isn't working for me for some reason as ./blobunpack blob.LNX says unrecognised blob format.
What is the secret to get it working?

sbdags said:
Many thanks - I've been struggling with linux to unpack the blob.LNX file. Blob tools isn't working for me for some reason as ./blobunpack blob.LNX says unrecognised blob format.
What is the secret to get it working?
Click to expand...
Click to collapse
I firmly believe that this should not be a secret, so I'll explain in detail how to do it and not only give you steps but also a lot of background info. Many steps in the following tutorial are optional and useful for learning, for checking things and for troubleshooting - I don't want you to blindly follow a recipe without understanding what you are doing.
Unpacking the blob
We start with the full firmware, unpacked once - in this case, WW_epad-user-10.4.4.25.zip. First extract the blob from the zip:
Code:
[email protected] ~/android/tf700/kernel $ unzip WW_epad-user-10.4.4.25.zip blob
Archive: WW_epad-user-10.4.4.25.zip
signed by SignApk
inflating: blob
This is a signed blob. It begins with "-SIGNED-BY-SIGNBLOB-". You can check this with hexdump (this step is completely optional, just for illustration):
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 48 blob
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d e9 1a d7 30 00 01 00 00 4d 53 4d 2d |LOB-...0....MSM-|
00000020 52 41 44 49 4f 2d 55 50 44 41 54 45 00 00 01 00 |RADIO-UPDATE....|
00000030
Also note the MSM-RADIO-UPDATE after the signature header - it is the start of an unsigned blob.
But what exactly is a blob? In database terminology, it stands for "binary large object" - a bunch of data that is just stored with no further interpretation by the database.The blobs for flashing NVIDIA Tegra devices have a specific structure - they contain one or more raw images to be flashed to one or more partitions on the device.
The full firmware blob for the TF700 contains images for 5 partitions, which we will now extract from the blob. If you don't have blobunpack, get the sources from https://github.com/AndroidRoot/BlobTools - how to do that and how to compile them may be part of another tutorial. I also assume you have blobunpack somewhere in your $PATH.
Code:
[email protected] ~/android/tf700/kernel $ blobunpack blob
Header size: 60
5 partitions starting at offset 0x3C
Blob version: 65536
Partition 0
Name: PT
Offset: 140 (0x8C)
Size: 524288 (0x80000)
Writing file blob.PT (524288 bytes)
Partition 1
Name: EBT
Offset: 524428 (0x8008C)
Size: 1566813 (0x17E85D)
Writing file blob.EBT (1566813 bytes)
Partition 2
Name: SOS
Offset: 2091241 (0x1FE8E9)
Size: 6410496 (0x61D100)
Writing file blob.SOS (6410496 bytes)
Partition 3
Name: LNX
Offset: 8501737 (0x81B9E9)
Size: 5595392 (0x556100)
Writing file blob.LNX (5595392 bytes)
Partition 4
Name: APP
Offset: 14097129 (0xD71AE9)
Size: 805306368 (0x30000000)
Writing file blob.APP (805306368 bytes)
OK, now we have separate files for each partition. The next step is again optional, just to illustrate what happened:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2059512
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
What's inside a firmware blob
blob.APP is a raw image of a Linux ext4 partition. If you are interested in the contents, you can loop mount this file and access all files inside directly on your Linux computer. This is the filesystem that is mounted as /system - the ROM as you all know it.
blob.EBT is the bootloader.
blob.LNX is the boot image - the Linux kernel and the ramdisk, which is later seen as "/". This is the one we are after.
blob.PT is the Tegra partition table. This is a proprietary format, not a PC-compatible partition table.
blob.SOS is the recovery boot image - another Linux kernel and another ramdisk, but this ramdisk contains the stock recovery (incl. the dreaded "dead android").
The boot image
Now, what's actually a boot image, and how do we recognize one if we see one? As usual, the best answer is: look inside! (again - optional, just to learn something)
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blob.LNX
00000000 41 4e 44 52 4f 49 44 21 58 0c 4e 00 00 80 00 10 |ANDROID!X.N.....|
00000010
An Android boot image begins with the text "ANDROID!". Easy.
(maybe sbdags now starts to smack his head and realizes why blobunpack does not work here - and if anyone is still in doubt - a boot image is not a blob)
Splitting a boot image
Good, but how do we crack this thing open? Fortunately there are two small perl scripts I extracted from dsixda's Android kitchen (they are in tools/extract_boot_files):
Code:
[email protected] ~/android/tf700/kernel $ extract-kernel.pl blob.LNX
[email protected] ~/android/tf700/kernel $ extract-ramdisk.pl blob.LNX
1932 blocks
OK, what happened?
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2064524
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
We got a new file (zImage) and a directory (blob.LNX-ramdisk)!
zImage is the kernel image. It is the result of compiling a kernel from sources. Today, we will not compile a new kernel, just repack this image with our modified ramdisk.
What blob.LNX-ramdisk contains should be obvious.
Modifying the ramdisk
Now we can start modifying the ramdisk. A CleanROM ramdisk differs from a stock ramdisk in only 3 files:
- sbin/adbd
- default.prop
- init.rc
sbin/adbd is the adb daemon - the program that handles the tablet's side of the adb protocol. The stock version runs under the "shell" user account, which has limited permissions and cannot access all files on the tablet. The CleanROM version of adbd runs as "root", so "adb push" and "adb pull" can write or read any file on the device, and "adb shell" goes directly to a root prompt.
I don't know where scrosler got this binary from, I just copied it from his CleanROM kernel's ramdisk. You can do the same - now you already know how to extract a ramdisk, so just do the same with the CleanROM kernel in another directory.
default.prop contains only a few lines. Here is the already modified CleanROM version:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
In the original file, ro.secure=1 (which would limit adb to the "shell" account again), ro.debuggable=0 (I'd have to look up what exactly this does), and persist.sys.usb.config=mtp without adb (I think this modification is what automatically enables "USB debugging" at boot time).
Finally, init.rc has a few additional lines to enable init.d support. This means the boot sequence will run any scripts in /etc/init.d - this a simplified version of a usual convention for desktop Linux systems. CleanROM uses it to set up various tweaks (look into /system/etc/init.d on your device).
To illustrate the changes in init.rc, I use the "diff" command (and you can too, if you want - just use the correct paths for your setup instead of mine):
Code:
[email protected] ~/android/tf700/kernel $ diff -u blob.LNX-ramdisk/init.rc ~/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc
--- blob.LNX-ramdisk/init.rc 2013-01-19 19:59:03.000000000 +0100
+++ /home/that/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc 2013-01-19 01:24:43.000000000 +0100
@@ -309,6 +309,8 @@
# Set this property so surfaceflinger is not started by system_init
setprop system_init.startsurfaceflinger 0
+ start sysinit
+
class_start core
class_start main
@@ -413,6 +415,10 @@
user drm
group drm system inet drmrpc sdcard_r
+service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ disabled
+ oneshot
+
service media /system/bin/mediaserver
class main
user media
If you have never read a diff before (also called a patch), here a quick guide:
- Lines beginning with "---" and "+++" identify the two files that were compared.
- Lines beginning with "@@" specify line numbers in the two files. -309,6 +309,8 means: The next block contains 6 lines starting with line 309 from file 1 (---), and 8 lines starting with line 309 in file 2 (+++). In other words, this means that two lines were inserted there.
- The following lines start with a blank - they are context lines. These lines are common in both files and only used to see some context around the change.
- Lines beginning with "+" exist only in file 2 (+++). You can easily remember all this if you know that a diff describes how to edit file 1 to be identical to file 2 - you delete lines marked with "-" and insert lines marked with "+". With only these two operations, you can transform any text file to any other - in the worst case you will delete all lines of the original file and insert all lines of the new file.
The second block works like the first one - here we insert 4 lines near line 413 (which has become line 415 after our first insertion).
You have the following options to apply this change:
1. Simply copy over the changed version from the previous CleanROM kernel. Do a diff before to verify that Asus didn't change anything, otherwise you will undo Asus' changes.
2. Use the "patch" tool to apply the diff file from above. This will automatically perform the edit steps in the diff file and it also has some tolerance if something changed in other sections of the file.
3. Use a text editor and perform the changes manually. If you copy lines from the diff (and not the original init.rc), make sure you don't accidentally copy the leading "+" - this is only for the diff and should not part of the file.
Update 2013-01-21 Start
Unlocking DPI
As usual I don't just tell you how to do it, but some background info first:
There is a read-only system property in Android named "lcd_density" that specifies the display resolution. This is done to ensure that the approximate size of display items is kept consistent across the wide range of devices Android runs on.
For normal users this is great, because they don't have to buy a magnifying glass and a pointed stylus just to use their super-hires-devices, but users here on xda-developers of course see a setting that can be modified and therefore it *must* be modified. Smaller values produce smaller icons and text (and thus more visible content at once); bigger values produce bigger icons and text.
The ASUS stock firmware is not only used on the TF700, but also for several other Transformers. The file /system/build.prop sets ro.sf.lcd_density=160, which means 160 dpi. This is good for the majority of tablets that have 1280*800 displays, but the TF700's display has a resolution of 224 pixels per inch, and with a setting of 160 dpi everything would be very tiny.
The bootloader passes an important parameter to the kernel: "androidboot.productid=0x04", This value depends on the Transformer model, and it is 4 for the TF700. If you look into the ramdisk, there are several files named init.00.rc to init.0d.rc. These are device-specific, and you guessed right if you think that init.04.rc is for the TF700. This file sets lcd_density to 240 dpi, and since it is a read-only property, it keeps its value even if the system's build.prop (which is read later) tries to set lcd_density to 160.
So how do we unlock dpi? Delete the line that says "setprop ro.sf.lcd_density 240" in init.04.rc! Of course this requires you to set the desired dpi value in /system/build.prop. If you install CleanROM Inheritance, you can choose this value in the installer. If you run this kernel with the stock ROM, everything will become very tiny, and now you know why.
Update 2013-01-21 End
Re-packing the boot image
OK, phew, we finally have a modified ramdisk - now we need to repack everything, basically the reverse of the first few steps. For this I use a self-written shell script. First let's just run it:
Code:
[email protected] ~/android/tf700/kernel $ repack-kernel.sh
Found 1 partitions as commandline arguments
Partname: LNX Filename: blob.LNX
Size: 60
1 partitions starting at offset 0x3C
Offset: 76
8+0 records in
8+0 records out
8 bytes (8 B) copied, 0,000136275 s, 58,7 kB/
OK, what happened here? Since I wrote this script myself, I can explain it line by line:
Code:
[email protected] ~/android/tf700/kernel $ cat ~/bin/repack-kernel.sh
#!/bin/bash
~/android/Android-Kitchen/tools/mkboot/mkbootfs blob.LNX-ramdisk | gzip > ramdisk.gz
~/android/Android-Kitchen/tools/mkboot/mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
blobpack blobtmp LNX blob.LNX
echo -n "-SIGNED-BY-SIGNBLOB-" > blob
dd if=/dev/zero bs=1 count=8 >> blob
cat blobtmp >> blob
The ramdisk is repacked and zipped again. This creates ramdisk.gz.
The kernel is merged with the ramdisk to a new boot image, to create blob.LNX. If you paid attention before, yes, this will overwrite the old blob.LNX. If you want, you can check again with hexdump that it is really a boot image (it begins with "ANDROID!").
Re-packing a blob
Now we pack the boot image into a blob. However, the "original" version of blobtools does not create a signed blob. See:
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blobtmp
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010
That was the blob format for the TF101. For later Transformers, we need to prepend a signature header. As we don't have Asus' cryptographic keys, we cannot create a valid signature - but fortunately, since we have an unlocked bootloader, we don't actually need to add a proper signature - the header is enough. There are two ways to create this header - there is a modified version of blobtools in circulation that has a command line option for it, but I do it "manually" with echo and dd.
The final output is again simply called "blob" - this is the new blob that now contains only the kernel. (It overwrites the original blob, which is not really intended, but I just didn't care).
For comparison, now we have this:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 1274980
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 5599336 19. Jän 20:35 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5599232 19. Jän 20:35 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5599308 19. Jän 20:35 blobtmp
-rw-r--r-- 1 that users 479752 19. Jän 20:35 ramdisk.gz
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
Congratulations, you have a flashable blob with your new kernel. But how do you get it onto your device?
Installation
Again, there are two ways:
Installing the blob directly with dd
The first option is to copy the blob to your tablet's staging partition manually and reboot:
Code:
[email protected] ~/android/tf700/kernel $ adb push blob /sdcard/kernel-10.4.4.25.blob
1324 KB/s (5599336 bytes in 4.128s)
[email protected] ~/android/tf700/kernel $ adb shell
sh-3.2# dd if=/sdcard/kernel-10.4.4.25.blob of=/dev/block/mmcblk0p4
10936+1 records in
10936+1 records out
5599336 bytes transferred in 0.129 secs (43405705 bytes/sec)
Be very careful with the dd command and double-check that you didn't swap "if" and "of", and that you specified the correct target partition *before* you hit Enter.
Now reboot your tablet, and the bootloader will flash your new kernel from the blob to the actual kernel partition (notice the progress bar on the boot screen with the slightly broken graphics, as usual). The tablet will reboot again automatically, and if you did everything right, your shiny new kernel will be running!
Creating a zip for flashing in the recovery
OK, now to option 2 - pack the blob into a flashable zip that you can flash in the recovery. The easiest way to do this is to reuse the original firmware zip. Just replace the blob inside the big firmware zip, and that's it - you have a recovery-flashable zip!
Code:
[email protected] ~/android/tf700/kernel $ mv WW_epad-user-10.4.4.25.zip kernel-10.4.4.25.zip
[email protected] ~/android/tf700/kernel $ zip -d kernel-10.4.4.25.zip blob
deleting: blob
[email protected] ~/android/tf700/kernel $ zip kernel-10.4.4.25.zip blob
adding: blob (deflated 1%)
This would not be a good tutorial if I didn't explain how and why this actually works. Let's look inside!
Code:
[email protected] ~/android/tf700/kernel $ unzip kernel-10.4.4.25.zip META-INF/*
Archive: kernel-10.4.4.25.zip
signed by SignApk
inflating: META-INF/com/google/android/resource
inflating: META-INF/com/google/android/rule
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
The core of a flashable zip is the updater-script. For a full firmware, it is very short:
Code:
[email protected] ~/android/tf700/kernel $ cat META-INF/com/google/android/updater-script
assert(package_extract_file("blob", "/tmp/blob"), write_raw_image("/tmp/blob", "staging"),delete("/tmp/blob"));
This line instructs the recovery to extract the blob from the zip file to /tmp/blob and then copy it to the staging partition - essentially it is exactly the same as we did manually in option #1 above!
OK, now the secret is fully disclosed - I hope you learned something. If you have further questions, or if you need help compiling some of the mentioned binaries, don't hesitate to ask (if it's not something like "how do I use the Linux command line" ).

uh huh, uh huh, What?
I think I need to go to blob school....:silly:

_that said:
I firmly believe that this should not be a secret, so I'll explain in detail how to do it and not only give you steps but also a lot of background info. Many steps in the following tutorial are optional and useful for learning, for checking things and for troubleshooting - I don't want you to blindly follow a recipe without understanding what you are doing.
We start with the full firmware, unpacked once - in this case, WW_epad-user-10.4.4.25.zip. First extract the blob from the zip:
Code:
[email protected] ~/android/tf700/kernel $ unzip WW_epad-user-10.4.4.25.zip blob
Archive: WW_epad-user-10.4.4.25.zip
signed by SignApk
inflating: blob
This is a signed blob. It begins with "-SIGNED-BY-SIGNBLOB-". You can check this with hexdump (this step is completely optional, just for illustration):
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 48 blob
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d e9 1a d7 30 00 01 00 00 4d 53 4d 2d |LOB-...0....MSM-|
00000020 52 41 44 49 4f 2d 55 50 44 41 54 45 00 00 01 00 |RADIO-UPDATE....|
00000030
Also note the MSM-RADIO-UPDATE after the signature header - it is the start of an unsigned blob.
But what exactly is a blob? In database terminology, it stands for "binary large object" - a bunch of data that is just stored with no further interpretation by the database.The blobs for flashing NVIDIA Tegra devices have a specific structure - they contain one or more raw images to be flashed to one or more partitions on the device.
The full firmware blob for the TF700 contains images for 5 partitions, which we will now extract from the blob. If you don't have blobunpack, get the sources from https://github.com/AndroidRoot/BlobTools - how to do that and how to compile them may be part of another tutorial. I also assume you have blobunpack somewhere in your $PATH.
Code:
[email protected] ~/android/tf700/kernel $ blobunpack blob
Header size: 60
5 partitions starting at offset 0x3C
Blob version: 65536
Partition 0
Name: PT
Offset: 140 (0x8C)
Size: 524288 (0x80000)
Writing file blob.PT (524288 bytes)
Partition 1
Name: EBT
Offset: 524428 (0x8008C)
Size: 1566813 (0x17E85D)
Writing file blob.EBT (1566813 bytes)
Partition 2
Name: SOS
Offset: 2091241 (0x1FE8E9)
Size: 6410496 (0x61D100)
Writing file blob.SOS (6410496 bytes)
Partition 3
Name: LNX
Offset: 8501737 (0x81B9E9)
Size: 5595392 (0x556100)
Writing file blob.LNX (5595392 bytes)
Partition 4
Name: APP
Offset: 14097129 (0xD71AE9)
Size: 805306368 (0x30000000)
Writing file blob.APP (805306368 bytes)
OK, now we have separate files for each partition. The next step is again optional, just to illustrate what happened:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2059512
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
blob.APP is a raw image of a Linux ext4 partition. If you are interested in the contents, you can loop mount this file and access all files inside directly on your Linux computer. This is the filesystem that is mounted as /system - the ROM as you all know it.
blob.EBT is the bootloader.
blob.LNX is the boot image - the Linux kernel and the ramdisk, which is later seen as "/". This is the one we are after.
blob.PT is the Tegra partition table. This is a proprietary format, not a PC-compatible partition table.
blob.SOS is the recovery boot image - another Linux kernel and another ramdisk, but this ramdisk contains the stock recovery (incl. the dreaded "dead android").
Now, what's actually a boot image, and how do we recognize one if we see one? As usual, the best answer is: look inside! (again - optional, just to learn something)
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blob.LNX
00000000 41 4e 44 52 4f 49 44 21 58 0c 4e 00 00 80 00 10 |ANDROID!X.N.....|
00000010
An Android boot image begins with the text "ANDROID!". Easy.
(maybe sbdags now starts to smack his head and realizes why blobunpack does not work here - and if anyone is still in doubt - a boot image is not a blob)
Good, but how do we crack this thing open? Fortunately there are two small perl scripts I extracted from dsixda's Android kitchen (they are in tools/extract_boot_files):
Code:
[email protected] ~/android/tf700/kernel $ extract-kernel.pl blob.LNX
[email protected] ~/android/tf700/kernel $ extract-ramdisk.pl blob.LNX
1932 blocks
OK, what happened?
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 2064524
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 819403781 22. Mär 2011 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5595392 19. Jän 19:39 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
We got a new file (zImage) and a directory (blob.LNX-ramdisk)!
zImage is the kernel image. It is the result of compiling a kernel from sources. Today, we will not compile a new kernel, just repack this image with our modified ramdisk.
What blob.LNX-ramdisk contains should be obvious.
Now we can start modifying the ramdisk. A CleanROM ramdisk differs from a stock ramdisk in only 3 files:
- sbin/adbd
- default.prop
- init.rc
sbin/adbd is the adb daemon - the program that handles the tablet's side of the adb protocol. The stock version runs under the "shell" user account, which has limited permissions and cannot access all files on the tablet. The CleanROM version of adbd runs as "root", so "adb push" and "adb pull" can write or read any file on the device, and "adb shell" goes directly to a root prompt.
I don't know where scrosler got this binary from, I just copied it from his CleanROM kernel's ramdisk. You can do the same - now you already know how to extract a ramdisk, so just do the same with the CleanROM kernel in another directory.
default.prop contains only a few lines. Here is the already modified CleanROM version:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
In the original file, ro.secure=1 (which would limit adb to the "shell" account again), ro.debuggable=0 (I'd have to look up what exactly this does), and persist.sys.usb.config=mtp without adb (I think this modification is what automatically enables "USB debugging" at boot time).
Finally, init.rc has a few additional lines to enable init.d support. This means the boot sequence will run any scripts in /etc/init.d - this a simplified version of a usual convention for desktop Linux systems. CleanROM uses it to set up various tweaks (look into /system/etc/init.d on your device).
To illustrate the changes in init.rc, I use the "diff" command (and you can too, if you want - just use the correct paths for your setup instead of mine):
Code:
[email protected] ~/android/tf700/kernel $ diff -u blob.LNX-ramdisk/init.rc ~/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc
--- blob.LNX-ramdisk/init.rc 2013-01-19 19:59:03.000000000 +0100
+++ /home/that/android/tf700/cleanrom/blob.LNX-ramdisk/init.rc 2013-01-19 01:24:43.000000000 +0100
@@ -309,6 +309,8 @@
# Set this property so surfaceflinger is not started by system_init
setprop system_init.startsurfaceflinger 0
+ start sysinit
+
class_start core
class_start main
@@ -413,6 +415,10 @@
user drm
group drm system inet drmrpc sdcard_r
+service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ disabled
+ oneshot
+
service media /system/bin/mediaserver
class main
user media
If you have never read a diff before (also called a patch), here a quick guide:
- Lines beginning with "---" and "+++" identify the two files that were compared.
- Lines beginning with "@@" specify line numbers in the two files. -309,6 +309,8 means: The next block contains 6 lines starting with line 309 from file 1 (---), and 8 lines starting with line 309 in file 2 (+++). In other words, this means that two lines were inserted there.
- The following lines start with a blank - they are context lines. These lines are common in both files and only used to see some context around the change.
- Lines beginning with "+" exist only in file 2 (+++). You can easily remember all this if you know that a diff describes how to edit file 1 to be identical to file 2 - you delete lines marked with "-" and insert lines marked with "+". With only these two operations, you can transform any text file to any other - in the worst case you will delete all lines of the original file and insert all lines of the new file.
The second block works like the first one - here we insert 4 lines near line 413 (which has become line 415 after our first insertion).
You have the following options to apply this change:
1. Simply copy over the changed version from the previous CleanROM kernel. Do a diff before to verify that Asus didn't change anything, otherwise you will undo Asus' changes.
2. Use the "patch" tool to apply the diff file from above. This will automatically perform the edit steps in the diff file and it also has some tolerance if something changed in other sections of the file.
3. Use a text editor and perform the changes manually. If you copy lines from the diff (and not the original init.rc), make sure you don't accidentally copy the leading "+" - this is only for the diff and should not part of the file.
OK, phew, we finally have a modified ramdisk - now we need to repack everything, basically the reverse of the first few steps. For this I use a self-written shell script. First let's just run it:
Code:
[email protected] ~/android/tf700/kernel $ repack-kernel.sh
Found 1 partitions as commandline arguments
Partname: LNX Filename: blob.LNX
Size: 60
1 partitions starting at offset 0x3C
Offset: 76
8+0 records in
8+0 records out
8 bytes (8 B) copied, 0,000136275 s, 58,7 kB/
OK, what happened here? Since I wrote this script myself, I can explain it line by line:
Code:
[email protected] ~/android/tf700/kernel $ cat ~/bin/repack-kernel.sh
#!/bin/bash
~/android/Android-Kitchen/tools/mkboot/mkbootfs blob.LNX-ramdisk | gzip > ramdisk.gz
~/android/Android-Kitchen/tools/mkboot/mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
blobpack blobtmp LNX blob.LNX
echo -n "-SIGNED-BY-SIGNBLOB-" > blob
dd if=/dev/zero bs=1 count=8 >> blob
cat blobtmp >> blob
The ramdisk is repacked and zipped again. This creates ramdisk.gz.
The kernel is merged with the ramdisk to a new boot image, to create blob.LNX. If you paid attention before, yes, this will overwrite the old blob.LNX. If you want, you can check again with hexdump that it is really a boot image (it begins with "ANDROID!").
Now we pack the boot image into a blob. However, the "original" version of blobtools does not create a signed blob. See:
Code:
[email protected] ~/android/tf700/kernel $ hexdump -C -n 16 blobtmp
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010
That was the blob format for the TF101. For later Transformers, we need to prepend a signature header. As we don't have Asus' cryptographic keys, we cannot create a valid signature - but fortunately, since we have an unlocked bootloader, we don't actually need to add a proper signature - the header is enough. There are two ways to create this header - there is a modified version of blobtools in circulation that has a command line option for it, but I do it "manually" with echo and dd.
The final output is again simply called "blob" - this is the new blob that now contains only the kernel. (It overwrites the original blob, which is not really intended, but I just didn't care).
For comparison, now we have this:
Code:
[email protected] ~/android/tf700/kernel $ ls -l
total 1274980
-rw-rw-r-- 1 that users 468028852 28. Dez 12:33 WW_epad-user-10.4.4.25.zip
-rw-r--r-- 1 that users 5599336 19. Jän 20:35 blob
-rw-r--r-- 1 that users 805306368 19. Jän 19:39 blob.APP
-rw-r--r-- 1 that users 1566813 19. Jän 19:39 blob.EBT
-rw-r--r-- 1 that users 5599232 19. Jän 20:35 blob.LNX
drwxr-xr-x 8 that users 4096 19. Jän 19:59 blob.LNX-ramdisk
-rw-r--r-- 1 that users 524288 19. Jän 19:39 blob.PT
-rw-r--r-- 1 that users 6410496 19. Jän 19:39 blob.SOS
-rw-r--r-- 1 that users 5599308 19. Jän 20:35 blobtmp
-rw-r--r-- 1 that users 479752 19. Jän 20:35 ramdisk.gz
-rw-r--r-- 1 that users 5114968 19. Jän 19:58 zImage
Congratulations, you have a flashable blob with your new kernel. But how do you get it onto your device?
Again, there are two ways:
The first option is to copy the blob to your tablet's staging partition manually and reboot:
Code:
[email protected] ~/android/tf700/kernel $ adb push blob /sdcard/kernel-10.4.4.25.blob
1324 KB/s (5599336 bytes in 4.128s)
[email protected] ~/android/tf700/kernel $ adb shell
sh-3.2# dd if=/sdcard/kernel-10.4.4.25.blob of=/dev/block/mmcblk0p4
10936+1 records in
10936+1 records out
5599336 bytes transferred in 0.129 secs (43405705 bytes/sec)
Be very careful with the dd command and double-check that you didn't swap "if" and "of", and that you specified the correct target partition *before* you hit Enter.
Now reboot your tablet, and the bootloader will flash your new kernel from the blob to the actual kernel partition (notice the progress bar on the boot screen with the slightly broken graphics, as usual). The tablet will reboot again automatically, and if you did everything right, your shiny new kernel will be running!
OK, now to option 2 - pack the blob into a flashable zip that you can flash in the recovery. The easiest way to do this is to reuse the original firmware zip. Just replace the blob inside the big firmware zip, and that's it - you have a recovery-flashable zip!
Code:
[email protected] ~/android/tf700/kernel $ mv WW_epad-user-10.4.4.25.zip kernel-10.4.4.25.zip
[email protected] ~/android/tf700/kernel $ zip -d kernel-10.4.4.25.zip blob
deleting: blob
[email protected] ~/android/tf700/kernel $ zip kernel-10.4.4.25.zip blob
adding: blob (deflated 1%)
This would not be a good tutorial if I didn't explain how and why this actually works. Let's look inside!
Code:
[email protected] ~/android/tf700/kernel $ unzip kernel-10.4.4.25.zip META-INF/*
Archive: kernel-10.4.4.25.zip
signed by SignApk
inflating: META-INF/com/google/android/resource
inflating: META-INF/com/google/android/rule
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
The core of a flashable zip is the updater-script. For a full firmware, it is very short:
Code:
[email protected] ~/android/tf700/kernel $ cat META-INF/com/google/android/updater-script
assert(package_extract_file("blob", "/tmp/blob"), write_raw_image("/tmp/blob", "staging"),delete("/tmp/blob"));
This line instructs the recovery to extract the blob from the zip file to /tmp/blob and then copy it to the staging partition - essentially it is exactly the same as we did manually in option #1 above!
OK, now the secret is fully disclosed - I hope you learned something. If you have further questions, or if you need help compiling some of the mentioned binaries, don't hesitate to ask (if it's not something like "how do I use the Linux command line" ).
Click to expand...
Click to collapse
Wow! Many thanks! :victory:
Will digest this tomorrow but yes I recognised my smack head moment! :laugh:

Hmmm, my extreme pro 16gb seems to work fine with this kernel. Using/testing it as an external storage, formatted as fat32. Before it wasen't even recognized when inserted. In recovery (twrp) the card is still not recognized but in android (cleanrom 3.1) it works fine.

New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
But still thanks for your work and sorry if it's all sounds not very good...

Blue cat said:
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
Click to expand...
Click to collapse
That's a bit harsh don't you think.

sbdags said:
That's a bit harsh don't you think.
Click to expand...
Click to collapse
Yes,sorry if it's sounds harsh,forgot add in my post gratitude for his work,cant edit next 5 min.I just very want OC and new kernel.

Blue cat said:
Yes,sorry if it's sounds harsh,forgot add in my post gratitude for his work,cant edit next 5 min.I just very want OC and new kernel.
Click to expand...
Click to collapse
_that has only worked on the Asus Stock kernel, for which I am extremely grateful. It gives those users who don't want to OC anything the ability to have a custom rom on the new kernel. From my testing it works better than the old kernel and is very stable.
I will be looking at the Clemsyn kernels in the mean time to see if I can bring them onto the new kernel base and the benefits they bring.
Please be patient, these are not 5 minute jobs. It can take many hours to unpack, decompile, edit, recompile, repack a kernel into a working flashable package. Then we have to test it and live with bootloops and soft bricks if we get it wrong. I can not tell you how many times I have had to restore my Infinity due to one line of code wrong or a badly compiled apk. It's all so you don't have to.
Anyway I'm sure you understand :good: Why don't you read the guides and have a go yourself? Always good to have more people able to do this type of work

sbdags said:
Why don't you read the guides and have a go yourself?
Click to expand...
Click to collapse
I tried to understand,but it's all very hard for me and ok i will be wait your new kernel with OC

Blue cat said:
New kernel from _that so bad,this kernel dont have OC and voltage control,DPI and most important for me balance power mode 1600...performance power mode do nothing.
But i still want asus changes from new kernel.I hope someone create normal kernel like was Clemsyn's kernel or may be _that do this?
Click to expand...
Click to collapse
This is a 100% stock kernel with just a custom ramdisk. Stock kernels never have any of the features you describe here.
Asus have not released their sources for 10.4.4.25 yet, and Clemsyn's kernel sources are a big mess. As soon as sources are released, it is possible to build a new kernel with OC features.
sbdags said:
I will be looking at the Clemsyn kernels in the mean time to see if I can bring them onto the new kernel base and the benefits they bring.
Click to expand...
Click to collapse
Do you have a clue how to build the kernels in your kernel installer from Clemsyn's sources?
sbdags said:
Please be patient, these are not 5 minute jobs.
Click to expand...
Click to collapse
Right, this kernel was more like 10 minutes work. Writing the tutorial took more than 2 hours.

_that said:
Do you have a clue how to build the kernels in your kernel installer from Clemsyn's sources?
/QUOTE]
Nope. Just unpacked yours and clemsyn's. Right, that's not going to happen anytime fast!
:laugh:
Click to expand...
Click to collapse

Great job, _that, you have my sincere thanks. I still cannot find the Thanks button on my screen because of all the blood and brain tissue that got on there when my head exploded. I'll take a walk over to the ED department to get that fixed with a printed plastic cranium, glue it shut, cover it up with a few bandages, get back to my own department and then clean up for a bit. When I finally regain something of a normal level of consciousness I'll try and step into the shadown you throw upon me, and press the damn button.
EDIT: button pressed. Speech still slurring a bit, minor tremor in the left hand and incontinent for both faeces and urine. Apart from that, I'm fine, thanks for asking.
Just kidding, obviously. I've read along, and I get most parts theoretically. Thanks for making me learn -- the most important mental facility we humans have.

Hey very good tutorial
I just unpacked your kernel and take a look inside the ramdisk and repacked the blob.
And it boots up normaly without problems.
Now I am waiting for Asus to release their latest kernel sources that I can modify the kernel itself, too and not only the ramdisk.
Thanks for helping me with that blob stuff!

blackmambazzz said:
Hey very good tutorial
I just unpacked your kernel and take a look inside the ramdisk and repacked the blob.
And it boots up normaly without problems.
Click to expand...
Click to collapse
:good: Great!
blackmambazzz said:
Now I am waiting for Asus to release their latest kernel sources that I can modify the kernel itself, too and not only the ramdisk.
Click to expand...
Click to collapse
Do you have any specific mods in mind?

_that said:
Do you have any specific mods in mind?
Click to expand...
Click to collapse
I think about this features but nothing for sure
more governors
more io-scheduler
compiled with linaro and -o3 optimizations
add fsync control
add oc (by this one i need help I think)
increase readahead

NODPI Update!
Excellent work _that! I will implement the nodpi kernel into the kernel flasher tomorrow and when the odex rom is finished I'll put it in instead of the one there now. :good::good::good:

Thank you, _that, for your hard work. Your kernel seems to be faster than Clemysn's, at least on first sight (scr** the benchmark hippies -- it feels faster, OK? ).
Flashing this was so fast, I thought I had accidentally pressed "reboot system now" instead of actually flashing your kernel. Off to testing a bit more! ; )

[Q] Overlay Error

Hello,
I'm trying to port Ubuntu Touch for Photon Q. I'm posting in this section, because the error I get is generic. My phone fails to boot. The display flickers several times and last_kmsg contains the following message multiple times (the number is consistent with the number of flickers):
Code:
[ 13.802716,0] mdp4_calc_req_mdp_clk: src_h is zero!
[ 13.807477,0] mdp4_overlay_borderfill_stage_down: no base layer at mixer=1
Can someone please tell me what might be causing this error?
Thank you!

Some more information from the log:
Code:
E/Adreno200-GSL( 1138): <ioctl_kgsl_driver_entry:402>: open(/dev/kgsl-3d0) failed: errno 2. No such file or directory
But the device is there:
Code:
ls -l /dev/kgsl*
crw-rw-rw- 1 root root 241, 1 Nov 26 01:08 /dev/kgsl-2d0
crw-rw-rw- 1 root root 241, 2 Nov 26 01:08 /dev/kgsl-2d1
crw-rw-rw- 1 root root 241, 0 Nov 26 01:08 /dev/kgsl-3d0

[GUIDE|HOW-TO|ROOT] Cube iWork 10 i15-TCL - Root / Recovery / Boot.img [WIN|LINUX]

Code:
*** Disclamer
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
Hi guys and girls, as you may know it's pretty easy to find here on xda but on other forums (techablets for example) info and files for rooting this tablet, but who has the TCL variant /which is Dual Boot Type C one) will only find outdates files and complex guides; that's the reason why - after spending a lot of time on bootloops and fails trying to figure how the hell modify the boot.img) I finally decided to share what I found here.
First thing first: this guide collects, improves and updates how-to from Laura of techtablets; I also want to thanks @jetfin and @master.pumpgun (aka Tom on techtablets) - they know why!
I will basically divide this guide per two: first section is READY TO FLASH, where you'll find my own boot.img (from and ONLY for the latest available stock build); before flashing this image file PLEASE be sure to check if your version is the same I had when preparing the image; also you should absolutely check the MD5 of all the files you will download from here:
check MD5 on any Linux distro by simply typing
Code:
md5sum /path/to/file/file
on Windows you could maybe use this tool: WinMD5
The second section is DO IT YOURSELF, and it's for users with a different kernel/build version from mine. I'll try to eventually update the boot.img if we will receive any new OTA, which I think will never happen. I'll write the second section as soon as possible, but I can speed work up if requested and if Cube updates
- - - - - - - - - - -​
---> READY TO FLASH
Code:
PLEASE NOTE
While the general procedure here reported remains
always correct, the files provided in this part of the
guide - specially the modified boot.img may not work
into your device is the kernel and build version are different
from the one I had, so please go to Settings, About tablet
and check if your specs meet mine:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
If you want to root your i15-TCL there's an high chance you would not need nothing more than backup your data, install drivers and adb/fastboot tools and flash file you will download here! BUT you need to have the same kernel and build as I had when prepared the boot.img file, which is the latest at the moment I'm writing. If you know about a newer version lease notify me and I'll try to process it again.
Last but not least, please note that is a pretty long and detailed Guide, I tried to explain and illustrate every single step, also covering some very common issues you may have, so please don't blame on me if it's a long story to read, I'm sure that a few newbies will appreciate
First thing to do is to backup data you want to restore because we need to unlock the bootloader (unfortunately there's no way to achieve the root without that, I tried everything I could but it's not possible). Also a general backup of all your partitions (both Windows both Android) could help and make you feel more comfortable. To backup partition please refer this thread on techtablets: The big threads of how-tos. Windows users could also have to install the proper Intel driver attached to end of the post.
Once you did that install adb/fastboot:
if you use Windows you can use this tool;
if you use a Linux distro please check if the package android-tools (more info here is available for your distro, otherwise you may have to install the official Android SDK (info about that here; no need Android Studio).
Into your tablet go to Settings / About tablet and press 7 times the Build number fields to enable Developer options; now go Back and tap the new voice Developer option: be sure that the main switch is ON and so the OEM unlocking and the USB debugging ones.
Connect your tablet to your PC, open the command prompt or a Linux shell and type
Code:
adb devices
you should receive an output like
Code:
adb devices
List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
0123456789ABCDEF device
If not, please please stop and check previous steps, but also:
If you use Linux and you see a udev error about permissions you have two solutions: one is running the adb/fastboot by root/sudo, another one is to let udev correctly recognize your idVendor and so your device (always prefer this last way, if possible!), which you can do by following this great mini tutorial on StackOverflow
If you use Windows 64bit try to install the driver attached below; don't know if they are also available for 32bit.
Now you have the basic stuff prepared and you are ready to go to fastboot/bootloader, so this is the last time you could check if your build is the same I had, so please do it if you missed that step before. Once more, the info you read from Settings / About tablet have to be
Code:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
Into your command prompt or shell type
Code:
adb reboot-bootloader
Your device will now go to fastboot mode. You can use your Volume Down / Volume Up to move choose menu commands and Power button to pick one. At the moment you don't need to pick any, so check if you have these two lines in red:
Code:
[COLOR="Red"]SECURE BOOT - disabled
LOCK STATE - unlocked[/COLOR]
If you have these exact lines you can jump to step10. My bootloader (and also Tom one) was already unlocked; others people reported it was locked, I guess it depends from where we bought the device. So, if your bootloader has those two red lines (which means the bootloader is already unlocked) go to step 10. If you have similar lines but in white and with different text, go to next step
CAUTION: this will permanently erase your userdata partition, which is where you store the applications and their data; you may also have there downloads, music, videos and photos so BE SURE you updated your relevant stuff!! If want to go further type into your command prompt/shell
Code:
fastboot devices
and check if you have the right output, that is
Code:
0123456789ABCDEF fastboot
If so, go on by typing:
Code:
fastboot oem unlock
This will erase your data and finally unlock the bootloader. you'll see something like that
Code:
...
OKAY
[ 0.162s] finished. total time: 0.162s
Now reboot the bootloader: move between the menu with the Volume rockers and press Power when you selected the Restart bootloader command. Wait for reboot, choose Android and you are on bootloader / fastboot mode again. Now you should absolutely have those two lines in red from step 6.
Download modified boot.img rootboot_mod.img and once finished PLEASE CHECK THE MD5 of the file: it should ABSOLUTELY match this one: 53cc4b08b123489e7c73cb013742f35d
Type on command prompt/shell
Code:
fastboot flash boot /path/to/your/file/rootmod_boot.img
Let the magic happen!
Now download the custom TWRP recovery (courtesy of @vampirefo), check if MD5 is correct (3c05a8704f5a77e20a45364c7a822a2b) and flash it with
Code:
fastboot flash recovery /path/to/your/file/i15_recovery.img
Use the Volume rockers to pick the Recovery mode command and press Power to go to recovery. Swipe to allow modification, go to Mount and tap the System checkbox
Download the latest SuperSu recovery flashable version available here, check the MD5 reported in that page and then from your tablet in recovery tap Advanced and then Adb Sideload. Swipe to let sideload mode start and type into your command prompt / shell (and change the path /opt/android-sdk/platform-tools/ with the path where YOU installed adb/fasboot)
Code:
adb sideload /path/to/your/file/supersu_file_you_downloaded.zip
If you are on Linux and you have udev permissions issues again when sideloading proceed like that
Code:
cd /opt/android-sdk/platform-tools
su
Password:
[email protected]*********:/opt/android-sdk/platform-tools# ./adb kill-server
[email protected]*********:/opt/android-sdk/platform-tools# ./adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]*********:/opt/android-sdk/platform-tools# ./adb devices
List of devices attached
0123456789ABCDEF sideload
[email protected]*********:/opt/android-sdk/platform-tools# ./adb sideload /path/to/your/file/supersu_file_you_downloaded.zip
If you have issues on Windows or still having issues on Linux you can always copy the SuperSu zip to a USB Pen and attach the pen to the tablet using the OTG cable or paste the file to a micro SD.
Reboot your device and it's done!
Doing that instead of using the well know root.bat is much better - IMHO - because we don't have to reboot the device two times and we don't have to uninstall SuperSu and flash a new version to update binaries (SuperSu it is not able to update the binaries by itself, nor by recovery nor by app. Also remember that when a new version os SuperSU will be available: Open SuperSu app, go to Settings and tap on Reinstall. Wait for it to finish and shut down the device. Go to bootloader (or use adb when the device is still on), download latest updated flashable SuperSu zip and flash via recovery).
DOWNLOADS SECTION
rootmod_boot.img
i15_recovery.img
- - - - - - - - - - -​
---> DO IT YOURSELF
WARNING: to do that you need a Linux machine / Virtual machine!
First, be sure to have adb and fastboot working; if issues read the first section for common solutions; you should also have already unlocked your bootloader.
If you did not create a dd backup of your partition I recommend once again to do that; you should at least backup android_boot, android_recovery, android_system (but also consider android_bootloader and android_bootloader2). Please note that to check partition in a human readable mode you can use
Code:
adb shell
ls -las /dev/boot/by-name/*
Now we should create our working folders environment; you can do that by yourself or follow my suggstions.
Open a terminal as normal user; you should be in your home folder; launch the following commands one by one
Code:
mkdir -p Android/iWork10/_working/ ; cd Android/iWork10
mkdir _stockimg ; cd _stockimg
adb shell
su
dd if=/dev/block/by-name/android_boot of=/sdcard/boot.img
cd /sdcard/
md5sum boot.img > bootmd5
exit
please note that you could have to execute the exit command 2 times; just be sure to go back to your terminal into your
Code:
/home/USER/Android/iWOrk10/_stockimg
if su is still not available try to dd the same; for me the bootloader was already unlocked and I had no issue to create the dd image
Then
Code:
adb pull /sdcard/boot.img
adb pull /sdcard/bootmd5
and check if MD5 is OK with
Code:
md5sum -c bootmd5
if error recreate the boot image file, if OK go on.
Now we need to download and extract the Android Bootimg Tools; click this link and save it into the
Code:
/home/USER/Android/
folder; once downloaded (the file it's less than 8 kB) we'll extract the two file in the _working dir so to have all the stuff organized; please note that it's important to keep files organized because we'll decompress and re-compress the boot partition and the kernel it contains; if we don't move files appropriately unneeded stuff could go into the kernel! So please try to understand the process or to follow my steps
Code:
cd ../_working/
tar -zxvf ../../android_bootimg_tools.tar.gz
mkdir bootimg
./unpackbootimg -i ../_stockimg/boot.img -o bootimg/
As you can see we unpacked the stock boot.img to the folder bootimg we just created..
Now let's extract the ramdisk, that is where we were pointing from the start..
Code:
cd bootimg ; mkdir ramdisk ; cd ramdisk
gunzip -c ../boot.img-ramdisk.gz | cpio -i
Now if you are familiar with nano or pico terminal continue on terminal to apply the following mods, otherwise open your file manager to the ramdisk folder, then open the default.prop file and change
Code:
ro.secure=1
to
Code:
ro.secure=0
Save and close the editor.
Open the init.rc file and change
Code:
service media /system/bin/mediaserver
class main
user [COLOR="Red"]media[/COLOR]
to
Code:
service media /system/bin/mediaserver
class main
user [COLOR="Red"]root[/COLOR]
Please note here that if your bootloader was unlocked without your intervention you could have already user root (I had). In that case just leave as it is and close, otherwise save and close.
Go back to your terminal, you should still be into the ramdisk folder, if not navigate with cd to go to that folder and then
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Now we have our new ramdisk; at this point we need to open the boot.img-cmdline file that is located into the bootimg folder and copy its content, then go back to the terminal; the terminal should be still in ramdisk folder, so
Code:
cd ..\..\
and we are into the _working folder.
Now the last command, that you CANNOT simply copy and paste. The command is something like that (hold on, don't execute it)
Code:
./mkbootimg --kernel bootimg/boot.img-zImage --ramdisk bootimg/newramdisk.cpio.gz --cmdline 'CONTENT OF YOUR boot.img-cmdline CONTENT HERE; PUT IT BETWEEN SINGLE ' BOTH AT THE START BOTH AT THE END' -o root_boot.img
Please note the double -- for kernel, ramdisk and cmdline options (while single - for -o that stays for output) and also note the single ' peaks that contain the boot.img-cmdline content.. So in my case it will be:
Code:
./mkbootimg --kernel bootimg/boot.img-zImage --ramdisk bootimg/newramdisk.cpio.gz --cmdline 'loglevel=5 androidboot.hardware=cht_cr_mrd_w firmware_class.path=/system/etc/firmware i915.fastboot=1 memmap=4M$0x5c400000 vga=current i915.modeset=1 drm.vblankoffdelay=1 enforcing=0 androidboot.selinux=permissive console=ttyS0,115200n8 bootboost=1 pm_suspend_debug=1 pstore.backend=ramoops' -o ../root_boot.img
BUT PLEASE DON'T COPY AND PASTE THIS ONE; JUST USE YOUR boot.img-cmdline FILE (I'm pretty sure they are identical but cannot be sure, SO USE YOURS)
If the command doesn't give errors or the standard output that describe the usage of a linux command (so like usage: mkbootimg --kernel <filename> --ramdisk <filename> - this means you missed something) we are done, we just need to flash it and root. So we now have our modified boot image which will let the tablet boot a rooted OS without bootloop.
If you haven't do it already go to download latest Recovery Flashable zip of SuperSU from SuperSu webpage and the custom TWRP recovery for this device that you find in the first section (also check MD5) and copy both to your internal of external sdcard (if you are not familiar with sideload)
Reboot your device to bootloader with
Code:
adb reboot-bootloader
Once it's there,
Code:
fastboot flash boot /home/USER/Android/iWork10/root_boot.img
fastboot flash recovery /path/where/you/downloaded/recovery.img
Now use the volume rockers to pick RECOVERY MODE option and press the Power button. The device will boot the TWRP recovery; allow system modifications when asked and finally flash the SuperSu zip file you downloaded and copied to the tablet (or use adb sideload /path/to/supersu/into/your/pc/supersufile.zip)
You may need to adjust settings in TWRP (timezone and language), then reboot the system and you should have rooted your i15-TCL!
It's easy, isn't it?
PLEASE NOTE: If you have errors like adb, fastboot not recognizing your device, don't ask but read the other section where I explain the most common solution for Windows and Linux; same if you don't find links for recovery, SuperSU or other read the first section, thanks!
- - - - - - - - - - -​
THANKS
@jetfin for providing a lot of goodies that saved my ****** last month (wish you all the best for the next future mate!)
@master.pumpgun (aka Tom on techtablets - amazing guy! :good
@vampirefo for custom TWRP for this device
Laura - for all the info she's made available for this device

Great job mate!
It seems very analytical and very useful for people who need a step by step guide.
Unfortunately it requires a full wipe of user data, so for now I am not willing to try this guide.
Sent from my i15-TCL using Tapatalk

RASTAVIPER said:
Great job mate!
It seems very analytical and very useful for people who need a step by step guide.
Unfortunately it requires a full wipe of user data, so for now I am not willing to try this guide.
Sent from my i15-TCL using Tapatalk
Click to expand...
Click to collapse
Well, I feel you, unlocking is always annoying but there are apps which let you backup everything.
I couldn't live without root + Link2SD into the cube!
Thanks for the nice words ?
Inviato dal mio Nexus 7 utilizzando Tapatalk

Hi brainvison,
it`s a nice, correct and clear tutorial, many thanks.
Only one question
Fortunately I have an unlocked bootloader, then I`ll do it from step 10, but I have a same kernel and build version (3.14.37/x86_64-L1-R517 and V1.0) but the date of this version is different (20160913).
What do you suggest, try it? Or could you help me to create a new version of the boot.img, please?
Nice regards
Peter
brainvision said:
Code:
PLEASE NOTE
While the general procedure here reported remains
always correct, the files provided in this part of the
guide - specially the modified boot.img may not work
into your device is the kernel and build version are different
from the one I had, so please go to Settings, About tablet
and check if your specs meet mine:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
Click to expand...
Click to collapse
​

rpeter said:
Hi brainvison,
it`s a nice, correct and clear tutorial, many thanks.
Only one question
Fortunately I have an unlocked bootloader, then I`ll do it from step 10, but I have a same kernel and build version (3.14.37/x86_64-L1-R517 and V1.0) but the date of this version is different (20160913).
What do you suggest, try it? Or could you help me to create a new version of the boot.img, please?
Nice regards
Peter
Click to expand...
Click to collapse
both kernel and build dates are different, aren't them?
I'll try to write the missing section as soon as possible, don't worry..
In the meantime could you please check a few things that could help to understand a few things?
If your bootloader is unlocked you should have no issue doing that; assuming you already have adb working, open a terminal and execute this commands (just "read" commands, no mods here)
Code:
adb shell
uname -a
cat default.prop
If errors try to execute adb root (this does NOT root, it just use adb as root user, it should work with the unlocked bootloader) before adb shell and if possible please report me the output from unameand cat
EDIT: also my advice is to backup your system partitions so to able to go back to stock if needed; at least partitions
Code:
android_boot
android_bootloader
android_bootloader2
android_recovery
android_system
To do that you could check Laura's thread from techtablets or use
Code:
dd if=/dev/by-name/your_partition of=/sdcard/your-partition.img
the if= option is where you choose the partition to backup while the of= one is the resulting file that will be created (an image .img file)
If you agree you could also upload those somewhere on the cloud so we could use them, too, it would be interesting to see what changes.. Naturally the partition I suggested do not contain any personal file, no worry about that (your data is on the android_userdata - or _data, don't remember the name here).
EDIT2: you'll need a Linux machine to mod your boot.img partition, do you have one?

brainvision said:
both kernel and build dates are different, aren't them? yes, both of the are the same date:20160913
the build.prop is:
Code:
[email protected]:/system # cat build.prop
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=LMY47I
ro.build.display.id=i15-TCL_V1.0_20160913
ro.build.version.incremental=eng.softteam.20160913.102513
ro.build.version.sdk=22
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=5.1
ro.build.version.security_patch=2016-03-01
ro.build.version.base_os=
ro.build.date=Tue Sep 13 10:26:20 CST 2016
ro.build.date.utc=1473733580
ro.build.type=userdebug
ro.build.user=softteam
ro.build.host=pdd-build
ro.build.tags=release-keys
ro.build.flavor=cht_cr_mrd_w-userdebug
ro.product.model=i15-TCL
ro.product.brand=i15-TCL
ro.product.name=cht_cr_mrd_w
ro.product.device=i15-TCL
ro.product.board=i15-TCL
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=x86
ro.product.cpu.abilist=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist64=
ro.product.manufacturer=i15-TCL
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=gmin
# ro.build.product is obsolete; use ro.product.device
ro.build.product=cht_cr_mrd_w
# Do not try to parse description, fingerprint, or thumbprint
ro.build.description=cht_cr_mrd_w-userdebug 5.1 LMY47I eng.softteam.20160913.102513 release-keys
ro.build.fingerprint=intel/cht_cr_mrd_w/cht_cr_mrd_w:5.1/LMY47I/softteam09131026:userdebug/release-keys
ro.build.characteristics=tablet
# end build properties
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.dalvik.vm.isa.arm=x86
ro.enable.native.bridge.exec=1
sys.powerctl.no.shutdown=1
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=100m
dalvik.vm.heapsize=174m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m
ro.opengles.version=196609
ro.setupwizard.mode=OPTIONAL
ro.com.google.gmsversion=5.1_r1
ro.gnss.sv.status=true
ro.hwui.texture_cache_size=24.0f
ro.hwui.text_large_cache_width=2048
ro.hwui.text_large_cache_height=512
drm.service.enabled=true
keyguard.no_require_sim=true
ro.com.android.dataroaming=true
ro.com.android.dateformat=MM-dd-yyyy
ro.config.ringtone=Ring_Synth_04.ogg
ro.config.notification_sound=pixiedust.ogg
ro.carrier=unknown
ro.config.alarm_alert=Alarm_Classic.ogg
persist.sys.language=zh
persist.sys.country=CN
persist.sys.timezone=Asia/Shanghai
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.x86.features=sse4_2,aes_in,popcnt,movbe
dalvik.vm.lockprof.threshold=500
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
# begin fota properties
ro.fota.platform=IntelZ3735F_5.1
ro.fota.id=mac
ro.fota.type=pad_phone
ro.fota.oem=hampoo-cherrytrail_5.1
ro.fota.device=i15-TCL
ro.fota.version=i15-TCL_V1.0_20160913
# end fota properties
[email protected]:/system #
I'll try to write the missing section as soon as possible, don't worry..
Many thanks
Code:
adb shell
uname -a
cat default.prop
the adb root and the cat is ok, but the uname is not found
the output of the cat is:
Code:
127|[email protected]:/ # cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.sf.lcd_density=240
ro.frp.pst=/dev/block/by-name/android_persistent
persist.intel.ogl.username=Developer
persist.intel.ogl.debug=/data/ufo.prop
persist.intel.ogl.dumpdebugvars=1
ro.ufo.use_msync=1
ro.ufo.use_coreu=1
wifi.interface=wlan0
persist.service.apklogfs.enable=1
persist.core.enabled=0
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=1
ro.modules.location=/lib/modules
ro.dalvik.vm.native.bridge=libhoudini.so
persist.sys.usb.config=mtp,adb
persist.nomodem_ui=true
ro.zygote=zygote32
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=256m
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
[email protected]:/ #
EDIT: also my advice is to backup your system partitions so to able to go back to stock if needed; at least partitions
Code:
android_boot
android_bootloader
android_bootloader2
android_recovery
android_system
All of my partitions expect the largest one(maybe windows) were backed up to sd with dd
If you agree you could also upload those somewhere on the cloud so we could use them, too, it would be interesting to see what changes.. Naturally the partition I suggested do not contain any personal file, no worry about that (your data is on the android_userdata - or _data, don't remember the name here).
I will upload it to somewhere, but which partitions are you need (i don't no clearly, how can I determinate, which partition is the boot, bootloader, ...)
the outputs of the /proc/partitions are the following:
Code:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 102400 zram0
179 0 61071360 mmcblk0
179 1 102400 mmcblk0p1
179 2 102400 mmcblk0p2
179 3 30720 mmcblk0p3
179 4 30720 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 16384 mmcblk0p6
179 7 2621440 mmcblk0p7
179 8 262144 mmcblk0p8
179 9 8388608 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 102400 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 48361472 mmcblk0p14
179 15 1024000 mmcblk0p15
179 48 4096 mmcblk0rpmb
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 64 15671296 mmcblk1
179 65 15667200 mmcblk1p1
253 0 2600764 dm-0
maybe the *p3 is the bootloader, the *p14 is the windows, maybe the *p9 included the data and *p7 is the system, but don't know, which one is the boot, bootloader2, recovery
EDIT2: you'll need a Linux machine to mod your boot.img partition, do you have one?
Click to expand...
Click to collapse
yes, I have, a debian.
One question, if we have any problem with the upload the modified bootloader, how can i restore the old one (how can I upload (which method, adb, fastboot, or the phone flash?) an original bootloader, if we have a problem with the modded bootloader)
Have you link(s) with the full original windows and andoid image of the i15-tcl? I found to i15-t, i15-td, but not for this version...
Nice regards
Peter

i have the same software version as rpeter. When i first boot in fastboot my bootloader was unlocked and secure boot was disabled. Itried flash twrp and it was succesful. Next i downloaded superSu zip from official website and i flashed it. After reboot i stuck at bootlogo. Can you share me a system image to restore?

The mmcblk0p9 partition is the system? I will share it as soon as possible.

07 is system. 09 is data partition.
https://drive.google.com/file/d/0B_QRR9kog1iZQ2ZaNzdZenQ4MkE/view?usp=sharing

@rpeter I'll read your long reply asap, now just want to tell you that to check partition in a human readable way you should use
Code:
ls -las /dev/block/by-name/*
the partition I would like you to share are
Code:
android_boot
android_bootloader
android_bootloader2
android_system
android_recovery
when using dd of course as I told you can directly point to that name convention (which are nothing but symbolic link) so
Code:
dd if=/dev/block/by-name/android_boot of=/sdcard/android_boot.img
this is for the boot partition, the other the same..
also please before uploading to cloud check the MD5 so we could verify it before installing
are you sure you wrote uname -a the right way? It's weird you don't have it...
About restoration, you could use fastboot in future, I tried it by myself.. the most important are
Code:
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
I don't think we'll ever need the two bootloader restoration, it's just to go extremely safe but I still don't find a reason to flash them.. But backup anyway!
EDIT: please note the .img extension for the of= part of the dd command!
@boberq sorry for your issue but I have to say that it was obvious: it's not plenty of guides and how-to about this tablet but the few available are also easy to find, and they all clearly state that you need to modify the boot image before rooting, otherwise as you know now, bootloop!
so, if you guys need to immediately root you can send me the boot.img file and I do it for you, otherwise you can wait and do it by yourself - I'm going to write the how-to right now, it should be ready for tomorrow, I guess..
EDIT and yes, we don't have any full restoation image like for other variants, I asked them on Twitter https://twitter.com/CubeHeping (it seems this is their official account that I found via www.51cube.com) - please do the same, maybe they will listen to us

I flashed i15 td rom and it works without auto rotation. If rpeter share images i want flashthe stock.
---------- Post added at 12:52 PM ---------- Previous post was at 12:44 PM ----------
I flashed a i15td rom and everything is fine without auto rotate. Rpeter please share boot and system images, they help me to restore the stock rom.
Ps After first boot if i want enter to recovery , it show red triangle with green android. There was any recovery.

boberq said:
I flashed i15 td rom and it works without auto rotation. If rpeter share images i want flashthe stock.
---------- Post added at 12:52 PM ---------- Previous post was at 12:44 PM ----------
I flashed a i15td rom and everything is fine without auto rotate. Rpeter please share boot and system images, they help me to restore the stock rom.
Ps After first boot if i want enter to recovery , it show red triangle with green android. There was any recovery.
Click to expand...
Click to collapse
stock recovery is not a real recovery there.. Red triangle is the right thing.. BUT if you flashed the custom TWRP with
Code:
fastboot flash recovery recovery.img
you should have noticed that the process failed.. I don't remember the exact output but you should have seen FAILED instead of SUCCESS. If flash succeed you also need stock recovery, I guess, otherwise it should still bootloop after system restore..

@brainvision
Has anything changed about rooting?
I remember that the process was involving resetting in order to unlock bootloader, etc
Sent from my m1 note using Tapatalk

RASTAVIPER said:
@brainvision
Has anything changed about rooting?
I remember that the process was involving resetting in order to unlock bootloader, etc
Sent from my m1 note using Tapatalk
Click to expand...
Click to collapse
nope, and it never will in that direction..
you should definitively make a backup, the more you'll wait the worst it'll be!

I flashed twrp and from it i want flash supersu and i get bootloop. After this i flashed i15td rom andeverything works fine. So can i flash boot,recovery and system image and get stock without root? Or should i flash it using intel flash tool?

boberq said:
I flashed twrp and from it i want flash supersu and i get bootloop. After this i flashed i15td rom andeverything works fine. So can i flash boot,recovery and system image and get stock without root? Or should i flash it using intel flash tool?
Click to expand...
Click to collapse
you can flash them with fastboot indeed and then root again, I finished writing my how-to, I'm formatting it and update the first post in an hour max..
Never looked at Intel Flash Tool, I don't know if it permits the flash of a single partition or if you need a full image provided by OEM, can't help with that..

So i'm waiting for original images from rpeter and i'm goind to flash it. I have a twrp backup with original 20160913 firmware but after bootloop. I can sare it but i think it isnt usefull.
PS
Brainvision , can you share me your original partition images for i15TCL from May? I think it will repair my autorotation.

boberq said:
So i'm waiting for original images from rpeter and i'm goind to flash it. I have a twrp backup with original 20160913 firmware but after bootloop. I can sare it but i think it isnt usefull.
PS
Brainvision , can you share me your original partition images for i15TCL from May? I think it will repair my autorotation.
Click to expand...
Click to collapse
I do NOT recommend you to flash that because you will completely mess things up, having boot, recovery and kernel with a build date and system with a different one! You went to fast on rooting your device without reading stuff, now I suggest you to wait for @rpeter images - but anyway here it is system.img https://mega.nz/#!YBdw1bIT!GibOWLBNyXAhwEiEdXIV3JKKdMM9gXzLIYvppKn0Bgs
EDIT: guys I updated OP with the missing sectioon, please click thanks if you find it useful..
@rpeter before rooting remember to backup partition with dd, then upload when you can but backup before rooting!
if you have suggestion for the guide or you think something is not so clear please tell me that I'll try to improve..

brainvision, boberq, I'm so sorry, yesterday is one of my longest working day...
My gdrive is currently full, bu I created a dedicated place for yours in my server.
The link is: http://rpeter.dyndns.info/xda
user: xda_users
pwd: i15-tcl
It's included all partitions compressed and uncompressed version expect p9 and p14 (data and windows) and the md5 checksum file.
The output of the "identification" is here:
Code:
127|[email protected]:/ # ls -las /dev/block/by-name/*
lrwxrwxrwx root root 2016-11-12 12:21 Basic_data_partition -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-11-12 12:21 EFI_system_partition -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-11-12 12:21 Microsoft_reserved_partition -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-11-12 12:21 android_boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader2 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-11-12 12:21 android_cache -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-11-12 12:21 android_config -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-11-12 12:21 android_data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-11-12 12:21 android_metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-11-12 12:21 android_misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-11-12 12:21 android_persistent -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-11-12 12:21 android_recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-11-12 12:21 android_system -> /dev/block/mmcblk0p7
[email protected]:/ #
I will put it somewhere fastest place, when I have enough time to do it
Nice regards
Peter

rpeter said:
brainvision, boberq, I'm so sorry, yesterday is one of my longest working day...
My gdrive is currently full, bu I created a dedicated place for yours in my server.
The link is: http://rpeter.dyndns.info/xda
user: xda_users
pwd: i15-tcl
It's included all partitions compressed and uncompressed version expect p9 and p14 (data and windows) and the md5 checksum file.
The output of the "identification" is here:
Code:
127|[email protected]:/ # ls -las /dev/block/by-name/*
lrwxrwxrwx root root 2016-11-12 12:21 Basic_data_partition -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-11-12 12:21 EFI_system_partition -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-11-12 12:21 Microsoft_reserved_partition -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-11-12 12:21 android_boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader2 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-11-12 12:21 android_cache -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-11-12 12:21 android_config -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-11-12 12:21 android_data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-11-12 12:21 android_metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-11-12 12:21 android_misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-11-12 12:21 android_persistent -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-11-12 12:21 android_recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-11-12 12:21 android_system -> /dev/block/mmcblk0p7
[email protected]:/ #
I will put it somewhere fastest place, when I have enough time to do it
Nice regards
Peter
Click to expand...
Click to collapse
great work mate!
Thanks a lot. As you may have read I updated the OP with the new section, hope you'll find useful and clear enough, if not don't hesitate to ask, it will be a pleasure to help and to improve the how-to