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.
Hello Moto
I've just downloaded Verizon Jelly Bean 4.1.1 by "Firmware Team".
Just to play with it a little, extract apks and test them on Galaxy SII Skyrocket.
The thing is i'm having a hard time opening system.img.
Now i've tried LinuxReader, Unyaffs and ext2explore/read but none of these can open it, they all say that it's an unrecognized image.
Do you guys know how to properly open a stock moto System.img?
lingowistico said:
Hello Moto
I've just downloaded Verizon Jelly Bean 4.1.1 by "Firmware Team".
Just to play with it a little, extract apks and test them on Galaxy SII Skyrocket.
The thing is i'm having a hard time opening system.img.
Now i've tried LinuxReader, Unyaffs and ext2explore/read but none of these can open it, they all say that it's an unrecognized image.
Do you guys know how to properly open a stock moto System.img?
Click to expand...
Click to collapse
Google for a tool called simg2img (I used the python script that appears in get first few results, there should be other versions as well). That will unpack the image into a plain ext4 image that you can mount with any Linux pc (I recommend using a virtual machine if you have windows or mac).
Happy hacking!
Sent from my XT907
aslomagic, did you try this with the firmware lingowistico is talking about? I also tried before to unpack system.img from this package, and system.img.ext4 from ICS package, and another ICS soft for XT897, and all of them give "Bad magic" error in simg2img. All of those softs are published by the same "Firmware Team" - maybe that's the case? I also tried dsixda kitchen (which also uses simg2img, but anyway...) and it also didn't work. Might be also some custom Motorola's approach to system.img....
Could you possibly help? Thanks.
micx_pl said:
aslomagic, did you try this with the firmware lingowistico is talking about? I also tried before to unpack system.img from this package, and system.img.ext4 from ICS package, and another ICS soft for XT897, and all of them give "Bad magic" error in simg2img. All of those softs are published by the same "Firmware Team" - maybe that's the case? I also tried dsixda kitchen (which also uses simg2img, but anyway...) and it also didn't work. Might be also some custom Motorola's approach to system.img....
Could you possibly help? Thanks.
Click to expand...
Click to collapse
Well, I know for a fact that those images are packed ext4, but I haven't tried specifically with that one.
Now that you mention, I think I remember signed images (like those ones) have some additional header, maybe that needs to be removed with an hex editor, or with dd of you like
If I get a chance, I'll try and report back...
Sent from my XT907
aslomagic said:
Well, I know for a fact that those images are packed ext4, but I haven't tried specifically with that one.
Now that you mention, I think I remember signed images (like those ones) have some additional header, maybe that needs to be removed with an hex editor, or with dd of you like
If I get a chance, I'll try and report back...
Click to expand...
Click to collapse
Ok, I tried, and yes, it complains it cannot find the magic (again, I'm using the python script). I modified the script to look for the magic value in the first 50Mb of the file, and if it finds it, it starts unpacking from there. Python scripts are very easy to play with
It seems to work for me, but I don't have a linux vm handy to see if it mounts correctly (I'm currently on a mac). micx_pl, can you give it a try and let me know?
I had to zip the file even though it's very small because the forum won't let me upload a .py file... who knows, just unzip it.
Holy cow! It works! You're the master I was looking for such solution everywhere, and was stunned to see barely few topics with similar problem, and no solution at all. Thanks!
micx_pl said:
Holy cow! It works! You're the master I was looking for such solution everywhere, and was stunned to see barely few topics with similar problem, and no solution at all. Thanks!
Click to expand...
Click to collapse
You're welcome, glad I could help!
Sent from my XT907
aslomagic said:
Ok, I tried, and yes, it complains it cannot find the magic (again, I'm using the python script). I modified the script to look for the magic value in the first 50Mb of the file, and if it finds it, it starts unpacking from there. Python scripts are very easy to play with
It seems to work for me, but I don't have a linux vm handy to see if it mounts correctly (I'm currently on a mac). micx_pl, can you give it a try and let me know?
I had to zip the file even though it's very small because the forum won't let me upload a .py file... who knows, just unzip it.
Click to expand...
Click to collapse
HOLY $#!+ THANKS!!! I've been trying to decompress the moto images for awhile and have never been able to do it until now
Would it be possible to modify make_ext4fs to re-sparse the image and copy the original signature?
Q9Nap said:
Would it be possible to modify make_ext4fs to re-sparse the image and copy the original signature?
Click to expand...
Click to collapse
You're welcome to try ... my guess is that it could be made to work if the image was an official, originally signed image that was unpacked by the script above or equivalent, but if you want to modify it, re-pack it and re-attach the signature, most likely the signature won't match the content. But I may be wrong, so if somebody is willing to try, best of luck to you
If your goal is just to create a packed image, but not necessarily signed (needs bootloader unlock), then I'd say it's definitely possible, search around here.
aslomagic said:
You're welcome to try ... my guess is that it could be made to work if the image was an official, originally signed image that was unpacked by the script above or equivalent, but if you want to modify it, re-pack it and re-attach the signature, most likely the signature won't match the content. But I may be wrong, so if somebody is willing to try, best of luck to you
If your goal is just to create a packed image, but not necessarily signed (needs bootloader unlock), then I'd say it's definitely possible, search around here.
Click to expand...
Click to collapse
i'm sure you're right about the signature not working on a modified image; it was just wishful thinking. the idea of course would be to inject superuser.apk and su, which wouldn't be necessary on a bootloader unlocked device.
for bootloader unlocked devices though, the ability to repack a modified image does give you another way to build custom roms. here's the code to unpack and repack images with simg2img.py and make_ext4fs:
Code:
mkdir system
./simg2img.py system.img.ext4 system.raw
sudo mount -t ext4 -o loop system.raw system/
#make changes, then:
wc -c system.raw #lists size in bytes of system.raw
sudo make_ext4fs -s -l 1234567890 -a system system.img system/ #where 1234567890 is output from wc -c
sudo umount system
rm -rf system
i've used this proecess with samsung system images, should work for moto images now too (bootloader unlocked, of course)
Yep, it's a good cheat sheet reference
Besides, on razr m and hd at least, you can also use this with safestrap without unlocking the bootloader.
aslomagic said:
Besides, on razr m and hd at least, you can also use this with safestrap without unlocking the bootloader.
Click to expand...
Click to collapse
Not sure what you mean by this; do you mean you could mount a modified system.img with safestrap? I guess it's possible since safestrap uses a system.img on the emmc, interesting idea
Q9Nap said:
Not sure what you mean by this; do you mean you could mount a modified system.img with safestrap? I guess it's possible since safestrap uses a system.img on the emmc, interesting idea
Click to expand...
Click to collapse
Yes, that's what I mean, more or less. You don't need safestrap to just mount it (use the terminal and "mount"), but you can use it to boot from it and try it.
I did this to try the Telstra image that pjcons dumped, which is pre-rooted and not signed (there it's no official signed image to date), and with a few tricks it worked without me having to unlock the bootloader.
Sent from my XT907
aslomagic said:
Google for a tool called simg2img (I used the python script that appears in get first few results, there should be other versions as well). That will unpack the image into a plain ext4 image that you can mount with any Linux pc (I recommend using a virtual machine if you have windows or mac).
Happy hacking!
Sent from my XT907
Click to expand...
Click to collapse
hello, i cant find anything on the basics of how this works, could you point me somewhere that explains it step by step or do one here. sorry of the noob question
TheWhiteChallenger said:
hello, i cant find anything on the basics of how this works, could you point me somewhere that explains it step by step or do one here. sorry of the noob question
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1588461
CNexus said:
http://forum.xda-developers.com/showthread.php?t=1588461
Click to expand...
Click to collapse
Thanks for the link I need to go learn Linux now. Lol I dontbgt the virtual machine thing at all. Its basically a Linux emulator right?
Sent from my XT1080 using XDA Premium 4 mobile app
TheWhiteChallenger said:
Thanks for the link I need to go learn Linux now. Lol I dontbgt the virtual machine thing at all. Its basically a Linux emulator right?
Sent from my XT1080 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
No need to
http://sourceforge.net/projects/androidicsjbext/
CNexus said:
No need to
http://sourceforge.net/projects/androidicsjbext/
Click to expand...
Click to collapse
oh damn it. ok first i do appreciate the help. but that sucked. that was the frist program i tryed and it gives me "unknown file format" have i just been screwing up from the begining?
This is a much simpler and hasslefree process.
Download the root file from : here.
Instructions :
Put the downloaded root.zip in external sdcard.
Go to the stock recovery.
Select apply update from sdcard.
Select root.zip
Flash
Reboot
Please let me know if there are any problems!
Proof : forum.xda-developers.com/showpost.php?p=37976783&postcount=9
Credits :
Phil for finding the method..
I do not respond to tech support via PM
Stock recovery? How does it pass if not signed by samsung?
tys0n said:
Stock recovery? How does it pass if not signed by samsung?
Click to expand...
Click to collapse
This zip is made for stock.
Its been signed..
I do not respond to tech support via PM
Shaaan said:
This zip is made for stock.
Its been signed..
I do not respond to tech support via PM
Click to expand...
Click to collapse
A question i was about to ask...
But the answer and the /wink really rocks!
Thanks!
Root failed
Rebooted to recovery via ADB.
Started root.zip, result is following:
E:failed to verify whole-file signature
E:signature verification failed
I wonder what is wrong with this device! Nothing normal works on this.!
I do not respond to tech support via PM
Sv: [ROOT] Root JB
ladislav.heller said:
Rebooted to recovery via ADB.
Started root.zip, result is following:
E:failed to verify whole-file signature
E:signature verification failed
Click to expand...
Click to collapse
Ok, just as every other "signed". Zip's made for this model :-\
Sent thru time and space from my s3mini.
It doesnt work for me.
E:failed to verify whole-file signature
E: signature verification failed
I have stock Official 4.1.1 android version si stock recovery
XXALJL build.
tys0n said:
Ok, just as every other "signed". Zip's made for this model :-\
Sent thru time and space from my s3mini.
Click to expand...
Click to collapse
This zip is signed using Google developer keys. These keys get past Samsungs signature verification!
We have been using this zip on various 4.0+ devices..
I do not respond to tech support via PM
Shaaan said:
This zip is signed using Google developer keys. These keys get past Samsungs signature verification!
We have been using this zip on various 4.0+ devices..
I do not respond to tech support via PM
Click to expand...
Click to collapse
Maybe Samsung has its own signing key? Or the verification method was modified...
Our device has some kind of next generation security. So I've read somewhere on this forum, and all of bypass security mods and hacks that worked on other devices don't work on this device. Like triangle away and other stuff..
Sent from my GT-I8190 using Tapatalk 2
ladislav.heller said:
Maybe Samsung has its own signing key? Or the verification method was modified...
Click to expand...
Click to collapse
Yep, although it was worth trying. Older Samsung devices could be rooted this way (the Galaxy Y for example).
tested and not work faile signature verification and after tested with signing your zip with md5sum only signe and not work some message faile signature verification
spawk said:
tested and not work faile signature verification and after tested with signing your zip with md5sum only signe and not work some message faile signature verification
Click to expand...
Click to collapse
same for me! its not working... :crying:
Samsung digital certificate
Attached is the original Samsung digital certificate extracted from sec_csc.zip. You can open it in Windows and import if you want (just remove the .txt extension). But unfortunately it has no private key so we can't create signing hash for script files, etc.
ladislav.heller said:
Attached is the original Samsung digital certificate extracted from sec_csc.zip. You can open it in Windows and import if you want (just remove the .txt extension). But unfortunately it has no private key so we can't create signing hash for script files, etc.
Click to expand...
Click to collapse
Have you considered contacted Samsung to obtain their private key? I see no reason why they wouldn't give it to an unknown third party.
xd.bx said:
Have you considered contacted Samsung to obtain their private key? I see no reason why they wouldn't give it to an unknown third party.
Click to expand...
Click to collapse
Not yet
Actually I don't know their contact address.
Maybe I should write to [email protected] which is in the certificate?
ladislav.heller said:
Not yet
Actually I don't know their contact address.
Maybe I should write to [email protected] which is in the certificate?
Click to expand...
Click to collapse
I think that xd.bx has been 100% ironic in his post.
Would anyone with official 4.1.2 has been successful with this method make a confirmation here please? Thx!
Shaaan said:
This is a much simpler and hasslefree process.
Download the root file from : here.
Instructions :
Put the downloaded root.zip in external sdcard.
Go to the stock recovery.
Select apply update from sdcard.
Select root.zip
Flash
Reboot
Please let me know if there are any problems!
Proof : forum.xda-developers.com/showpost.php?p=37976783&postcount=9
Credits :
Phil for finding the method..
I do not respond to tech support via PM
Click to expand...
Click to collapse
benjaminv said:
Would anyone with official 4.1.2 has been successful with this method make a confirmation here please? Thx!
Click to expand...
Click to collapse
No it's not working with stock recovery.
Hey, I noticed while looking through the Stock Firmware AP file, that in meta-data/fota.zip there are .jar files that have to do with package signing. Only issue is that the zip is password protected. If someone has the Compute power and skills to decrypt a zip and look at the jar files and ****, maybe we could find a way to sign our own TWRP recoveries and roms. Just a thought, i'll post a link to the fota.zip file i was talking about in a bit if anyone wants to take a crack at it. (Google drive is taking forever to upload cause of AT&T's ****ty DSL speeds, sorry)
Download Link: htt*ps:/*/drive.*google*.com/file/*d/0B9tb-svjqaVD*b3Y0V0tXR3drSzA/vie*w?usp=sharing (Remove all *'s from link, stupid 10 post until you can post links limitation)
Thanks,
Lavavex
Did you saw this Thread?
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
About fota.zip...
Did you heard about plain text attack?
In few Seconds... minutes done... no password required but you can unpack.
Best Regards
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
adfree said:
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
Click to expand...
Click to collapse
Which will allow unpacking of the above zip? I thought it needed a zip password.
osm0sis said:
Which will allow unpacking of the above zip? I thought it needed a zip password.
Click to expand...
Click to collapse
We never found the Password... but for Decryption you need only these 3 Keys...
They can be easily found in few Minutes... with the right Tool...
Code:
2b4d493c
6142b289
1b7024aa
Here Key0 Key1 Key2 for Samsungs fota.zip...
This is really no rocket science...
Simple read about plain-text attack...
You can see all filenames...
You can see all filesizes etc...
Many files are floating around the Internet... to create ZIP for attack...
Then result is in few Minutes possible... :angel:
Use these 3 Keys in Tool:
Code:
Advanced Archive Password Recovery
And try self to unpack...
Best Regards
Edit 1.
Screenshot added...
Then maybe more clear...
Trial Version have mabye limtations... but to see it work... it is enough to play with trial.
@adfree or to anyone who can answer.
Quick question, what are the legal limitations to what is going on here? I may or not have a file from inside the fota.zip, but will sharing it put me in the legal wrong? If it is within the legal boundaries, I'd be happy to upload it for anyone to take a look at, but I don't want to land on the wrong side of the law by doing so. Please do let me know, as this is the most exciting development we've had when it comes to bootloader unlocking in a while. Also, it seems as though we can't view the entirety of the contents of the fota.zip with the trial version of the zip extraction tool mentioned in this thread, so if someone with more knowledge about this can confirm we could unlock our bootloaders with the contents of the zip (based on what is currently known about this), I'd be happy to bite the bullet of paying for the premium version given we can do this within the boundaries of the law.
Thanks.
1.
Maybe you can answer your question self...
Samsung PROTECTED this ZIP with password.
2.
IMHO it is Kernel related...
Yeah I know... Boot is every irritating...
But it is not sboot.bin related...
3.
About decrypting all files...
There are floating around Command Line Tool...
Code:
pkcrack
Try to Google it...
I have not tried...
I am 1 click Button user...
Best Regards
zipdecrypt from the pkcrack package plus those 3 keys worked flawlessly. :good:
Edit: Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
the password for that zip is fotatest1234
Correct. All fota zips passwords are fotatest1234
Drdra3 said:
Correct. All fota zips passwords are fotatest1234
Click to expand...
Click to collapse
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Delgoth said:
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Click to expand...
Click to collapse
Presumably what I previously said still stands:
osm0sis said:
Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
Click to expand...
Click to collapse
In various thread scattered around the Fire and Kindle forums here on XDA, I talked about the possibility of decompiling an Amazon system APK, modifying the contents such as settings for the framework or changing permissions in an attempt to escalate privileges to some degree, maybe even root. I ran into several issues when attempting such a thing:
1) Using a PC, I found it almost impossible to successfully recompile a modified APK. Many of the tools like APKtool are just too complicated and missing even the slightest step will cause it to fail.
2) Surprisingly, I've had the opposite outcome using two apps. Using APK Export, I was able to export an APK from the system and use APK Editor Pro to modify permissions. I have been able to, on a consistent basis, use APK Editor Pro to decompile the Android Live Wallpaper system APKs to add or remove any permission from the APKs manifest. Installing the APKs did not result in getting them into /system/priv-app on my HD 8, but all modifications held over and over. But every time the signature is ruined, and installing as a system app fails again.
Janus can help escalating permissions even further when using the above method and maybe others, to modify system APKs. The question is: Can we use Janus to modify an APK in some form, to install an update to an Amazon system app, which would on install, execute code that would install SU binaries? What about any other known exploit patched or not? Could we fake the system into thinking a one-click-root app is a system app and install it? Link to XDA article.
Janus takes advantage of the fact that extra bytes go unnoticed in APK files and DEX files. The GuardSquare report explains that an APK file is a ZIP archive which can contain arbitrary bytes at the start, before and between its ZIP entries. The JAR signature scheme only takes into account the ZIP entries, ignoring any extra bytes when computing or verifying the application’s signature.
It goes on to explain that a DEX file, on the other hand, can contain arbitrary bytes at the end – after the regular sections of strings, classes, method definitions, etc. Therefore, a file can be a valid APK file and a valid DEX file at the same time.
GuardSquare also mentions that a key element of the vulnerability is a “harmless” feature of the Dalvik/ART virtual machine. The report states that in theory, the Android runtime loads the APK file, extracts its DEX file and then runs its code. However, in practice, the virtual machine (VM) can load and execute both APK files and DEX files. The issue is that when the VM gets an APK file, it still looks at the magic bytes in the header to decide which type of file it is: DEX or APK. On finding a DEX header, it loads the file as a DEX file. If it doesn’t find a header, it loads the file as an APK file containing a zip entry with a DEX file. Thus, it can misinterpret dual DEX/APK files.
GuardSquare says that an attacker can leverage this duality feature of the VM to add a malicious DEX file to a normal APK file without affecting its signature. The Android runtime will accept the APK file as a valid update to a legitimate earlier app version, but the Dalvik VM will load the code from the DEX file, which has been injected with malicious code.
Click to expand...
Click to collapse
This is a good point. I brought up something similar a few months ago in another thread.
With all the exploits discovered this year where's someone trying these exploits on this hw sw combo we have with FireOS.
Where's the fuzzer for all the system calls while trying the known exploits?
Where is the systematic approach to testing these from the pedants on the forum?
Sure you can reply with the usual comebacks, but try a different approach instead of more of the same.
With
Sent from my iPhone using Tapatalk
Robius said:
Where is the systematic approach to testing these from the pedants on the forum?
Click to expand...
Click to collapse
Totally agree! Those selfish tech elitists who put real life above the desires of strangers. They should dedicate themselves (without compensation) and their community resources to methodically crack this very important nut. Ya know, because exploiting a $50 entertainment gizmo should rise to the top of THEIR priority list. Sorry sweetie, daddy won't becoming to any of your soccer games this year; he has important work to do.
My point exactly.
You spent enough energy to respond to this in a sarcastic manner. Thank you
Sent from my iPhone using Tapatalk
Robius said:
My point exactly.
You spent enough energy to respond to this in a sarcastic manner. Thank you
Click to expand...
Click to collapse
Time well spent; appreciate the opportunity to respond in kind.
I have seen a bunch of hashes running through the terminal last time. Amazon may compare the hashes of the apks against a whitelist.
All right, I am ready to take this exploit on my 5th Gen. What I have to do??
Adyatan said:
All right, I am ready to take this exploit on my 5th Gen. What I have to do??
Click to expand...
Click to collapse
I haven't sat down and looked into this too much so I'm not sure how to execute the exploit yet.
The idea I had been working on months ago was to somehow insert SU binaries into an Amazon system APK, and get it to install the modified APK as an update to an existing system app. The issue back then was the signature getting destroyed. If we can modify an Amazon system APK to contain a script to execute installation of SU binaries, the exploit might allow the APK to install as an update to an existing Amazon app and in theory install the SU binaries. Based on what little I've read, we would have to either 1) modify the existing DEX file of an Amazon system APK to contain code/script to install SU binaries or 2) create a new DEX file with the code and replace it with the original. My opinion is a better chance at the first method.
Now how to do all that using the Janus exploit? I do not yet know.
"An attacker exploiting the flaw could replace a trusted application that already has high privileges, such as a system app, with one of their updates to abuse the permissions that have already been granted. This could enable the attack to access sensitive information stored in the devices or enable the attacker to seize control over the device completely."
https://www.scmagazine.com/janus-vu...-android-50-devices-and-newer/article/713449/
So how would one go about updating a DEX file to contain 1) SU binaries that install upon 'updating' the app on installation? Or 2) clone a system app and edit or change the DEX file? 3) add an exploit script to a DEX file that would gain root (then you would install SU binaries and app)?
It seems the editing of the DEX file itself doesn't damage the signature and that's the nature of the exploit?
Hey is it possible to modify the permissions ota updater and remove the internet permissions so it can't update
I just found this https://github.com/odensc/janus don't have a computer anymore or would try it
Asadullah said:
Hey is it possible to modify the permissions ota updater and remove the internet permissions so it can't update
Click to expand...
Click to collapse
I cannot recall if I've ever tried with that APK. I have tried with others, unsuccessfully. Either the APK will fail to recompile into a proper installation file, or it would 'install', but with none of the modifications holding.
Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures
While installing an Android app or its update, your device checks APK header information to determine if the archive contains code in the compressed DEX files. If header says APK archive contains DEX files, the process virtual machine decompiles the code accordingly and executes it; otherwise, it runs the code as a regular APK file.
It turns out that an APK archive can contain DEX files as well as regular application code simultaneously, without affecting its validity and signatures.
Researchers find that this ability to add extra bytes of code due to lack of file integrity checking could allow attackers to prepend malicious code compiled in DEX format into an APK archive containing legitimate code with valid signatures, eventually tricking app installation process to execute both code on the targeted device without being detected.
In other words, the hack doesn't require attackers to modify the code of legitimate applications (that makes signatures invalid)—instead, the vulnerability allows malware authors to merely add some extra malicious lines of code to the original app.
Click to expand...
Click to collapse
So we would need to write a script or other code that would be placed into a Amazon System APK. Now would we be able to add SU binaries to an APK? What about a root script like DirtyCow. Although DC is patched, would that be different if the exploit was installed into the /system-priv-app and then executed? I really don't want to sound dumb here so please help me pout guys. Any feedback, negative or not is appreciated.
Maybe this tool can help https://forum.xda-developers.com/android/software/tool-dex-manager-v1-0-designed-to-play-t2988532
Robius said:
Maybe this tool can help https://forum.xda-developers.com/android/software/tool-dex-manager-v1-0-designed-to-play-t2988532
Click to expand...
Click to collapse
I can't find a working download link. Apparently it has been discontinued and i was directed to this: Uret Android Reverser Toolkit v1.6. I downloaded it.
I did find the other one but it says it's for a Galaxy Note. Not sure if that's really the case though.
DragonFire1024 said:
Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures
So we would need to write a script or other code that would be placed into a Amazon System APK. Now would we be able to add SU binaries to an APK? What about a root script like DirtyCow. Although DC is patched, would that be different if the exploit was installed into the /system-priv-app and then executed? I really don't want to sound dumb here so please help me pout guys. Any feedback, negative or not is appreciated.
Click to expand...
Click to collapse
It's beyond my knowledge but if you were to maybe add a script to the dex giving it the permisions I gotta look more into this
---------- Post added at 04:13 PM ---------- Previous post was at 03:54 PM ----------
DragonFire1024 said:
I can't find a working download link.
Click to expand...
Click to collapse
here's smali baksmali for editing dex files https://github.com/JesusFreke/smali I havent used it in a while but used to work good
Asadullah said:
It's beyond my knowledge but if you were to maybe add a script to the dex giving it the permisions I gotta look more into this
---------- Post added at 04:13 PM ---------- Previous post was at 03:54 PM ----------
here's smali baksmali for editing dex files https://github.com/JesusFreke/smali I havent used it in a while but used to work good
Click to expand...
Click to collapse
Editing DEX is pretty much out of my league too. I wouldn't know where to start. I don't even know how to install or use the tool you posted.
DragonFire1024 said:
Editing DEX is pretty much out of my league too. I wouldn't know where to start. I don't even know how to install or use the tool you posted.
Click to expand...
Click to collapse
https://github.com/JesusFreke/smali/wiki/DeodexInstructions
It's really pretty simple used to use it take out the ads from angry birds and what not when it first came out. But it's easier said than done. If you do try first thing I would suggest is that you decompile then recompile to see if it works right the dependencies sometimes will get you or we can try and beg another developer to make us a modified apk..... Please pretty please with sugar on topwe'll like all your posts???
Check this thread for root possibility:
https://forum.xda-developers.com/hd8-hd10/general/complete-guide-root-hd7-8-106th-gen-t3545411
Robius said:
Check this thread for root possibility:
https://forum.xda-developers.com/hd8-hd10/general/complete-guide-root-hd7-8-106th-gen-t3545411
Click to expand...
Click to collapse
FYI - nothing new in that thread. Same familiar tools/techniques targeting a different gen/suite of Amazon devices. Similar outcomes too. Vulnerability patched in FireOS 5.3.2.x as so far proven impenetrable by generic rooting tools of common origin (KingRoot, KingORoot, etc).
Davey126 said:
FYI - nothing new in that thread. Same familiar tools/techniques targeting a different gen/suite of Amazon devices. Similar outcomes too. Vulnerability patched in FireOS 5.3.2.x as so far proven impenetrable by generic rooting tools of common origin (KingRoot, KingORoot, etc).
Click to expand...
Click to collapse
Not sure if the following report is true: (HD10 7th Gen on 5.6.0.0)
https://forum.xda-developers.com/hd8-hd10/general/rooted-fire-hd-10-7th-generation-t3718629