• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Root/ROM/recovery R&D

Bigcountry907

Well-Known Member
Oct 15, 2015
212
214
Erie PA
So i been trying to find a workaround to at least restore my backup. I have a full backup of the 7040T that i created before i messed with stuff. I need to get my phone back up to get much further. I managed to get ahold of an OTA Update for the 7040N. An OTA update for the 7040T might bring my phone back up but so far noone is posting it. Even though one became available in the beginning of NOV 2015.

I have a plan or at least a possible way we could get in this phone. My idea is to use the OTA update that is signed correctly and passes e3 recovery verification. Take it and add a modified recovery by replacing the recovery.img in the OTA with the new one. The question is how to do this and not break the signature. Not likely to happen. I do wonder if the Command: {"/sbin/recovery"} the recovery.sh could be changed to not check for the signature.

Im downloading the AOSP source to try some test. I have the keys file that is called here by this command shown in the recovery.log
I:read key e=3 hash=20
I:1 key(s) loaded from /res/keys

I also have the releasekey.x509.pem that is used to sign the file by the developer.

But i dont have the releasekey.pk8 the developer PRIVATE key.

Im going make my own releasekey.pk8 and try to use it and releasekey.x509.pem to resign the update and see what happens.
I expect it will fail. im just curious if i use the keys found it the keyfile in the pk8 if it might take.

The other test is to use the releasekey.x509.pem and the AOSP platform.pk8, if the developer got lazy and used the stock .pk8 key we would be golden. I expect this will fail as well.

Ive been investigating if there is a way to pull the .pk8 key from the device or from the public half of the keys but i have not found a method yet.

The only other thing i can think of is to create completly new keys platform.x509.pem and platform.pk8 and take the new OTA.zip and replace the one on the phone with the new created one. But im fearful that the apk may go nutz and crash not really sure. at any rate if that certificate can be replaced the we could sign our own updates. as far as the apps we could do the same. Take my full backup and resign all the apk with the new key then reload the whole system provided the new signature will pass the recovery. In theory it seems it would work that way.

Ideas Anyone???
 
  • Like
Reactions: scary alien
Well its been an exciting day. Made a lot of progress on this Key work-around.
There are a couple of places out there where this idea was originally developed but there really is no step by step guide.
Im surprised because this is a valuable method that will allow flashing of roms on the phone without having a full custom recovery. Im not 100% sure about the effects of the locked boot loader it probably might not allow a Cyanogen rom or other but i dont see any reason why it would cause a problem loading a cooked factory rom.

Im going to create a thread on how to do this when i get a chance but basically heres how its accomplished.

First you create your own releasekeys releasekey.x509.perm and releasekey.pk8.

Then with some Java you dump the keys file from the releasekey.x509.perm.

Pull the recovery.img from the phone using the dd commands.

extract the ramdisk from the recovery.img and replace the keys file that is in /res/keys
and replace the keys file with the one we made.

Re-pack the recovery image

use adb push and the dd command to flash the recovery.img to the phone. Just to be safe im replacing the releasekey.x509.pem that is in the OTACERTS.zip located at /system/etc/security on the phone. probably could use root browser to do that,

If you can accomplish that then if you made a backup of your factory rom you could cook it in a kitchen or manually then sign it with the new releasekey.x509.perm and releasekey.pk8.

That baby will pass the signature verification

I think this is a great start. It opens a back door where you at least have a way to put your backup back to your phone.

Like if your boot looped like i am because i messed up some system files.
You would be able to flash your phone with the stock recovery.

Unfortunatly for me I have no way to ADB into the phone to flash the new recovery with the updated key. Yet anyway. Im researching using QFIL or one of the qualcom tools to re flash in emergency download mode.

I have a ZTE n800 AWE and a Galaxy S3 sph-l710 im gonna test this method out fully.
If all goes well i would reccomend anyone who is rooted to do this so if you soft brick your phone you will be able to fix it.
 
  • Like
Reactions: scary alien
Upvote 0
Well another fun filled day. I built cm11 for my sph-l710 from source. It flashed and everything is good. This just means my Android Development Setup is in good shape. I learned some new signing tricks during the build so that worked out good.

I have tested all possible combinations of resigning the ota update after modification without success.
Like my pk8 + ota x509 and my pk8 + my x509.

My signature routine is corrected. I did not re-sign apk but i resigned the whole ota.sip

Just to point it out I could not get the -w flag to work with signapk.jar alone. And it wasnt a bouncy castle issue either.
But throughout my day i did manage to properly sign an ota.zip with the -w flag. Close to the same result with the exception that if you dont use the -w flag you get e:failed incorrect footer error in recovery.

Only error i get now is whole file signature failed.

This is because i cannot replace the keys file in the /res folder of the ramdisk because i have no way to flash my recovery since my phone is bootlooped and i cannot ADB.

Only other thing that i note is the other individual who was successful at this had replaced the /res/keys but still got errors trying to flash the OTA.zip.
When he flashed a full rom he built and signed it passed the recovery.

So now im off to recompile my backup. Probably try some kitchens just for the heck of it to see what they do.
But my final compilation will be my backup with all the work completed manually.

So you ask why do this? What is the advantage of flashing a modified backup "Factory Rom' ?
Besides deodexing the apks i know modifications can be done to allow ADB Insecure and open up some other functionality that can help lead to unlocking this phone.

Im going to buy a new fierce 2 for testing as soon as i can. If i had known what i know now i woulda fixed my recovery /res/keys after i rooted before i killed my phone.

Problem is i have no job and i spend 12 hrs a day learning and playing with android builds. So i dont want to get a job then i dont have as much time to test, But i guess its inevitable i have to get a job.

o-well maybe after this project.

In the meantime if you guys really want to make progress on this badboy. Someone is gonna have to be brave enough to test things out.

Currently im good to go to provide the custom Private Key and Keys file. Also i will build the recovery with the /res/keys replaced to work with the Private key.

You will have to use the dd command in ADB to replace the recovery on your phone with the recovery i can provide.
Then you could flash any rom backup from the fierce 2 ONLY has to be factory rom. Else because of bootloader might have an issue.

Guess ill work this project through and build the rom you can flash.
Like i said i believe i can open up some more holes for us to get in a bit deeper.

If someone wants to give this a go just say so.

Ive been contemplating writing a tutorial on creating your own private releasekeys and generating the /res/keys file and how to unpack the recovery.img and replace the /res/keys to match the private releasekeys and then repack the recovery img and then use adb push to pus the recovery and dd to flash it in.

I wont make tutorial on building the rom from the backup, theres alot out there and if you do it wrong your done.

But all of the previous including also how to sign your rom with the releaskeys Id be willing to share that.

My fear is that the true Developers "which i am not yet" may not want just anyone to know how to do this.
There arent in existance any tutorials that go thru this whole process and there could be a reason for that.

I have spent many many hours to put all theese pcs together and learned a boatload doing so maybe its the best process to go through.

At any rate i just want to see this phone get beat and id be happy to share my completed files for you to test.
 
  • Like
Reactions: scary alien
Upvote 0
Ive been contemplating writing a tutorial on creating your own private releasekeys and generating the /res/keys file and how to unpack the recovery.img and replace the /res/keys to match the private releasekeys and then repack the recovery img and then use adb push to pus the recovery and dd to flash it in.

I'm not a Fierce 2 owner, but I for one would be very interested in this, @Bigcountry907.

I've been reading your last few posts with great interest :).
 
Upvote 0
Thank You, this has been a process for sure.

Good News
I confirm that this works. I don't know about the Fierce 2. It will depend if we can replace the recovery.img on the phone. With the locked boot loader we could be locked out from writing to the /recovery partition but since we have root and can ADB shell as #SU Im pretty positive it'll go. I killed my Fierce 2 by trashing the /system so its stuck in boot loop. Considering i could write to the /system like that Im pretty positive we can write /recovery. And if I remember correctly Im pretty darn sure Flashify App will do it for us. If your fierce 2 boots.

I feel like this is significant because this is the only way i know of to flash a complete Rom without a custom recovery like CWM or TWRP. So for phones that dont have a custom recovery available / or can be rooted but the boot loader is locked this works.

On a second note this method may be the way to unlock the un-lockable phones. The main requirement is a way to write the recovery to the phone. I'm pretty sure the stock recovery can be modified to allow ADB insecure and debug keys Ect. If we can gain access to re-write the Bootloader itself we could replace it with a unlocked one.

The only problem i ran into was with the KEY type. If the key is made with offset e is 65537 (0x10001) the recovery could not load the Keys file. The public exponent needs to be 3 and then there's no problem.

I'm going to clean up my process so i can make it easily replicated on other systems and I will write the guide.
 
  • Like
Reactions: scary alien
Upvote 0
Update

Well i cleaned up my process and wrote half a book of a tutorial.
You know how it goes one thing leads to another.

During writing the tutorial i realized that there are a lot of different topics involved in actually doing this.
I started to imagine the disaster of questions and issues that could arise so a new idea was born.
I spent today writing a interactive script to handle this. I got a lot more to implement but it will be better in the end.

This way if someone capable wants to know the commands they can get them from the script.
Otherwise they can use it by following the instructions.

At any rate hopefully a couple days to getter done.
Im having some fun for sure and brushing up on my scripting.
 
  • Like
Reactions: scary alien
Upvote 0
Figured id post a little update again.

I hope all this isn't too off topic for this thread but i look at it like this.
Getting a recovery image that allows us to flash a rom is step one of having custom roms.

Number 2 we need a way to fix the phone when things go wrong.

Today i came across a potential way to get ADB access to the boot looped Fierce 2.
With linux there is a utility called
USB_ModeSwitch.

The tool is used to switch device modems into different modes.

Considering the phone still connects to charging on windows box and has ADB sideload capibility i think this could be a possible way in. Using linux of course.

Basically you use
SniffUsb 2.0" USB Sniffer for Windows

to get the parameters we need to switch the modem modes using USB_ModeSwitch.

So the idea is to plug the phone in and have the modem switch to adb mode insted of being in charging mode. Also for about 30 seconds during booting the phone connects to usb. A potential switch here could buy enough time to write the recovery image. Then sky is the limit.

Ill let you know how this works out. Im logging my usb and getting ready to test the theory.
It all depends on what access to the device memory i end up with.

As far as the Key Maker Program. Im working on that too. Takes alot of time. Im making it usable for any device. Its coming along pretty good.
 
Upvote 0
@Bigcountry907,

Just a quick pop-in to point-out some adb-related information just to make sure you're aware.

The adb daemon won't even try to talk to "anyone" via the USB (or even wifi) unless USB debugging has been previously enabled (and the RSA key/authorizations for more recent versions of Android allowed).

If the above has been done and the boot sequence for a device has gotten far enough along, it may indeed be possible to connect to your bootlooping device to analyze and debug the issue. My experience with this shows this is often a pretty rare scenario, though (although not any experience involving the any Alcatel devices).

Re. using adb sideload, you should remember that any file that the stock recovery can flash must be signed with the manufacturer's keys, so any crafted flashable .zip file not created by the manufacturer will not successfully install.

This is not relevant for a custom recovery of course (unless signature checking is enabled).

~ ~ ~

By the way, I'm going to split-off these posts to a separate thread...not sure what title I'll use so please let me know what you'd like the proper title to be :).

Cheers!
 
Upvote 0
Yes you are correct adb debugging and the rsa key must be set for communication.
That is the first thing I do with any device I get.

And you are correct about the sideload with one exception.

What happens is that the stock recovery checks the public part of the key pair against a file in the recovery.img ram disk. Usually /res/keys. You can locate this call in one of the recovery log files located in the /cache. When you get your device the /res/keys that is in the ramdisk is generated by the manufacture keyset therefore limiting the update.zip to be signed with the manufacturer keys.

So I have tested and found a way to change that. Like I said I have tested and it works. If you pull your stock recovery image or get it from a factory update.

Take that recovery.img and split it into the seperate kernel and ramdisk.
Extract or mount the ramdisk -cpio.

Generate your own set of private keys using the same public exponent as the factory rom.
Example and probably most common: Exponent: 3 (0x3)
Example: Releasekey.x509.pem and Releaseke.pk8 generated with Exponent: 3 (0x3)

Take the new keys and use DumpPublicKey.jar to create a new keys file.

Replace the /res/keys file with the one created from your keys.

Repack the ramdisk.

Repack the recovery.img using the correct offsets.

Either flash the new recovery.img to the device or use fastboot to boot it.
Example: fastboot boot recovery.img

Now take an update.zip and edit the updaterscript so that it will fail at an assert / unless you actually want to flash the update.

Sign the update zip using your .x509.pem and .pk8 keypair. You have to use the signapk.jar with the -w option else it wont work.

It will pass the signature verification of the recovery for sure.
We just did the same thing that the manufacturer does with there keys.

I dont anticipate any problems with the bootloader because the new recovery.img is identical to the original recovery.img except for the /res/key is your key.

The boot loader isn't checking that key "that i know of" so it doesn't know anything is different.

And that is how to load any update you want. You sign it with your own key. You make the recovery.img /res/keys with the matching keys.

Now if you are a developer you could probably figure out how to do all of the above.
Otherwise there is a lot more to it than it seems.

Im writing a script to perform this operation. And probably a bunch more.

Its called AUTO-KEY.

Hopefully i have it finished soon.
 
Upvote 0
Update:

I've written so much code my fingers have blisters.

No no blisters but a lot of code.

Anyway everything is going pretty well.
Since i'm trying to make this universal for all phones its been a little more difficult.

running adb commands that are hard coded in script is easy but when you need to build adb commands out of variables it gets difficult.

Especially when you have to execute the as adb -d shell -c ' '

Variables dont get passed from the main shell to the sub shell and even if you export them sometimes they get funny on you.

I found some work arounds.

Right now most of the main functions are complete.

I actually pull the path and partition info off the phone and set up variables so i dont have to hard code dd commands.

This will be especially helpful when putting the recovery.img back together if it has non standard offsets.

I noticed most scripts floating around hard code everything.
I'm using variables set by the data i pull from the device to make this versitle as possible.

Im just wondering though. Do most devices have /storage/sdcard1/downloads as a path???

A common place for me to dd files to storage on the device before pull would be a good thing.
I only have a few devices to test.

Anyway if you know of a better path let me know.
I really hate to use variables for that unless i have to just to avoid the mess.

A couple more days and ill have something up for you all to play with.
 
Upvote 0
Im dying to show you whats coming so heres some shots of the menus.

mainmenu_zps655sbdjx.jpg



key%20maker%20menu_zpsvr4xg9i4.jpg



recovery_zpsjrggpnm1.jpg
 
Upvote 0
As of tonight i have tested and prooved this works. I have a newer version of autokey that i did not post yet.

I did test today to live fierce 2.

We flashed my patched recovery and the phone is in good shape.

No bootloop and the recovery functions as it should. We sideload a zip file signed by the keys i made for the patched recovery and it worked.

Tommorow i will be test flashing a virgin factory backup.

I just have to finish writing the meta-inf updater script. Mainly i need to get all file permissions set right and get the symlinks set.

Then there is one backuo that can be flashed via my patched recovery.

Meanin custom rom soon
 
  • Like
Reactions: scary alien
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones