Related
I have searched, read, and tested my butt off on this so, I'm not posting without doing my own homework. I promise.
I'm looking for CURRENT documentation on how to create a standard update.zip file that simply copies a file into /system/foo/bar and chmods it.
All the links I've looked at seem to have old deprecated syntax on the update-script file, or the examples given simply do not work.
I do NOT want to download someone else's script-pak, windows app, or any other such thing that makes it for me.
As for signing, I'm completely comfortable signing using the SDK, although I'll probably take the easy route with ZipSigner/Signapktic running on the phone/tab now that I've discovered those.
Can someone please post a very simple howto?
Thanks for posting this -- I'm with you, I'm not a script-kiddie using someone else's tools, I want to learn it for myself, but like you, I've searched, and what I've found -- while probably correct and accurate -- isn't working the way they say it should. I've even followed the directions on android.com itself and they fail, so I'm starting to suspect my recovery or my ROM is at fault, not the signing itself.
I have a bunch of files I want to place in /system/foo/bar and chmod, as you say, and the error I'm getting is "No signature (172 files) Verification Failed". I do indeed have signatures in the file, as when I open them I see CERT.RSA and others that weren't there before signing, so IDK what the deal is with the error I'm getting (obviously something's missing -- maybe a public key verification from a trusted authority like Thawte or VeriSign).
I see you, too, are getting as much help as I am seeing others get. They start threads, get all sorts of praise from script kiddies who have no clue and just see a point-click solution, and then someone asks for real help and everyone shuts up for months until the thread eventually dies.
But kudos to you, sir, for being in the same boat as I!
cj chitwood said:
Thanks for posting this -- I'm with you, I'm not a script-kiddie using someone else's tools, I want to learn it for myself, but like you, I've searched, and what I've found -- while probably correct and accurate -- isn't working the way they say it should. I've even followed the directions on android.com itself and they fail, so I'm starting to suspect my recovery or my ROM is at fault, not the signing itself.
I have a bunch of files I want to place in /system/foo/bar and chmod, as you say, and the error I'm getting is "No signature (172 files) Verification Failed". I do indeed have signatures in the file, as when I open them I see CERT.RSA and others that weren't there before signing, so IDK what the deal is with the error I'm getting (obviously something's missing -- maybe a public key verification from a trusted authority like Thawte or VeriSign).
I see you, too, are getting as much help as I am seeing others get. They start threads, get all sorts of praise from script kiddies who have no clue and just see a point-click solution, and then someone asks for real help and everyone shuts up for months until the thread eventually dies.
But kudos to you, sir, for being in the same boat as I!
Click to expand...
Click to collapse
See my other reply to you in a similar topic.
I may be wrong but dont you have to sign system apps with the same key that the rom was signed with.
You can compile and sign from source and then add system apps or data
From something awesome
killersnowman said:
I may be wrong but dont you have to sign system apps with the same key that the rom was signed with.
You can compile and sign from source and then add system apps or data
From something awesome
Click to expand...
Click to collapse
System apps must be signed using the same key that is used to sign the platform. This has nothing to do with the ZIP signature that may or may not be present on a recovery update. The actual platform public key is stored within the ROM and gets extracted just like any other file in the system image.
If you compile from source, you use the platform key provided in the source; typically: build/target/product/security/platform.x509.pem. If you are an OEM like say HTC, you'll use your own key to compile the platform and sign the system apps.
Gene Poole said:
System apps must be signed using the same key that is used to sign the platform. This has nothing to do with the ZIP signature that may or may not be present on a recovery update. The actual platform public key is stored within the ROM and gets extracted just like any other file in the system image.
If you compile from source, you use the platform key provided in the source; typically: build/target/product/security/platform.x509.pem. If you are an OEM like say HTC, you'll use your own key to compile the platform and sign the system apps.
Click to expand...
Click to collapse
So in order to put ringtones in the appropriate system folder, I have to sign the update.zip with the same key that e.g. Roalex uses to sign the ROM? Of course that won't work, as I don't have his key, and then there are kernels and themes that other people make that work, and surely they don't have Roalex's key.
So I think I'm misunderstanding this still.
But if I compile from source, I sign with the key that's in the source, so if I know Roalex compiles from source, if he signs with the source key, I can sign an update.zip with that key and it will work?
Also, Recovery says there is NO signature in the file, but does that not necessarily mean really what it says?
I don't know who Roalex is. I don't know anything about your device per se. I don't know anything about Amon-Ra recovery. I was hoping some others would jump into this thread to help out with these unknowns. I've always used clockworkmod recovery so that's all I can speak for, but I did D/L an Amon-Ra recovery to analyze it.
As far as custom ROMs go, most are based on some OEM ROM and still contain system files signed by the OEM and the OEM certs are still included with the ROM so no modifications are necessary.
If you have a simple update.zip with just some files to be written to the system partition, then signing the update.zip file is unnecessary. A signed update.zip is only useful when it is distributed by an OEM with an official OEM update since the stock recovery will refuse anything not signed by the OEM. One of the reasons for using a custom recovery on rooted devices is that it gets around this security check to allow you to install custom stuff written by someone other than the OEM.
If you are having trouble installing an update.zip that contains an otherwise valid working "amend" or "edify" script, then I don't know what the issue might be. Clockworkmod recovery (at least all the versions I've run) has an option to toggle signature checks in the "apply update from SD card" sub-menu, but I don't know of any good reason that it is there since it only has one key and it is the same "test" key distributed in official source distributions, and the toggle is off by default.
I've been poking around github and grabbed the current source for amon-ra recovery (https://github.com/packetlss/amonra_bootable_recovery) and interestingly, amon-ra has a signature verifyer that is missing from clockworkmod recovery. It actually parses the zip file for the META information and ensures that the included signing key for the zip is consistent with the manifest and each file's signature.
So, it would seem that your update.zip should be signed the same way an APK is signed, using jarsigner.
Do you have a valid signing certificate and are you signing your update.zip correctly?
After learning to compile cm from source I found it easiest just to edit the .zip and then resigning the zip. I have added a few programs into /system and never had an issue. Perhaps this is because it's cm?
Gene Poole said:
I've been poking around github and grabbed the current source for amon-ra recovery (https://github.com/packetlss/amonra_bootable_recovery) and interestingly, amon-ra has a signature verifyer that is missing from clockworkmod recovery. It actually parses the zip file for the META information and ensures that the included signing key for the zip is consistent with the manifest and each file's signature.
So, it would seem that your update.zip should be signed the same way an APK is signed, using jarsigner.
Do you have a valid signing certificate and are you signing your update.zip correctly?
Click to expand...
Click to collapse
i was just going to conjecture that perhaps the amon-ra recovery is verifying sigs. you however have found proof. thank you
the only way someone would have the valid sig is for it to either be public, or for them to have signed the platform themselves and have there own private key. i ran into this same problem when investigating the android.intent.action.REBOOT intent which can only be broadcast by system apps signed with the same sig as the platform.
Gene Poole said:
I don't know who Roalex is [...]
Click to expand...
Click to collapse
Sorry, he's the guy who put together the COS-DS ROM for G1/HTC Dream based on CyanogenMod and AOSP sources.
Gene Poole said:
As far as custom ROMs go, most are based on some OEM ROM and still contain system files signed by the OEM and the OEM certs are still included with the ROM so no modifications are necessary.
Click to expand...
Click to collapse
Wait... can signing the zip be as easy as including the CERT.MSA and related other two files as found in the other update.zip files I have that work? Seems that would be too easy... I assumed there would be something in the zip file headers that would be modified to reflect a key as well so that they would also have to match. Maybe this is getting too in-depth...
Gene Poole said:
If you have a simple update.zip with just some files to be written to the system partition, then signing the update.zip file is unnecessary.
Click to expand...
Click to collapse
So just put together a common zip file with the update-script and the right folder structure in it, and I'm good? I tried that too and it also failed. Does the NAME of the file have to be update.zip in that case, though? I didn't actually try that. My unsigned one was named "CJ-Audio-Update_unsigned.zip" or something like that.
Gene Poole said:
A signed update.zip is only useful when it is distributed by an OEM with an official OEM update since the stock recovery will refuse anything not signed by the OEM. One of the reasons for using a custom recovery on rooted devices is that it gets around this security check to allow you to install custom stuff written by someone other than the OEM.
If you are having trouble installing an update.zip that contains an otherwise valid working "amend" or "edify" script, then I don't know what the issue might be. Clockworkmod recovery (at least all the versions I've run) has an option to toggle signature checks in the "apply update from SD card" sub-menu, but I don't know of any good reason that it is there since it only has one key and it is the same "test" key distributed in official source distributions, and the toggle is off by default.
Click to expand...
Click to collapse
Okay then. From here it's a lot clearer than a week ago. Thanks for taking the time to explain it so thoroughly... I think so many people understand so little and they're so quick to say "here, just use this other guy's tool LOL!!!111!1 he r0x0r$!!!1!1". I mean, that's great, that there are tools, but I want to understand it, not just be a script kiddie with someone else's tools, blindly trusting that they're doing it right and all that. Not saying the tools are bad or wrong, but by knowing myself, I know whether it's done right, you know? Same reason I learned automotive mechanicals, computers, and electrical wiring. Oh, and plumbing is slowly being added and in a few years roofing
Then it's on to framing as I build a 20-by-20-foot "workshop" in the back yard but I digress...
Thanks again!
Well this is interesting...
I took the MSA and other two files from the COS-DS update, and put them in a new zip containing my other files (not signed) and it didn't complain about no signature... instead, it failed saying some lib file is missing. Stagefright or some such. Progress is still progress though...
EDIT:
Okay, so it looks like there's something in those signats that says, "hey, look for all these other files too", so I'ma try a different tack...
EDIT2:
I guess I'm just gonna have to use Testkeys. They appear to have worked. :/ But if everyone else is doing it that way, I guess there's no harm.
I flashed the UK sbf via RSDLite and then when I tried flashing the brazil sbf again I could not, right now I can no longer flash via RSDLite. Keeps on gettiing a 0x71000 error.
info5i2002 said:
I flashed the UK sbf via RSDLite and then when I tried flashing the brazil sbf again I could not, right now I can no longer flash via RSDLite. Keeps on gettiing a 0x71000 error.
Click to expand...
Click to collapse
I was running into the same problem, with Win7 x64, RSD Lite 4.6, latest drivers. Did some investigation into the error log and looks like I found a bug in their programming. Go into the directory you installed RSD Lite (for Win7 x64 the default is C:\Program Files (x86)\Motorola\RSD Lite\) and look for a file that starts with "FlashErrorLog". Open it, and if you see something like this:
Code:
Code:
Line: 865
ERROR: \\?\c:\SPRecovery_ESE81.sbfwtƒyoþÿÿÿ‚qawñrawðiµ was not found.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashFi leIO.cpp
then you are experiencing this same bug that I had (looks like adr3nalin3 had this problem too). For those fellow programmers out there, looks like they are copying the filename into uninitialized memory and not explicitly adding the NULL terminator, meaning it's pure luck whether the filename is recognized or not. Since the uninitialized memory produces random results, this explains why people have had it work after restarting their computer, trying several times, using a different computer, etc. Hopefully if you follow my instructions below, you will be able to make it work right away.
So the work around for this problem is to rename the file so that the real filename overwrites all the unwanted junk characters at the end. These junk characters are random, and they are likely to change each time you open RSD Lite.
Here are step by step instructions:
Go to the folder where you installed RSD Lite
Delete any files that start with "FlashErrorLog"
Right click on "SDL.exe" and click "Run As Administrator"
Move your recovery file to the root C:\ directory
Rename the recovery file to something short, like "r.sbf", so that you will have space left for the filename to overwrite the junk characters
Try flashing the file with RSD Lite - it will most likely fail, don't worry (if it works then good job, you are lucky )
In the RSD Lite folder, open the newly created FlashErrorLog... file
Count the number of junk characters after the real filename - for example if you have this error:
Code:
Code:
ERROR: \\?\c:\r.sbfqawñraï was not found.
then the junk characters are "qawñraï" and there are 7 of them, so we are going to add 7 extra letters to the real filename
Rename the file to add the same number of letters/numbers as junk characters in the log file. In this case, we need to add 7, so change the filename to something like "r1234567.sbf" - make sure you add the characters BEFORE the file extension (".sbf"), not after!
Point RSD Lite to the renamed file, click Start, and it should work!
Note that some of the junk characters can't be displayed in the log, so there might actually be 8 of them when you can only see 7, etc. Just repeat the process from step 6, adding 1 character at a time (don't remove any), and it should work after a few tries.
Note that just making the filename really long won't work, you need to be precise so that you only overwrite the extra stuff, nothing more and nothing less.
Click to expand...
Click to collapse
Find Original post here: http://androidforums.com/droid-all-things-root/74153-if-you-get-failed-flashing-process-0x7100-rsd-lite.html
At #32 reply.
I just mis-clicked thanks when I want to quote your post.
Haha I returned the favour by thanking you too. By the way, all I had to do was to delete the error logs and then enter the
Code:
cd C:\Program Files\Motorola\RSDlite\
SDL.exe -f [FILENAME].sbf -t 2
and it starting flashing again.
Good luck!
I know this is a pissed off issue by many of you but I want to use my archos as an industrial tablet.
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
br, sodjas
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Sad news modinfo shows:
alias: char-major-10-243
license: Proprietary
description: flashrw
author: Archos
depends:
vermagic: 2.6.10_mvl402 ARMv5 gcc-3.4
It is Proprietary
Hi sodjas,
you should do a little more research on this issue.
sodjas said:
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
Click to expand...
Click to collapse
As you started to point out, there are different bootlogos for the differnt stages on start-up.
1. bootloader logo
2. ramdisk bootlogo
3. Android logo (animated)
The logo inside Android could be easily removed or replaced (at least using Urukdroid).
Also the ramdisk logo could be modified with some technical skills (ramdisk needs to be rebuild and replaced).
Replacing the first hardcoded bootloader logo, is something for the freaks, but in fact it is possible.
First of all you'll need read/write access to the mtd block devices created by the kernel. This would require at least SDE or Urukdroid installation.
The Archos tablets use embedded MMC as persistant storage.
All partitions of this device are mounted as block devices and could be tweaked by directly accessing them (e.g. using dd for low level access).
One could start by reading some sectors of the first raw partition, examine the structure, do some disassembly and find the location where the bootloader logo is stored. Not sure if it could be deleted without changing some lines of code.
In fact this is an expert thing, if something goes wrong, you'll have a true brick .
There'd been some posts around covering this topic.
sodjas said:
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Click to expand...
Click to collapse
AFAIK, there's no need for this kernel module on gen8 devices.
The gen8 devices do not use any raw NOR flash or NAND devices.
All access to the eMMC is done with mtd kernel driver using the OMAP mmc interface.
BTW there might be some parts of storage used as hidden sectors, but this is a kernel thing only.
But back to topic:
In fact you'll need to find the bootlogo in raw data of the bootcode, determine the format and replace the raw blocks of memory.
Maybe you'll also need to tweak the security checks in bootcode as well, because checksum will change is the bootlogo is replaced.
Anyway it's slightly difficult to do so, but it's not impossible
Have fun,
scholbert
Lot of interesing information thank you, I'll check the hints out... The checksum thing sounds serious
Anyway, thank you very much for your answer it contains a lot interesting and useful things for me!
br, sodjas
Hi sodjas,
you're welcome!
This might be of interest to:
http://forum.xda-developers.com/showthread.php?t=1018260
This guy already made a disassembly of boot code.
http://forum.xda-developers.com/showthread.php?t=1214674
This guy wrote some tools for mmc low level access.
Maybe they might help you as well.
Keep on posting, this is an interesting topic
Regards,
scholbert
@sodjas:
Just being curious, why do you want the archos as an industrial PC?
I'M asking because we have bought a very cheap development board
http://embedded-computing.com/low-runs-main-line-linux-android
where you can install everything you want.
It is definately not as powerfull as the archos, but it costs less then half of it.
And if you search for OK6410 you will find others that even have the Android 2.3 for that.
@scholbert:
Thank you very much one more time , hope we can bring out something interesting
@fzelle:
The answer for this is the circumstance when you are at a software development deparment surrounded with high level software guys and have an interesting and impressing task to build an RFID enabled industrial terminal with WIFI capability and a platform where you can easly build fancy touch based UI-s in just 3 months then you made choices like these -> to have a proof of concept thing -> to prove that your software is unique and feasible to develop -> to be able to go to exhibitions to make this interesting to investors -> later it is more then possible that we will say somebody who has the experience in hw building: OK we have this HW build us a similar one from OEM parts bundled in an industrial box...
@both:
Thank you guys for replying, this is such a nice community!
br, sodjas
Hey Guys!
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Sorry for the lots of questions, I'm still very green on low level
br, sodjas
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
br, sodjas
Of course i understand that, i'm a sw dev for 25 years.
I was lucky to see that board before we had some similar needs as you have.
What do you use for the rfid part?
Hi sodjas,
it's late but i'll try to answer your questions
sodjas said:
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
Click to expand...
Click to collapse
So this is the firmware structure before it is installed on the device.
The update process is done by the bootcode and there's not that much information about it and not much we could actually do with these files.
So you'd better have a look at the installed partitions and the way to modify thoose.
sodjas said:
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Click to expand...
Click to collapse
No, the squashfs file is the final rootfs mounted as a loop device by the stock firmware.
It's possible to modify this file, but if you do the checksum won't match and you'll have to tweak bootcode to ignore security checking.
So in fact this is not very comfortable, but doable.
The ramdisk is the the cpio file archive also beeing updated and included in the update. Don't know the structure right now because it's on my linux laptop.
sodjas said:
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Click to expand...
Click to collapse
I don't know this tool and i guess it has been made for the older platforms.
sodjas said:
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
Click to expand...
Click to collapse
Yeah, as i pointed out:
By extracting the update file you got an "external view" of the system.
After the firmware is placed on the device these files are flashed to eMMC and got mounted as block devices.
So it's little different then.
sodjas said:
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
Click to expand...
Click to collapse
It's a bit complicated to explain... but quite easy in the end.
You'll have to read out the partitions as raw blocks.
All the low level stuff is mounted as /dev/block/mmcblk0p1
Please read out first using the dd command.
It will give a file at about 32MByte, ands it's all cryptic binary format (rawfs and below).
So if you like to enter this, there's not much information here and you'll have to digg out pieces.
Maybe it's better to modify the higher level parts...
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Attached you'll find the mounts of stock and Uruk firmware.
I know that this is little abstract right now, but i'll have to take some sleep
Have fun!
scholbert
@fzelle:
the rfid part is for workflow monitoring in glass houses. we would like to deploy N terminals in each house and the workers can check-in, define a task they are working on and after they've finished can check out... simple but all info is gathered on a central place and is in order to make easier planning/observing/and calculating financial/investment related things...
the only problem is the musb_hdrc.ko -> it is not picking the FTDI chip if its plugged-in with the OTG cable at the same time. It is a known issue but I still have a lots of problem here:
1. if a change musb_hdrc.ko to my instance musb_hdrc.ko in /lib/modules it is not working at all, if I check it with modinfo it is different than the one in the GPL release. I guess these files under /lib/modules are also proprietary
2. I degbugged around and saw that the state changes for musb only work well if you first attach the OTG micro which has a grounded 5th pin ->then the state goes to a_idle and then attach the FTDI chip -> this is a working scenario
3. If you attach the OTG with already connected FTDI then it stuck at b_idle mode...
I started a thread about this:
http://forum.xda-developers.com/showthread.php?t=1288522
but it seems the proprietary drivers will be the root of the problem here...
@scholbert:
a mininum thing I owe you is a beer a lot of useful infos here again I'll check around and come back if there are some updates.
thank you guys!
br, sodjas
Hi,
thanks for appreciating.
But stupid me, i forgot one thing...
Quoting myself:
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Click to expand...
Click to collapse
So there's a kernel driver for rawfs of course
The rawfs parts got mounted to /mnt/rawfs and present themselfs as files (avboot, banner,...).
No need to fiddle with the raw binaries to investigate the structure.
You'll have to be root to access this directory.
I'll do some research about the file format of the banner file
EDIT:
O.K., here we go... it is a gz compressed file representing raw pixel data.
So in fact this is the very first boot logo!
Should be possible to import this file to gimp or something.
Don't know if it breaks the avboot security check if it get's replaced. So please be careful!
EDIT2:
I got a Archos 101 so filesize will vary on other platforms.
The pixel data is put into 32bit format so each pixel requires a 4-byte value.
On A101 the resulting file size is of the uncompressed banner file is 2457600 bytes -> 1024x600x4
The simple framebuffer inside avboot uses only the lower 24bit of 32bit pixel data.
The most significant byte of each pixel is always set to 0xFF (0xFF000000 written as MSB first)
To completely blank screen (delete archos logo) you'll need to blank out all pixel.
Pixel data should look like this:
Code:
0xFF000000 x 1024 x 600 (for A101)
0xFF000000 x 800 x 480 (for A70)
You might create such a file with a hex-editor or use some scripting.
Good luck with your USB driver stuff!
Regards,
scholbert
Update
I modified both mmcblk0 and mmcblk0p1, my tab is still booting.
The modification of /mnt/rawfs/banner directly was my idea too, but I'm still afraid of some parts
I pulled the banner file and on ubuntu I can list the content, but can't extract it, and there are lots of questions like:
1. The file inside banner is named i240x400 -> this means that it is a 240x400 image but it would be more logical that it is 400x240 based on how "Entertaiment your way " looks...
2. Ubuntu's file roller can't extract it
3. When I open it in hex editor it has some meta info at the start of the file
and a question at the end:
How did you uncompress your banner file? I always get errors, maybe I used wrong syntax...
br, sodjas
Hi Sodjas,
Let me jump in on this to complement your study:
First, a BIG WARNING: touching any of this without patching signature check will result in bricking device.
Second BIG WARNING: Vitalif's mmc offsets for bootloader patches are valid for his device only. Mine has completely different values, I presume there are multiple bootloader versions out there. If patch is incorrect, or not done in the right order, instant brick.
7_MMC and 8_MMC are indeed interesting parts, these are the kernel+initrd images for android and recovery.
As stated by scholbert, to get a better understanding, you should take a look at /mnt/rawfs:
You'll see few files there:
avboot (second stage bootloader)
init (normal boot android, kernel+initrd)
recovery (recovery boot, kernel+initrd)
custom (sde boot, kernel+initrd)
banner (boot logo as it seems)
7_MMCF is flashed to init
8_MMCF is flashed to recovery
Splitting these files into zImage+initrd.gz is quite easy, I can give you some hints if you want. But I don't think it would serve you much for what you're trying to do: what you want is changing bootloader logo, so your goal is avboot+banner.
But again, don't modify anything on mmc0 until you're sure of what you do. First bootloader checks avboot signature and avboot checks init and recovery signature for sure. Without patch, you'll brick your device.
I don't know if avboot checks banner file though.
Hi Letama,
Thank you for joining.
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Two big questions still open for me:
1. How to modify banner in an efficient way?
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Update 2
In the meantime I uncompressed it on win with 7-zip I see the content I should modify to 0xFF000000 but I'm still not sure how flush this to all 0xFF000000 because there is some meta info at start. And as second, how to compress it, maybe the gzip -9 i240x400 will do its job as it was described at Gen5 boot logo tutorial...
br, sodjas
sodjas said:
because there is some meta info at start.
br, sodjas
Click to expand...
Click to collapse
Sorry AFAIK, no metainfo, just the pure 0xAABBCCDD 32bit values as scholbert told me before, sorry for that
br, sodjas
I realized again I'm a fool, or just archos guys wanted to make a joke
1. the banner file is named i240x400 BUT
2. when you extract it you got a 1 536 000 bytes sized file
3. I used my awsome maths skills and found out that: 1 536 000 / 4 <byte> = 384000 / 800 <pixels> = 480
So the raw image size is 800x480 and no 240x480 as the file name indicates...
I just need to flush 0xFF000000 384000 times in a file I think.
br, sodjas
sodjas said:
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
Click to expand...
Click to collapse
Yes, search pattern was the same for me too, only different offsets. Good thing that code didn't change.
sodjas said:
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Click to expand...
Click to collapse
I only modified init and recovery, but I guess they wouldn't implement a specific signature check for boot logo. I'm suspecting that there is no signature check at all on it but I never checked avboot for that.
sodjas said:
1. How to modify banner in an efficient way?
Click to expand...
Click to collapse
To modify init and recovery, I wrote a small app that directly open /dev/block/mmcblk0p1, seek for the right position (with some file signature check to be sure I'm doing it right) then write. I make sure that I don't write a bigger file than current ones and it works fine for init/recovery. I believe that archos flasher does the same as existing file sizes are bigger than the firmware dump file sizes.
For your needs, I don't know if you will have to adjust size in the rawfs directory entry and/or avboot. Rawfs is quite straightforward, you can take a look at linux driver if you need to adjust directory entry.
sodjas said:
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Click to expand...
Click to collapse
A dd of mmcblk0 (not mmcblk0p1, you need also first bootloader) should do the trick if the hardware doesn't change and doesn't need a different bootloader. I think that there is multiple revisions of hardware out there, improper bootloader for a specific hardware revision could not boot.
Safest bet would be to write a small patcher that would check pattern and stop if you don't have a known bootloader.
I looked through the fixed vulnerabilities and found the stack corruption in the fastboot mode. Can it possibly get the TA party through it? Maybe someone guide me in right direction?
Use is extremely simple: run some like "fastboot flash dahdbachegwekjwekghkusbcekfyewkuwgkeufgwyfw4gfsmncqdbxvsffg some_file".
I've tested on XZP with latest firmware and think other models are also may be affected.
CVE-2017-11007
P. S. qdbxvsffg is mistake of forum, i can't delete it.
fastboot flash <random 59 chars string> some_file
This thread seems to be a great opportunity to remember and discuss this: backup of the TA partition on the latest devices (2017/2018)!
If I'm not mistaken, even if we somehow figured out a temp root, allowing us to backup (dd) TA (and/or any other partition) on locked BL, that would not be enough to allow us to relock BL again, nor to create a hack like we did with ta-poc, since both drm and unlock keys do not seem to be present in the TA partition anymore (maybe now inside at own bootloader... don't know)!! Would DRM-fix be our last hope from now on?
I would like to hear some enlightening words from the masters @munjeni @the_laser @sToRm// @tobias.waldvogel @zxz0O0 (everyone is welcome ofc)
Thanks in advance!
On the topic of possible exploits:
A user posted here that he's getting an error when attempting to flash the v47.1.A.12.119 partition SIN file. The error is "FAIL Command not authenticated" which suggests that it's requesting SAKE authentication.
The v47.1.A.2.374 firmware was the last one to have the LA1.1_O_77 bootloader (which is the BL version I'm on) and doesn't have a problem flashing the partition SIN. The v47.1.A.5.51 firmware, and all subsequent firmware versions, have the LA1.1_O_79 bootloader.
So that makes me wonder if they've blocked partition flashing in the newer bootloader to prevent a bypass of some sort.
What's new about the v47.1.A.12.119 firmware is that it has the partition SINs pre-extracted to a folder called partition, where they were previously contained in a zip file. So it's possible that nobody was flashing the partition SINs previously because Newflasher will only flash them if they are extracted.
It would be interesting if you can flash a set of partition data that allows access to a partition that isn't normally allowed.
For an extreme, but unlikely to be workable example, flash partition data that says the TA partition sectors are at the end of the userdata partition, then create a file table entry that encompasses that set of sectors.
pbarrette said:
On the topic of possible exploits:
A user posted here that he's getting an error when attempting to flash the v47.1.A.12.119 partition SIN file. The error is "FAIL Command not authenticated" which suggests that it's requesting SAKE authentication.
The v47.1.A.2.374 firmware was the last one to have the LA1.1_O_77 bootloader (which is the BL version I'm on) and doesn't have a problem flashing the partition SIN. The v47.1.A.5.51 firmware, and all subsequent firmware versions, have the LA1.1_O_79 bootloader.
So that makes me wonder if they've blocked partition flashing in the newer bootloader to prevent a bypass of some sort.
What's new about the v47.1.A.12.119 firmware is that it has the partition SINs pre-extracted to a folder called partition, where they were previously contained in a zip file. So it's possible that nobody was flashing the partition SINs previously because Newflasher will only flash them if they are extracted.
It would be interesting if you can flash a set of partition data that allows access to a partition that isn't normally allowed.
For an extreme, but unlikely to be workable example, flash partition data that says the TA partition sectors are at the end of the userdata partition, then create a file table entry that encompasses that set of sectors.
Click to expand...
Click to collapse
Guy who flashed partition forgot to move partition sin files to partition folder which gaved error "command not authentificated", it was error because instead of command "repartition" wrong command was set "flash" because partition files was in top folder with sin files which use command "flash". For partition flashing diferent command must be used "repartition".
munjeni said:
Guy who flashed partition forgot to move partition sin files to partition folder which gaved error "command not authentificated", it was error because instead of command "repartition" wrong command was set "flash" because partition files was in top folder with sin files which use command "flash". For partition flashing diferent command must be used "repartition".
Click to expand...
Click to collapse
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
pbarrette said:
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
Click to expand...
Click to collapse
I wrote about fastboot mode (led is blue) not flashmode (led is green). That message was about error in flashmode.
To go in fastboot you need poweroff the phone, push vol_up button and connect phone to PC.
kv123 said:
I wrote about fastboot mode (led is blue) not flashmode (led is green). That message was about error in flashmode.
To go in fastboot you need poweroff the phone, push vol_up button and connect phone to PC.
Click to expand...
Click to collapse
Yes, I know that.
Serajr, however, brought up the point that this would be a good thread to use for a broader discussion of possible exploits that could be used to access the TA partition.
Since I recently saw a situation which suggests that Sony may have blocked the ability to flash the partition table, I thought it warranted a mention here as opposed to being hidden on page-26 of a thread about VoLTE. Because if they have blocked that ability in a newer bootloader, it suggests that there's a way to alter the partition table in a way that Sony did not intend. And if that's true, it could open the door to accessing other partitions, including the TA partition.
pbarrette said:
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
Click to expand...
Click to collapse
You mean this post? -> https://forum.xda-developers.com/showpost.php?p=76162897&postcount=769 It was what I talking about. That thing is fixed with latest v11 version, see -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773 partition sucesfully flashed!
---------- Post added at 05:09 PM ---------- Previous post was at 05:07 PM ----------
pbarrette said:
Yes, I know that.
Serajr, however, brought up the point that this would be a good thread to use for a broader discussion of possible exploits that could be used to access the TA partition.
Since I recently saw a situation which suggests that Sony may have blocked the ability to flash the partition table, I thought it warranted a mention here as opposed to being hidden on page-26 of a thread about VoLTE. Because if they have blocked that ability in a newer bootloader, it suggests that there's a way to alter the partition table in a way that Sony did not intend. And if that's true, it could open the door to accessing other partitions, including the TA partition.
Click to expand...
Click to collapse
Sucesfully flashed partition table -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773
One more thing, you can't flash modified partition sin file since its signed! All sin files is signed. Only maybe trought bootloader command "write_block", "read_block", maybe a chance for modifying partition table (in case not protected by sake authentification like it was protected to some trim area units like drm key unit...etc). List of command you can get inside LILO which lives in one of the sin files in bootdelivery, didn't remember name of the file but know only it was .img file format when unpack that sin file, inside that .img file inside ramdisk there is lilo file which is our bootloader, just decompile it and see what you need...
I know for sure about drm + unlock key (more about unlock key since I didn't found it on unlocked bootloader ta dump) is being outside trim area from 2017 and including 2018 models, and I'm believing booth drm key and unlock key is inside trust zone! Somehow I'm not believing which @the_laser says about drm key being deleted from trim area on android boot, its somehow nonsense, lets hope it is not true. Only a chance having that info for sure is soldering Easy Jtag Tool with emmc adapter directly to emmc pins and reading directly first partition while device is power down...
---------- Post added at 05:29 PM ---------- Previous post was at 05:09 PM ----------
pbarrette said:
Are you sure about that?
Look at the log he posted:
Repartition: partitionimage_0
Error, didn't got Repartition OKAY reply! Got reply: FAILCommand not authenticated
Click to expand...
Click to collapse
Can you give me link? I see now, instead of Repartition:0 wrong command is set Repartition: partitionimage_0 that might be again partition string changes. My tool use basename of the extracted file to send command e.g. 0.img and 0.cms, than basename of the file is 0 and command is xxx:0, but again where you saw that post? Can you post link? That thing would not cause problem since I have fixed that s o n y changes https://github.com/munjeni/newflasher/commit/a70e4984dc6863413043d2ce8bdd557879db5b69 , might be you found some old post?
device key ( unit 66667 ) is deleted from trim area only after rooting process completed.
munjeni said:
You mean this post? -> https://forum.xda-developers.com/showpost.php?p=76162897&postcount=769 It was what I talking about. That thing is fixed with latest v11 version, see -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773 partition sucesfully flashed!
---------- Post added at 05:09 PM ---------- Previous post was at 05:07 PM ----------
Sucesfully flashed partition table -> https://forum.xda-developers.com/showpost.php?p=76163127&postcount=773
One more thing, you can't flash modified partition sin file since its signed! All sin files is signed. Only maybe trought bootloader command "write_block", "read_block", maybe a chance for modifying partition table (in case not protected by sake authentification like it was protected to some trim area units like drm key unit...etc). List of command you can get inside LILO which lives in one of the sin files in bootdelivery, didn't remember name of the file but know only it was .img file format when unpack that sin file, inside that .img file inside ramdisk there is lilo file which is our bootloader, just decompile it and see what you need...
I know for sure about drm + unlock key (more about unlock key since I didn't found it on unlocked bootloader ta dump) is being outside trim area from 2017 and including 2018 models, and I'm believing booth drm key and unlock key is inside trust zone! Somehow I'm not believing which @the_laser says about drm key being deleted from trim area on android boot, its somehow nonsense, lets hope it is not true. Only a chance having that info for sure is soldering Easy Jtag Tool with emmc adapter directly to emmc pins and reading directly first partition while device is power down...
---------- Post added at 05:29 PM ---------- Previous post was at 05:09 PM ----------
Can you give me link? I see now, instead of Repartition:0 wrong command is set Repartition: partitionimage_0 that might be again partition string changes. My tool use basename of the extracted file to send command e.g. 0.img and 0.cms, than basename of the file is 0 and command is xxx:0, but again where you saw that post? Can you post link? That thing would not cause problem since I have fixed that s o n y changes https://github.com/munjeni/newflasher/commit/a70e4984dc6863413043d2ce8bdd557879db5b69 , might be you found some old post?
Click to expand...
Click to collapse
The link was in my first post, but here it is again.
The next post in the thread is me asking him to flash the old bootloader to see if that allows the partition flash, but I never got a response.
This is on a XZ1c.
Previously, Sony firmware included the partition SIN files as a zip file. So if you wanted to flash them with Newflasher, you had to extract them to the partition folder yourself.
Starting with v47.1.A.12.119, there's no zip file anymore. Instead, there's a folder called partition and the partition SIN files exist inside it. So, if you're using Newflasher, you don't have to move or extract anything.
I also get that the images are signed. But, it looks like you have to:
1] Extract the signature and upload it.
2] Extract the data to be flashed and upload it.
So you're already feeding the signature separately from the data, as opposed to uploading the entire SIN file.
Is it possible that Sony made a mistake in the old bootloader? That the partition data gets flashed before the signature validation occurs?
There have been some CVE's against the Qcom bootloader for flash before validation issues, as well as flash OOB issues in the Android Security Bulletins.
I mean, Sony didn't change the bootloader in Nov-2017 for no reason.
I'd test it myself, but I'm on the old bootloader version with the bootloader still locked. So I don't want to flash the newer one at this time if it's possible that I won't be able to downgrade it. I almost got burned that way with my old Moto phone.
pbarrette said:
The link was in my first post, but here it is again.
Click to expand...
Click to collapse
It was 01.Apr.2018 but latest version of the newflasher is from 08.Apr.2018, it might work now as like already comfirmed.
pbarrette said:
The next post in the thread is me asking him to flash the old bootloader to see if that allows the partition flash, but I never got a response.
This is on a XZ1c.
Previously, Sony firmware included the partition SIN files as a zip file. So if you wanted to flash them with Newflasher, you had to extract them to the partition folder yourself.
Starting with v47.1.A.12.119, there's no zip file anymore. Instead, there's a folder called partition and the partition SIN files exist inside it. So, if you're using Newflasher, you don't have to move or extract anything.
Click to expand...
Click to collapse
Yes, no need to extract anything in case it is already inside partition folder.
pbarrette said:
I also get that the images are signed. But, it looks like you have to:
1] Extract the signature and upload it.
2] Extract the data to be flashed and upload it.
So you're already feeding the signature separately from the data, as opposed to uploading the entire SIN file.
Click to expand...
Click to collapse
It will not work since data is uploaded in chunks, every chunk is processed and in case you have modified any part of it entire process will fail, in worst case you get hardbrick.
pbarrette said:
Is it possible that Sony made a mistake in the old bootloader? That the partition data gets flashed before the signature validation occurs?
There have been some CVE's against the Qcom bootloader for flash before validation issues, as well as flash OOB issues in the Android Security Bulletins.
I mean, Sony didn't change the bootloader in Nov-2017 for no reason.
I'd test it myself, but I'm on the old bootloader version with the bootloader still locked. So I don't want to flash the newer one at this time if it's possible that I won't be able to downgrade it. I almost got burned that way with my old Moto phone.
Click to expand...
Click to collapse
Don't know but might be true.
---------- Post added at 03:47 PM ---------- Previous post was at 03:41 PM ----------
the_laser said:
device key ( unit 66667 ) is deleted from trim area only after rooting process completed.
Click to expand...
Click to collapse
But now booth keys is no more seen in trim area partition dump, which is not a case on pre 2017 models, on 2017 and up models e.g. after unlocking bootloader unlock key 0x8b2 is no more inside trim area as like it was a case on pre 2017 models. The same with drm. It might be that unit number is moved to some diferent number? Or booth stored in tz? On short search I'm unable to get anything in secd about 1046b or 8b2 or inside ta lib
device key ( unit 66667 ) still present in trim area and parsed by appropriate routines.
bootloader unlock key parsed by linuxloader.efi application and removed from trim area after parse as many other one-time keys ( remote lock reset, etc )
the_laser said:
device key ( unit 66667 ) still present in trim area and parsed by appropriate routines.
Click to expand...
Click to collapse
That mean with temp root we can dump drm key?
the_laser said:
bootloader unlock key parsed by linuxloader.efi application and removed from trim area after parse as many other one-time keys ( remote lock reset, etc )
Click to expand...
Click to collapse
But if it is removed from trim area than whats going on on next boot, its restored to trim area and again deleted? Somehow unclear and somehow nonsense for me. It might be that unlock key have backup key? But in that case where is that backup key stored?
munjeni said:
That mean with temp root we can dump drm key?
But if it is removed from trim area than whats going on on next boot, its restored to trim area and again deleted? Somehow unclear and somehow nonsense for me. It might be that unlock key have backup key? But in that case where is that backup key stored?
Click to expand...
Click to collapse
Yes, with temp root it's possible. Because with the drm fix (patched secd and the relevant libs) the system doesn't wipe the unit at boot (logs proof this). So there should be a way to dump the TA as backup (for future use maybe) and fix the security checks (like I did) in the relevant files while the device is running. After that, the device thinks it's not rooted and we can use it like a brand new device out of the box, but with root and modifications.
munjeni said:
That mean with temp root we can dump drm key?
Click to expand...
Click to collapse
yes, we can dump all high-area units, including device key
But if it is removed from trim area than whats going on on next boot, its restored to trim area and again deleted? Somehow unclear and somehow nonsense for me. It might be that unlock key have backup key? But in that case where is that backup key stored?
Click to expand...
Click to collapse
bootloader unlock key checked by linuxloader.efi, if correct - linuxloader.efi erase userdata, erase device key and modify DEVINFO partition ( set flag "critical unlocked" or "unlocked", whatever )
so, if dump raw trim area before bootloader unlock via exploit, then unlock bootloader and restore trim area dump back - we will get unlocked bootloader and phone with original drm keys.
of course, on next boot releases s1team could add check and erase device key from trim area if devinfo.unlocked true, but this is "could"
the_laser said:
yes, we can dump all high-area units, including device key
bootloader unlock key checked by linuxloader.efi, if correct - linuxloader.efi erase userdata, erase device key and modify DEVINFO partition ( set flag "critical unlocked" or "unlocked", whatever )
so, if dump raw trim area before bootloader unlock via exploit, then unlock bootloader and restore trim area dump back - we will get unlocked bootloader and phone with original drm keys.
of course, on next boot releases s1team could add check and erase device key from trim area if devinfo.unlocked true, but this is "could"
Click to expand...
Click to collapse
"could". That was a case on pre 2017 models, on newer models it is diferent now. Just dump your bootloader UNlocked trim area and search for unit 0x8B2, its not existent! I'm believing drm key too not exist inside LOcked trim area dump. Why I think that? I know, on old models, pre 2017, default case AFTER unlocking bootloader is: trim area gets totaly new unit 0x8B2 which is unlock key string. On new models, all after 2017, unit 0x8B2 NOT exist! Chech if you not believing me! I don't have new sony model but if I somehow decide to buy one (3 percent possible, I promised that I will never buy sony again because of its infinity unfriendly camera-audio-video proprietary libs) I will definitelly disasemble it and connect emmc tool to it and dump trim area and get thing confirmed. Now I not believing about drm unit is inside trim area, lets hope I am wrong.
you did not read my message - once again - linixloader.efi check if unlock key valid and delete it after check.
device key ( unit 66666 ) still in trim area, if you believe in it or not, this will not change how things works.
the_laser said:
you did not read my message - once again - linixloader.efi check if unlock key valid and delete it after check.
device key ( unit 66666 ) still in trim area, if you believe in it or not, this will not change how things works.
Click to expand...
Click to collapse
Ok, but where is 0x8B2 unit? Its gone? Thats a first diferent thing I have noticed. Don't know about 6667 but about 0x8B2 I know. Probably 0x8B2 is no more need, right?
you kidding, right ?
Code:
In order to enable locking/unlocking of the bootloader through
FG4, the xfl has support for oem lock/unlock commands. When executing
those commands, the xfl writes data in miscTA, which is then verified by
the boot on the next boot up, and if valid, the bootloader is locked or
unlocked respectively.
1. If MiscTA Unit 2226 (TA_RCK) is not empty, the boot SHALL check whether
unlocking of the bootloader is allowed.
If unlocking of the bootloader is allowed and the RCK is valid, the bootloader SHALL be unlocked.
Before unlocking the bootloader, the userdata and cache partitions, as well
as MiscTA Unit 66667 (TA_DEVICE_KEY) MUST be erased.
After unlocking the bootloader, MiscTA Unit 2550 (TA_MASTER_RESET) SHALL
be set to 0x2.
MiscTA Unit 2226 MUST be erased after the check.
2. If MiscTA Unit 2237 (TA_RESET_LOCK_STATUS) is not empty,
the boot SHALL validate whether the content of the unit is a valid CMS signed message.
If the message is verified, the bootloader SHALL be locked.
Before locking the bootloader, the userdata and cache partitions, as well as
MiscTA Unit 66667 (TA_DEVICE_KEY) MUST be erased.
After locking the bootloader, MiscTA Unit 2550 (TA_MASTER_RESET) SHALL
be set to 0x2.
MiscTA Unit 2237 MUST be erased after the check.
Not kidding! Dump an trim area for example from xz premium unlocked bootloader phone, and see, there is no unit 2226 (0x8b2)! Believe me!
Edit:
This is wrong:
MiscTA Unit 2226 MUST be erased after the check
Click to expand...
Click to collapse
Thas never worked that way! Unit 2226 IS NOT cleared after the check (at least on pre 2017 models), that unit keep bootloader unlocked! Erasing unit 2226 on e.g. xperia z1 compact giving bootloader unlock status "unknown", I can say that for sure! Lets make thing clear, you mean that for 2017-2018 models and NOT for pre 2017 models?
First, to clarify, the last time I rooted anything was a Galaxy S3 back in the day. I'm by no means an expert, I just figured I'd help out folks like me that haven't touched all these new tools, well, ever.
Just did this myself earlier today attempted to get Magisk root, but alas, I got stuck in a boot loop. Luckily I had muddled through getting the image first, otherwise I'd still be stuck in said boot loop. I figured I'd post this for anyone else trying to root these things just to make sure you have a backup you can trust (I generally don't trust rando images that folks post online). All of the instructions below are assuming you're on Windows 10 and using PowerShell just because that's the default these days. Without further adieu.
Download ADB/fastboot (on your Windows machine)
I downloaded adb/fastboot from google directly: https://developer.android.com/studio/releases/platform-tools
Just extract and browse to the platform-tools directory in Windows Explorer until you can see adb.exe and a bunch of other tools
Download the latest SP Flash Tool
I just grabbed it from here: https://spflashtools.com/
Please let me know if there's an "official" place to find SP Flash Tool, cause everything surrounding all the download sites seems a bit sus...
Enable USB Debugging (on the tablet)
Go to settings -> About tablet
Tap the Build number 10 times (until debugging mode unlocks)
Hit back and go to System
Click Advanced and then Developer Options
Enable USB Debugger
I also enabled OEM unlocking because the whole point of this is for me to run either AOSP or Lineage someday. I honestly don't know if unlocking the bootloader is needed for dumping your own images, but I highly suspect it's not.
Plug the tablet into your computer
You'll likely see a prompt on your tablet about allowing your computer to debug your tablet. I just checked the box and hit accept so I wouldn't see it again.
Get your scatter file (on your Windows machine)
I tried several things to get the scatter file (I guess this is like a partition table based on the contents I saw) but in the end, by far the easiest way was to just download the scatter file from the file system.
In the Windows Explorer window from before (platform-tools), hold down shift while left clicking and click on Open PowerShell window here
Now type the following to get a shell on your:
.\adb.exe shell
This will get you into the shell environment. Now type the following to verify your scatter file is there:
ls -al /system/data/misc/
In here you should see something like:
-rw-r--r-- 1 root root 13893 2008-12-31 19:00 MT8168_Android_scatter.txt
Now that we have the name, just type exit to get out of the shell
Download the scatter file
.\adb.exe pull /system/data/misc/MT8168_Android_scatter.txt
Open up the scatter file in your favorite text editor (for me, Notepad++)
Now you can see the partition layout, offsets, etc, etc
Dump your image(s) (on your Windows machine)
Now open SP Flash Tool (flash_tool.exe)
On the Download tab, make sure the Download-Agent is MTK_AllInOne_DA.bin
Now click Choose for the Scatter-loading file and browse to the scatter file you just downloaded
This should be in your platform-tools folder unless you moved it
Once the scatter file is loaded, the partition table should fill up with a bunch of partitions
Click on the Readback tab
Click Add
Double-click on the new entry
Navigate to where you want to save your image, and give it a name (in this case I'm starting with boot.img)
Remember how you opened the scatter file in a text editor? Search in the scatter file for boot.img
Make sure the region matches (should be EMMC_USER) between the scatter file and SP Flash Tool
Copy/paste the value for start_addr in the scatter file to Start Address in SP Flash Tool
Copy/paste the value for partition_size in the scatter file to Length in SP Flash Tool
Now do the same thing for recovery.img and any other images you'd like
If you want a full ROM backup, name the file something like ROM_0, then use Start Address of 0x0 and length as the start_addr for the second-to-last entry in the scatter file (in my case, it was 0xc1a80000, just make sure it doesn't start with f's)
Note: I don't know for sure if this is accurate or not, I'm still playing with it, but so far it appears to be. Probably?
Poking around in WwR MTK 2.51, it looks like for this particular device (100011885) I wanted a total dump of 0x73A000000. It looks like this number is derived from the first 8Mb of the EMMC_USER dump, so I'm not sure of an easier way than throwing WwR MTK at it for the moment.
Once you've got all the entries for what you'd like to dump, make sure to disconnect the tablet from your computer and power it off
Now click on Download in SP Flash tool
Once things grey out, then plug the tablet in. After a few seconds, you'll see the images start dumping.
Congrats, you have a boot.img (and whatever other images you wanted). Like I said, from here I tried using Magisk to patch the boot file, but when I flashed it in fastboot, after enabling OEM unlocking in Developer Options, it just kept popping up the initial Onn graphic along with the Orange State warning without getting to the "fancy" Onn graphic and the rest of the boot process. I was able to flash the original boot.img back and it once again booted properly again.
Also, for anyone interested, I've posted my dumped files for the 100011885 in my google drive: https://drive.google.com/drive/folders/17LtLtjKg4JJU9EJdIXPsyNjen0H-ilMX?usp=sharing
Maybe someone will have pity on me and figure out why Magisk isn't working?
Whenever I get a moment, I'll dump my 100003562 as well.
First, thanks a ton for this. I have been trying to pull a full system dump since I bought the tablet and had resorted to single pulls by name(very long and involved) I don't know if this will work for you, but on both of my 7 inch Gen 2 tablets, I just sideloaded Magisk Manager and then opened it (this was after unlocking the tablet) When I first opened MM it just said it needed to download some additional files for my environment. I clicked okay, it downloaded and installed the additional files. Once it rebooted, I open MM again and clicked install Magisk. On the next screen, I clicked direct install and let it do it's thing. After rebooting, root checker showed I had root, but I still can't get it to pass safetyNet. Root access does work as I have installed a few modules and busy box.