Related
Hi all -
Apologies if this is a stupid question. I'm trying to create an app that has the protected 2 level DEVICE_POWER permission. Is this possible without having a full-blown Custom ROM?
Things that I have tried:
1) Move apk from data/app to system/app [in packages.xml the app is then classified as system="true" but isn't allowed to get the permission]
2) In packages.xml, manually hack the certs line to be the same as a system app that does have the DEVICE_POWER permission
3) try to hack the file in /system/etc/permissions to add another gid to DEVICE_POWER or the uid of the app that I'm running
4) tried to re-sign the framework-res.apk and the other other system apk's with the same cert with the AOSP platform key [although google does seem to sign some apps with that key, B&N seems to have done the "right" thing and not signed everything with the platform key]. Just gets caught in a bootloop
In the devicemanager.db under /data/data/com.android.providers.settings/databases, in the registry table, it does show the hash of the system's private key ... wasn't sure if I could do anything with that though.
Someone created a custom screensaver that puts the cover of the book you're reading as screensaver and modified the Settings.apk to do so. I don't quite get how he was able to do that and still have the signature remain intact?
Thanks for the help!
AFAIK you have to build a custom ROM to do this.
Yeah I think so too, apps wanting that permission need to be signed with the platform key afaik.
This patch is against framework.jar for Android 4.4 (KRT16M) and allows you to modify system packages without them being verified.
Why would you want this?
Re-signing isn't possible with many google packages as they check their own certificates at runtime (GooglePlayServices). This patch allows you to make any modifications you like to system packages, while keeping the original certificates.
Isn't it unsafe to not verify packages?
Yes. However, this patch only applies to system packages. Those downloaded from the market are still verified as usual. The /system filesystem is read-only by default. The only way for a package to be infected is if an application has root privileges (via SuperSU or similar). Of course you should assume that after giving an application elevated privileges it could infect packages with or without this patch.
How does it work?
Packages in android are loaded by PackageParser. The method collectCertificates attempts to read the file AndroidManifest.xml from system packages, which causes the underlying JarFile to verify it against the embedded signature. If everything was successful it returns the certificate. This patch changes collectCertificates to load and return the certificate directly, without trying to read AndroidManifest.xml.
You must delete META-INF/CERT.SF and META-INF/MANIFEST.MF from any package you modify. This patch doesn't change the underlying JarFile code, which by default uses those files to check entries as they're read from the archive. You should leave META-INF/CERT.RSA alone as that's the certificate this patch loads.
The patch was produced against framework.jar from the factory image KRT16M using baksmali v2.0 .
SHA1
Code:
433eeec32008015a1f54964bf036f4eaddb3864b framework-jar-KRT16M-raw-certificates.patch
75b5999203f355cf45387a424246e988440c3068 framework.jar
*reserved*
Thanks for this great mod.. Modify system packages works but when add new apk system (like sony apps to my CM 11 device), ktkat won't accept as app installed, even when I don't modify anything in apk.
Sent from my Xperia Mini Pro using Tapatalk
I've been toying around with the "Runtime" object in java for an app I'm building.
With this object, you can execute various commands on the phone's shell. My question is, is there any way to modify the permissions of the Runtime object? So, does adding additional permissions to the manifest modify what Runtime can do? Does anything else modify what it can do?
Highbrow said:
I've been toying around with the "Runtime" object in java for an app I'm building.
With this object, you can execute various commands on the phone's shell. My question is, is there any way to modify the permissions of the Runtime object? So, does adding additional permissions to the manifest modify what Runtime can do? Does anything else modify what it can do?
Click to expand...
Click to collapse
It runs in the process of your app. So it should have the same permissions which your app has.
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
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]