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
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.
Greetings, and welcome to the home of a little set of utilities I'm calling "DroidShell".
What it is:
DroidShell is my attempt at bridging the gap between the various android utilities used for ROM modification and the Windows explorer system. It is a series of scripts that are automatically associated with .apk, .jar, and .iso files so that they are automatically decompiled on double-click or enter. Additionally, when a file is decompiled, a corresponding .dcp, dcf, or dci (decompiled package, decompiled framework, decompiled image) file is created, which allows for automatic recompiling, as well as optional cleanup, or resigning.
The goal of this project is pretty simple...to have all the tools needed for ROM work in one place, and have them easily accessible without having to have eighty command windows open or to have to go through a chain of commands to create a usable apk/jarfile.
Features:
One-shot setup. Extract the files, run install/installer.bat, and all of the necessary file associations and paths are created.
Batch terminal integration - provides integration for adb, fastboot, apktool, 7zip, zipalign, oat2dex, unpackbootimg, repackbootimg, baksmali and smali in windows command-line interface from path.
Automagic association with common android filetypes for decompilation.
Custom placeholder files - dcp, dcf, and dci - for packages, framework, and image files. Allows for automatic recompiling, and optional signing and cleanup of decompiled files.
Recompiled apks and jars are automatically repacked with modified files while excluding androidmanifest.xml, meaning signatures are unaffected.
For modifications requiring androidmanifest be changed, you can right-click a .dcp file to recompile with signature.
Auto-detection of framework-res file with prompting to install.
Popup dialogue boxes for errors and alerts.
(NEW) Right-click to decompile to java code. This cannot be recompiled, but is great for researching more complex mods. (Can also be invoked by using the command dj filename.apk)
(NEW) Support for sparse image system -> .img conversion.
(NEW) za command for zipaligning apk's.
(NEW)
Download:
https://github.com/d8ahazard/DroidShell/archive/master.zip
Source:
https://github.com/d8ahazard/DroidShell
Instructions...
You need the Java Runtime Environment (RE). Get it here.
Extract to a folder somewhere. Spaces in the path are probably not good. I put it in C:\DroidShell
Browse to the folder. Go into the install folder. Run installer.bat. (Installer needs admin priveleges. It will prompt for them, but in some cases, you may have to automatically run as admin)
Reboot.
You should now have shell integration. APKs, Jars, and .img files will automagically decompile.
It's late, I've been working on this all weekend...but it should be good to go. Please let me know if you have any thoughts.
CHANGELOG:
Code:
02.02.16 - v2.0
Update smali, baksmal to v. 2.1.1.
Add shell script for oat2dex (not implemented in context menus, just avaialable for now)
Update APKTool to latest version
Add dx.jar - for converting java classfiles to .dex (just available for now)
Add ext4 and ext2 tools - For manually unpacking images if needed. These are GUI based, not my work.
Add rimg2sdat - For converting .img to sparse (Not implemented yet)
Update sdat2img to latest version by xspirit, added python to installer as required.
Add zipalign function (Not implemented, can be called via "za filename.apk"
Add decompile to pure Java:
This utilizes a few tools to take apk's and jarfiles and decompile them to as close of an android package as we can get without having the actual source code. While we cannot at this time recompile these into apk's, it is very useful for analysis when trying to implement other mods. Like...really helpful. This one can be accessed by right-clicking a decompileable package and picking "decompile to java".
01.31.15 - v1.8
Added windows progress bar for file copies in system.img extraction.
Fixed some script errors.
01.29.15 - v1.7
Cleaned up installer, added more verbosity.
Better error checking in image extractor.
Add support for .list files, allowing double-click extraction of system.transfer.list and cm12-style image files.
Added custom language files for notepad++, allows syntax highlighting of .smali and logcat files.
01.27.15 -v1.6
Added support for system images. Requires installation of included OSFMount.
Added file associations for common plaintext android files to notepad++ if installed.
Converted several .bat files to .exe, allows for icons, inclusion of required files, and UAC prompting when needed.
01.26.15 - v1.5
Fixed fatfinger in APKtool detection causing error.
01.26.15 - v1.4
Added zipaligning
Added check to make sure apktool is present
Updated test-keys to latest AOSP version
Compiled batches to .exe with required files for AIO-packages
Fixed: Installer not always associating with files correctly.
Thanks a million
Version 1.5 uploaded.
Added Zipaligning
Check to make sure apktool.jar is found in %DROIDROOT% directory.
Updated signing keys.
Switch from .bat to .exe, allows modularization of functions, cleaner.
Modifications to installer to try and fix some issues with file associations.
Fixed issue between 1.4 and v 1.5 where I fatfingered a check.
Hell yes!
digitalhigh said:
Greetings, and welcome to the home of a little set of utilities I'm calling "DroidShell".
What it is:...
Click to expand...
Click to collapse
So many thanks for this! I'm going to use it like hell!
Excellent Job!
I'm bookmarking this, gona read it thuroughly at breakfas
So I'm curious - has anybody had a chance to give this a try yet?
Testing file association stuff is tricky, because Windows likes to keep track of the "user selected" association too. So, I had to add some extra commands to the installer script to clean up everything appropriately first.
Either way, I've ran it on like three different computers "clean" and had it work like a charm on all of them. I'd like to know how it works with WIndows 7 or XP.
I could be doing something wrong (windows is not my OS of choice, I use kubuntu 14.10 as my daily driver, and as such am mostly illiterate in dos/batch, I'm a sh/bash guy), but the installer bombed out (hung up without confirmation of success) on my windows 7 pro install (on a dell latitude e6400, with a dual core core2 @2.8ghz, quattro 160m graphics, 4gb of ddr2 @800mhz, booting off a 120gb Samsung evo ssd. Wouldn't think its relevant, but just in case).
Steps:
First I decompressed the .zip in the root of my C:\ drive, with 7zip (did not change file name, kept as "DroidShell_1.5").
Next I ran the installer script.
I then granted it admin privileges.
It killed my desktop, explorer.exe. I assume this is normal due to the terminal output:
Code:
SUCCESS: The process "explorer.exe" with PID 3260 has been terminated
Then I got:
Code:
file type 'apk_auto_file' not found or no open command associated with it.
Followed by 4 more identical errors, just replace "apk" with dfc, dcp, dci, img.
A bunch of successful operations.
Then:
Code:
ERROR: Invalid syntax.
Type "REG ADD /?" for usage
A bunch of successful operations.
Then:
Code:
ERROR: The system was unable to find the specified registry key or value.
The above output repeats 17 times.
Then 4 more operation success messages and it hangs, with my desktop killed.
Ctrl+alt+del, logout, log in, and I'm back in business. No noticeable increase in disk space, no newly installed programs (as expected).
I read the op, and from my understanding it doesn't require any dependencies? (Apktool, android SDK, android studio, etc). All the necessary dependencies are built in, right? It's a fresh install of windows 7 pro, with all available updates taken.
EDIT:
It worked perfectly regardless of the errors, see my post on page 2.
thisguysayswht said:
I could be doing something wrong (windows is not my OS of choice, I use kubuntu 14.10 as my daily driver, and as such am mostly illiterate in dos/batch, I'm a sh/bash guy), but the installer bombed out on my windows 7 pro install (on a dell latitude e6400, with a dual core core2 @2.8ghz, quattro 160m graphics, 4gb of ddr2 @800mhz, booting off a 120gb Samsung evo ssd. Wouldn't think its relevant, but just in case).
Steps:
First I decompressed the .zip in the root of my C:\ drive, with 7zip (did not change file name, kept as "DroidShell_1.5").
Next I ran the installer script.
I then granted it admin privileges.
It killed my desktop, explorer.exe. I assume this is normal due to the terminal output:
Code:
SUCCESS: The process "explorer.exe" with PID 3260 has been terminated
Then I got:
Code:
file type 'apk_auto_file' not found or no open command associated with it.
Followed by 4 more identical errors, just replace "apk" with dfc, dcp, dci, img.
A bunch of successful operations.
Then:
Code:
ERROR: Invalid syntax.
Type "REG ADD /?" for usage
A bunch of successful operations.
Then:
Code:
ERROR: The system was unable to find the specified registry key or value.
The above output repeats 17 times.
Then 4 more operation success messages and it hangs, with my desktop killed.
Ctrl+alt+del, logout, log in, and I'm back in business. No noticeable increase in disk space, no newly installed programs (as expected).
I read the op, and from my understanding it doesn't require any dependencies? (Apktool, android SDK, android studio, etc). All the necessary dependencies are built in, right? It's a fresh install of windows 7 pro, with all available updates taken.
Click to expand...
Click to collapse
Bombed out is a rough term. The installer is just writing a bunch of registry keys, and deleting some other ones to make sure other associations don't mess it up. So, some registry operations don't always work - there just there to be sure. I've actually worked on cleaning that up in the next iteration I'm cooking.
And yes, there shouldn't be any more size increase past extracting the original zip. All the files used are enclosed. "Installer" is just telling Windows that "droid shell is at location %CD%" and "use app xxx in %CD% to open file XX". A few extras for the right-click context menus and icons...so forth.
So, to know if it is working is really just a matter of finding an apk or .jar and double-clicking it. You should get a terminal window showing the process and a box confirming success or failure, plus a reason why if failure.
The only dependency is the Java Runtime environment, which is the same common necessity as for any other Apktool environment. You can get it here, and I'll throw that link in the OP in a second.
The next iteration of the installer is going to be a lot cleaner, plus be more verbose so you actually know what it's doing. My first thought in putting it out was just to see how well the decompile/recompile stuff worked.
Bombed out is a rough term. The installer is just writing a bunch of registry keys, and deleting some other ones to make sure other associations don't mess it up. So, some registry operations don't always work - there just there to be sure. I've actually worked on cleaning that up in the next iteration I'm cooking.
And yes, there shouldn't be any more size increase past extracting the original zip. All the files used are enclosed. "Installer" is just telling Windows that "droid shell is at location %CD%" and "use app xxx in %CD% to open file XX". A few extras for the right-click context menus and icons...so forth.
So, to know if it is working is really just a matter of finding an apk or .jar and double-clicking it. You should get a terminal window showing the process and a box confirming success or failure, plus a reason why if failure.
The only dependency is the Java Runtime environment, which is the same common necessity as for any other Apktool environment. You can get it here, and I'll throw that link in the OP in a second.
The next iteration of the installer is going to be a lot cleaner, plus be more verbose so you actually know what it's doing. My first thought in putting it out was just to see how well the decompile/recompile stuff worked.
Click to expand...
Click to collapse
I didn't mean to offend with the term "bombed out", it may have been a bit of a rough term. I just meant the script terminated my desktop and hung up.
It actually succeed regardless of the errors, and is working like a charm. I apologize, I should have actually tested it before posting. I shouldn't have assumed that it didn't work based off of the terminal output/behavior.
Also, I would like to say that I greatly appreciate the work that you put into this, and all your other projects here on xda. I'm running your 4.4.4 gpe port for the verizon m8 as my primary rom, and it is by far the most stable port I have ever had the pleasure of flashing.
Attached are screenshots of DroidShell successfully decompiling and recompiling an apk with a simple right click selection on windows 7 pro. Good stuff.
Thanks! tons
Thanks for the work. very useful.
The compiling and decompiling of apk is perfect on Win 7 pro.
From the OP, i also got the impression it would unpack / pack images, so i tried it with a system.img copied to the droidshell directory.
With the command c:\droidshell\unpackimg system.img, I got the error as shown in screenshot
Am I doing something wrong, or is this not supported yet?
arbit12 said:
Thanks for the work. very useful.
The compiling and decompiling of apk is perfect on Win 7 pro.
From the OP, i also got the impression it would unpack / pack images, so i tried it with a system.img copied to the droidshell directory.
With the command c:\droidshell\unpackimg system.img, I got the error as shown in screenshot
Am I doing something wrong, or is this not supported yet?
Click to expand...
Click to collapse
It only works for boot images at the moment. System images are a different beast.
Sent from my HTC6525LVW using XDA Free mobile app
digitalhigh said:
It only works for boot images at the moment. System images are a different beast.
Sent from my HTC6525LVW using XDA Free mobile app
Click to expand...
Click to collapse
Okay. Thanks for the info.
thisguysayswht said:
I didn't mean to offend with the term "bombed out", it may have been a bit of a rough term. I just meant the script terminated my desktop and hung up.
It actually succeed regardless of the errors, and is working like a charm. I apologize, I should have actually tested it before posting. I shouldn't have assumed that it didn't work based off of the terminal output/behavior.
Also, I would like to say that I greatly appreciate the work that you put into this, and all your other projects here on xda. I'm running your 4.4.4 gpe port for the verizon m8 as my primary rom, and it is by far the most stable port I have ever had the pleasure of flashing.
Attached are screenshots of DroidShell successfully decompiling and recompiling an apk with a simple right click selection on windows 7 pro. Good stuff.
Click to expand...
Click to collapse
Oh, no offense taken.
I came at this project, as I do with most, with the mindset of "OOOH, SHINY THING. I MUST SHOW EVERYONE." So, first thought was putting out the app, despite some of the install stuff being a bit dirty.
However, the next iteration is shaping up to be quite lovely. See below.
arbit12 said:
Okay. Thanks for the info.
Click to expand...
Click to collapse
So, it appears that this question has motivated me to try making that function a reality sooner than later.
However, as far as I can see, the *ONLY* application for windows that currently deals with system images right now is Ext2Explore, which is a bit old and doesn't have command-line support.
Fortunately, there's source code for it, so I'm currently downloading Visual Studio and will see if I can add command line functionality, as well as make it launch with UAC prompting.
If I can make this work, my plan is to make one handler for .img files that works like so:
1. Look at the file passed to it and see if it's a boot image. If it is, extract and exit.
2. If it's not a boot image, try to extract it as a system image. If it is, extract and exit.
3. If it's not a boot or system image - pass it to explorer and mount as usual.
I can do # 1 and #3 already...it's just getting #2 to go.
Also, I've added a check in the installer that looks for the installation of notepad++. If it finds it, it will create additional associations for .xml, .prop, conf, config, .smali, and whatever else I can think of that I could possibly need to edit in a ROM.
Then, lastly, with all these additions, I'd like to make the installer a bit more verbose. Give some options so it's not just an all or nothing install, make it prettier, etc.
digitalhigh said:
Oh, no offense taken.
I came at this project, as I do with most, with the mindset of "OOOH, SHINY THING. I MUST SHOW EVERYONE." So, first thought was putting out the app, despite some of the install stuff being a bit dirty.
However, the next iteration is shaping up to be quite lovely. See below.
So, it appears that this question has motivated me to try making that function a reality sooner than later.
However, as far as I can see, the *ONLY* application for windows that currently deals with system images right now is Ext2Explore, which is a bit old and doesn't have command-line support.
Fortunately, there's source code for it, so I'm currently downloading Visual Studio and will see if I can add command line functionality, as well as make it launch with UAC prompting.
If I can make this work, my plan is to make one handler for .img files that works like so:
1. Look at the file passed to it and see if it's a boot image. If it is, extract and exit.
2. If it's not a boot image, try to extract it as a system image. If it is, extract and exit.
3. If it's not a boot or system image - pass it to explorer and mount as usual.
I can do # 1 and #3 already...it's just getting #2 to go.
Also, I've added a check in the installer that looks for the installation of notepad++. If it finds it, it will create additional associations for .xml, .prop, conf, config, .smali, and whatever else I can think of that I could possibly need to edit in a ROM.
Then, lastly, with all these additions, I'd like to make the installer a bit more verbose. Give some options so it's not just an all or nothing install, make it prettier, etc.
Click to expand...
Click to collapse
Captain_Throwback said:
Click to expand...
Click to collapse
Don't get too excited. I've never touched C++ before, and ext2Explore was done in VisualStudio.net and a WYSIWYG editor called QT. I found updated source for the program from 2012 and have gotten it to import into QT, however, it needs MingW and some other dependencies. I'll be lucky if I can even get it to compile again, let alone work, let alone work with added command-line stuff.
However, that's still the goal.
Also, I want to add wget (windows equivalent) stuff to auto grab and install java and notepad++ while we're at it.
So, I think Ext2Explore is more work than it's worth.
OSFMount, on the other hand, just let me mount a system.img as a removable disk with read-write access. I'm going to go down this road...
Good to hear that. Extracting system.img on windows can be a real pain at times - this would be great.
As many of you know, Huawei released a GMS installer so that we can (FINALLY!) have google on our Chinese model phones.
I was wondering how it worked, so I looked into it, and I'd like to share what I've found.
The APK is signed with Huawei's key. I guess the way it's installed, it runs as a system app.
Inside the APK file, you will find assets/update_data_public.zip -- this is the payload. The payload zip file is not mentioned in the manifest file, but it is a flashable update file signed by huawei. The payload simply flashes the GoogleServicesFramework, GoogleLoginService, and GmsCore folders to /system/app
Where it gets interesting is, we can use this to flash whatever we want onto the phone (as long as it's something signed by Huawei, of course). Simply replace update_data_public.zip with whatever file you want to flash (rename it to update_data_public.zip of course) and if it's signed by Huawei, it will install.
Theoretically, you could put, for example, a European firmware zip file, and it would flash. I haven't tried this yet, though.
So then, this begs the question, "How does it do this?" Here's how.
It moves the payload file (update_data_public.zip) to the folder /data/update and runs the following command:
Code:
/cache/recovery/command --update_package=/data/update/update_data_public.zip
And that's basically it.
I don't have my USB cable with me at work to try anything over ADB, but if anyone wants to try any of this, go for it! I don't think this will lead to root or anything, but it will probably lead to an easier way of installing packages, which means we don't have to do everything via eRecovery.
That is a very interesting find. Cannot wait to see someone tests your theory.
duraaraa said:
As many of you know, Huawei released a GMS installer so that we can (FINALLY!) have google on our Chinese model phones.
I was wondering how it worked, so I looked into it, and I'd like to share what I've found.
The APK is signed with Huawei's key. I guess the way it's installed, it runs as a system app.
Inside the APK file, you will find assets/update_data_public.zip -- this is the payload. The payload zip file is not mentioned in the manifest file, but it is a flashable update file signed by huawei. The payload simply flashes the GoogleServicesFramework, GoogleLoginService, and GmsCore folders to /system/app
Where it gets interesting is, we can use this to flash whatever we want onto the phone (as long as it's something signed by Huawei, of course). Simply replace update_data_public.zip with whatever file you want to flash (rename it to update_data_public.zip of course) and if it's signed by Huawei, it will install.
Theoretically, you could put, for example, a European firmware zip file, and it would flash. I haven't tried this yet, though.
So then, this begs the question, "How does it do this?" Here's how.
It moves the payload file (update_data_public.zip) to the folder /data/update and runs the following command:
Code:
/cache/recovery/command --update_package=/data/update/update_data_public.zip
And that's basically it.
I don't have my USB cable with me at work to try anything over ADB, but if anyone wants to try any of this, go for it! I don't think this will lead to root or anything, but it will probably lead to an easier way of installing packages, which means we don't have to do everything via eRecovery.
Click to expand...
Click to collapse
Excellent idea. Modifying the apk will remove Huawei's signature, no?
onslaught86 said:
Excellent idea. Modifying the apk will remove Huawei's signature, no?
Click to expand...
Click to collapse
Yeah. I tried modifying the APK and it was a failure, of course. So I don't think any new flashing method will become of this. At the very least, though, we know more about how it works.
onslaught86 said:
Excellent idea. Modifying the apk will remove Huawei's signature, no?
Click to expand...
Click to collapse
Yes . We can compile/decompile but when install we'll have error in installation packet just because there is a bad sign. No possibility to recover a keystore from apk. So waste of time
So sorry it's out of topic, couldn't find it. I have huawei enjoy 7 or the kfc limited phone. Downloaded the gms installer but never work. Tried several gms installer and google installer
Here is the error on gms installer
Software install failed
Get help from emui.com/...
Reboot system now
I really like this phone. One of a kind, even though I promoted KFC indirectly ?
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
Security path is of june 2017. ro.build.version.security_patch=2017-06-01
We can try all exploits which came after that.
So far not able to find any exploit for tank, I'm sharing the latest bin and extract so we can collectively find some.
Drive Link
Succeeded with this exploit https://www.xda-developers.com/janus-vulnerability-android-apps/.
Able to modify and update system apps and gain system app privilege.
Script used > https://github.com/V-E-O/PoC/tree/master/CVE-2017-13156
i have only tested this on tank since i don't have other devices. Theoretically it should also work on all fire devices which don't have latest security patch.
install this apk to block installing new update from amazon. it will still download the ota bin file for you to experiment, but the ota install will fail as the install code is removed.
I'm not that expert so can you clarify for me? Can you use this exploit to add supersu or any other root method?
I have a US fire TV 3, a US FireTvStick 2 and an italian FireTvStick 2 Basic edition. Can I test this on any of them?
EDIT: All of them have updates blocked on my router. Can't rempember on what Os version they are though. But pretty sure a very early one.
EDIT#2: Reading better I guess it's not possible cause the exploit can only modify SYSTEM APPS permissions? Not sure if a non system app installed by user crafted to install su binaries can work?
EDIT#3: Reading better I understood that if you craft a dex file makiing it look like a legitimate update of a high privileged system app you can inherit its privileges and execute your code. So maybe there are hopes. Thanks again for your effort. Really interesting.
Thanks and nice work.
puppinoo said:
I'm not that expert so can you clarify for me? Can you use this exploit to add supersu or any other root method?
I have a US fire TV 3, a US FireTvStick 2 and an italian FireTvStick 2 Basic edition. Can I test this on any of them?
EDIT: All of them have updates blocked on my router. Can't rempember on what Os version they are though. But pretty sure a very early one.
EDIT#2: Reading better I guess it's not possible cause the exploit can only modify SYSTEM APPS permissions? Not sure if a non system app installed by user crafted to install su binaries can work?
EDIT#3: Reading better I understood that if you craft a dex file makiing it look like a legitimate update of a high privileged system app you can inherit its privileges and execute your code. So maybe there are hopes. Thanks again for your effort. Really interesting.
Thanks and nice work.
Click to expand...
Click to collapse
As of now no super user, still looking for loop holes to use system permission to disable SELinux security.
Yes you can try installing. But if it fails, you will have to pull your system app and modify.
This apk is based on Fire OS 5.2.6.3 bin also works on Fire OS 5.2.6.2.
ranjeet choudhary said:
install this apk to block installing new update from amazon. it will still download the ota bin file for you to experiment, but the ota install will fail as the install code is removed.
Click to expand...
Click to collapse
Where does the downloaded OTA sit? Will this blocking app work for other Fire devices such as Fire tablets?
ranjeet choudhary said:
As of now no super user, still looking for loop holes to use system permission to disable SELinux security.
Yes you can try installing. But if it fails, you will have to pull your system app and modify.
This apk is based on Fire OS 5.2.6.3 bin also works on Fire OS 5.2.6.2.
Click to expand...
Click to collapse
I researched Fire system app permissions a while ago, see this post https://forum.xda-developers.com/showpost.php?p=75226706&postcount=65
You can use a script like this to dump info for all system apps, and then look through the output:
Code:
for p in `pm list package -s | ./busybox awk -F"package:" '{print $2}'`; do echo -n "$p: "; dumpsys package $p ; done
(this requires that you upload 'busybox' to /data/local/tmp, and run it there)
What I observed is that SuperSu adds a whole new level of permissions to the system (a giant hole, if you will). None of the existing apps have that level of access. Of the existing system apps, it seemed that devicesoftwareota had some of the juicer permissions, which that still is not much. All it effectively does is that it grabs the update bin from the Internet, sticks it to a designated directory, and reboots to recovery which will continue the update. This can already be achieved on tablets via the sideloading option in recovery. I don't recall I spotted an existing app that could read the whole /data directory, as to enable backups in a simple format.
I've attached the output for devicesoftwareota for FireHD 10 2017, but that should be similar to the Fire stick.
Anyway, please do share if you find anything good!!!
ranjeet choudhary said:
Security path is of june 2017. ro.build.version.security_patch=2017-06-01
We can try all exploits which came after that.
So far not able to find any exploit for tank, I'm sharing the latest bin and extract so we can collectively find some.
Drive Link
Click to expand...
Click to collapse
Good job! I have not seen the bin file available elsewhere - Amazon obfuscated the links to it quite well.
Just for kicks, I unpacked it, and installed com.amazon.tv.launcher on top of the one I had. So I now have an updated launcher:
Code:
Package [com.amazon.tv.launcher] (2b2540ce):
userId=32072 gids=[3003, 1028, 1015, 3002]
pkg=Package{c86435c com.amazon.tv.launcher}
codePath=/data/app/com.amazon.tv.launcher-1
versionCode=600612610 targetSdk=22
versionName=6.0.0.6-126
...
Hidden system packages:
Package [com.amazon.tv.launcher] (3f5557eb):
userId=32072 gids=[]
pkg=Package{22e23948 com.amazon.tv.launcher}
codePath=/system/priv-app/com.amazon.tv.launcher
versionCode=573001710 targetSdk=22
versionName=5.7.3-17
I may try your devicesoftwareota.apk at some point too.
bibikalka said:
Where does the downloaded OTA sit? Will this blocking app work for other Fire devices such as Fire tablets?
I researched Fire system app permissions a while ago, see this post https://forum.xda-developers.com/showpost.php?p=75226706&postcount=65
You can use a script like this to dump info for all system apps, and then look through the output:
Code:
for p in `pm list package -s | ./busybox awk -F"package:" '{print $2}'`; do echo -n "$p: "; dumpsys package $p ; done
(this requires that you upload 'busybox' to /data/local/tmp, and run it there)
What I observed is that SuperSu adds a whole new level of permissions to the system (a giant hole, if you will). None of the existing apps have that level of access. Of the existing system apps, it seemed that devicesoftwareota had some of the juicer permissions, which that still is not much. All it effectively does is that it grabs the update bin from the Internet, sticks it to a designated directory, and reboots to recovery which will continue the update. This can already be achieved on tablets via the sideloading option in recovery. I don't recall I spotted an existing app that could read the whole /data directory, as to enable backups in a simple format.
I've attached the output for devicesoftwareota for FireHD 10 2017, but that should be similar to the Fire stick.
Anyway, please do share if you find anything good!!!
Click to expand...
Click to collapse
You can find the ota files here
/sdcard/Android/data/com.amazon.device.software.ota/
Haven't tested on Fire tablets, you can try and let us know.
ranjeet choudhary said:
You can find the ota files here
/sdcard/Android/data/com.amazon.device.software.ota/
Haven't tested on Fire tablets, you can try and let us know.
Click to expand...
Click to collapse
is there a way to get a 5.2.6.3 flashable zip for the fire tv 2 box from this?
Which launcher do you have now? can we replace that launcher with any other launcher? I could code a gui for drag/drop so we add the apk then the exploit generates the apk. Of course the tool would tell us which system apps are available and with what they could be replaced. Another interesting question is would we be able to remove the bloatware by adding replacing system apps with empty apks?
bibikalka said:
Good job! I have not seen the bin file available elsewhere - Amazon obfuscated the links to it quite well.
Just for kicks, I unpacked it, and installed com.amazon.tv.launcher on top of the one I had. So I now have an updated launcher:
Code:
Package [com.amazon.tv.launcher] (2b2540ce):
userId=32072 gids=[3003, 1028, 1015, 3002]
pkg=Package{c86435c com.amazon.tv.launcher}
codePath=/data/app/com.amazon.tv.launcher-1
versionCode=600612610 targetSdk=22
versionName=6.0.0.6-126
...
Hidden system packages:
Package [com.amazon.tv.launcher] (3f5557eb):
userId=32072 gids=[]
pkg=Package{22e23948 com.amazon.tv.launcher}
codePath=/system/priv-app/com.amazon.tv.launcher
versionCode=573001710 targetSdk=22
versionName=5.7.3-17
I may try your devicesoftwareota.apk at some point too.
Click to expand...
Click to collapse
Anyone have any pre-configured apk's available to replace the amazon launcher with an alternative using the janus exploit?
I cannot get the janus exploit to work with windows + phyton 2.7
Code:
cd_start_addr = struct.unpack("<L", apk_data[cd_end_addr+16:cd_end_addr+20])[0]
struct.error: unpack requires a string argument of length 4
Will need to try linux, mac, or python 3.0
juanse254 said:
Which launcher do you have now? can we replace that launcher with any other launcher? I could code a gui for drag/drop so we add the apk then the exploit generates the apk. Of course the tool would tell us which system apps are available and with what they could be replaced. Another interesting question is would we be able to remove the bloatware by adding replacing system apps with empty apks?
Click to expand...
Click to collapse
Im using appstarter. Yes you can replace launcher. And Yes its possible to replacing system apps with empty apks.
You can try the attached dummy apk which is replacing com.amazon.tv.oobe.apk. oobe is responsible for triggering default launcher and apply any locks by amazon to block the device and also prevent BOOT_COMPLETED. This dummy apk kills the oobe so that we can listen for BOOT_COMPLETED in other apps and replace launcher.
ranjeet choudhary said:
Im using appstarter. Yes you can replace launcher. And Yes its possible to replacing system apps with empty apks.
You can try the attached dummy apk which is replacing com.amazon.tv.oobe.apk. oobe is responsible for triggering default launcher and apply any locks by amazon to block the device and also prevent BOOT_COMPLETED. This dummy apk kills the oobe so that we can listen for BOOT_COMPLETED in other apps and replace launcher.
Click to expand...
Click to collapse
Sigh
This looked to be the best chance I had at killing the Amazon TV Launcher on my FireTV 2 (5.2.6.2) but it said it was already installed when I tried (adb install out1.apk)
It 'succeeded' when I forced a reinstall (adb install -r out1.apk) but on a reboot the TV Launcher came up
Anything else I can try?
ranjeet choudhary said:
install this apk to block installing new update from amazon. it will still download the ota bin file for you to experiment, but the ota install will fail as the install code is removed.
Click to expand...
Click to collapse
can i use this to stop my tank 5.2.6.3 from updating to 5.2.6.7?
have router blocking working (with some...tinkering), but would like to be able to connect to other networks without worry of update.
A request
Hello,
I'm sure you have noticed the flurry of successfully rooted Fire TV devices lately, including the Fire TV Stick 2, Fire TV 3 and Cube.
Which would seem to make this exploit now obsolete. But not your modified DeviceSoftwareOTA.apk, which I used on my stick to block updates until I recently rooted it.
At current, the Fire TV Stick 2 has the most up to date software. But the Cube and Pendant are behind on updates because there is no way to download them without
some risk of the possibility of losing root for which the exploit has now been patched. But a modified DeviceSoftwareOTA.apk for these devices that would download the
update and not initiate an install would be an elegant solution. Allowing us to pull the update from the device and install it in a different manner.
This type of modification is unfortunately beyond my skill level, so I have attached a link to the current apk from one of these devices.
And am asking, if you have time, could you please have a look at it. And tell me if yours would work in its place, or modify it as you did yours by removing the install code.
Your help would be greatly appreciated.
Thanks.
DeviceSoftwareOTA.apk
2WhlWzrd said:
But a modified DeviceSoftwareOTA.apk for these devices that would download the
update and not initiate an install would be an elegant solution. Allowing us to pull the update from the device and install it in a different manner.
Click to expand...
Click to collapse
This exploit was patched above 5.2.6.3., if your FTV3/Cube is at a higher firmware, forget about this...
2WhlWzrd said:
Hello,
I'm sure you have noticed the flurry of successfully rooted Fire TV devices lately, including the Fire TV Stick 2, Fire TV 3 and Cube.
Which would seem to make this exploit now obsolete. But not your modified DeviceSoftwareOTA.apk, which I used on my stick to block updates until I recently rooted it.
At current, the Fire TV Stick 2 has the most up to date software. But the Cube and Pendant are behind on updates because there is no way to download them without
some risk of the possibility of losing root for which the exploit has now been patched. But a modified DeviceSoftwareOTA.apk for these devices that would download the
update and not initiate an install would be an elegant solution. Allowing us to pull the update from the device and install it in a different manner.
This type of modification is unfortunately beyond my skill level, so I have attached a link to the current apk from one of these devices.
And am asking, if you have time, could you please have a look at it. And tell me if yours would work in its place, or modify it as you did yours by removing the install code.
Your help would be greatly appreciated.
Thanks.
DeviceSoftwareOTA.apk
Click to expand...
Click to collapse
Thanks for the update on root, i totally missed it. this opens a whole lot of modification possible. Let me check if the exploit still works. Even if it doesn't work, with root we can force replace with modified apk.
I read some time ago that there will be a new update that will block Kodi is this an update that could do this ?
ranjeet choudhary said:
Thanks for the update on root, i totally missed it. this opens a whole lot of modification possible. Let me check if the exploit still works. Even if it doesn't work, with root we can force replace with modified apk.
Click to expand...
Click to collapse
Thank you, for your reply.
I thought that it should be possible to force this with root, these devices have Fire OS 6 — Based on Android 7.1 (API level 25).
So I don't think the vulnerability would apply, would it? Unlike the 2nd generation stick with Fire OS 5 — Based on Android 5.1 (API Level 22).
But there still may be hope.
We are rooted with Magisk and I have installed the Magisk port of Xposed. And there is HDXposed, which is said to be able to
disable the signature check. But I don't see anyone using it with Fire OS 6 yet, only Fire OS 5 mods. So I don't know it will work anyway.
I shall patiently await your reply.
Thanks again for your efforts.
[deleted]