Hi everybody,
unfortunately I couldn't find a final answer to my question:
I know (or I think I know from your excellent forum):
- I can extract a stock ROM (and modify it)
But:
- can I resign the whole ROM using my own signature key, flash it back on the device and then use this to build an app (and sign/add/install it) running with e.g. android:sharedUserId="android.uid.phone" and androidrocess="com.android.phone" ?
In other words: can I replace the system signature key of a stock ROM with my own one, being able to sign my own apps with it? Or is that only possible by building the whole (custom) ROM myself?
I don't need a detailled description, a 'Give it a try!' or 'Wouldn't work because of...' however would be great!
Thanks,
deep blue
ps: any legal advice or warning is welcome, too, although I only want to dig a little deeper into my own phone.
yes you can
go to /system
and look for the build.prop
open it and
ro.build.display.id= Put Your rom name here
Thanks for your answer, locomain!
Maybe I didn't explain that correctly:
I don't mean the signature you can see when checking the phone-info. I'm thinking about the key, the ROM is signed with. If you sign your app with the same key, you can do much more stuff. As an example, my old HTC Desire came with a hidden app that displayed a lot of low-level radio-stuff (Field-Test-Monitor). This is only possible because this app is signed with the same key as the system itself.
My idea was to take a stock HTC-ROM and resign it with my own key, so I could build an app with extraordinary privileges for my own phone (like the app described above).
BR,
deep blue
Please use the Q&A Forum for questions Thanks
Moving to Q&A
[Q+A] [ROM] Resign stock ROM with my own signature key
For those who are interested:
using a downloaded CyanogenMod-signed-zip it worked, I just removed all signatures (from zip and all included apks) and re-signed everything using my own key. Afterwards I was able to create a small app that is allowed to run in the com.android.phone-process.
So I think it should work with stock-ROMs also, as long as I root them by the way.
[FIX][XPOSED][4.0+] Universal fix for the several "Master Key" vulnerabilities
You may be aware of recent news about several different security vulnerabilities that allow replacing code on a signed APK without invalidating the signature:
Master Key (Bug 8219321)
An issue related with duplicate entries on the ZIP / APK files.
It was patched by Google back in February 2013 and shared with OEMs, and some of the newer devices might have already received the fix in a recent stock update. At least both Xperia Z 4.2.2 and Galaxy S2 4.1.2 contain the fix; CM has also recently patched it, on this commit.
More info can be found on @Adam77Root's thread here: http://forum.xda-developers.com/showthread.php?t=2359943
Bug 9695860
This also originates in the ZIP file parsing routines, and was disclosed just a few days ago immediately after the previous one was made public. The correction has already been applied by Google to the code (this commit), but it's very likely that its rollout on stock ROMs will take a long time especially on non-Nexus devices.
You can read more about it here.
To know if you're vulnerable, use SRT AppScanner mentioned above.
Unless you're running CM 10.1.2, there's a fairly big chance that you have this issue, at least as of this moment.
Bug 9950697
It's yet another inconsistency in ZIP parsing that could be abused in very a similar way to the previous one.
This one is a bit special to me, since I was fortunate enough to be the first one to report it on Google's bugtracker
It was discovered around the time that the previous bug was acknowledged and Android 4.3 was a few days from being released, but despite the prompt report it was unfortunately too late to include the fix in time for the release; Therefore it wasn't disclosed till Android 4.4 sources came out and I had also decided not including a fix for in on this module, since it would be an easy way to learn about the extra attack vector.
Kudos to Jeff Forristal at Bluebox Security, who I learned was also working on that exact problem and helped me report it properly to Google, and also to Saurik who already released a Substrate-based fix and has written a very interesting article about it here.
Checking if you're vulnerable
You can use some 3rd party apps to test your system, such as:
- SRT AppScanner
- Bluebox Security Scanner
On Android 4.4 all these bugs should be fixed, and therefore this mod is not needed. But you can run one of these scanners to make sure you're not vulnerable.
While technically different, these vulnerabilities permit that legitimate APKs can be manipulated to replace the original code with arbitrary one without breaking the signature. This allows someone to take an update from a well known publisher (e.g. Google Maps), change the APK, and a device receiving it will happily apply the update as if it was indeed from that publisher. Depending on the apps being updated in this way, priviledge escalation can be achieved.
Google has already mentioned that all apps published on the Play Store are checked for this kind of manipulation, but those of us installing APKs from other sources aren't safe.
The universal fix
Since decompiling, fixing and recompiling the code for every possible ROM version is way beyond anyone's capability, the awesome Xposed framework by @rovo89 proves itself once again as an invaluable tool.
By creating hooks around the vulnerable methods and replacing the buggy implementation with a safe one, it's possible to patch the 2 issues on the fly without ever changing the original files. Applying the fix is as easy as installing and enabling an Xposed module.
Installation steps
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key multi-fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key multi-fix
4. Reboot
You should now see an image similar to the attached one when opening the app. The green text shows that the module is active and the vulnerabilities have been patched in memory.
Download
Grab it from Google Play (recommended, as you'll get updates) or use the attached APK. The files are the same.
Version history
2.0 - Fix bug 9950697; additional corrections taken from Android 4.4 (also supports GB, provided you have a working version of Xposed Framework for your ROM)
1.3 - Fixed problems with parsing some zips depending on the rom original code
1.2 - Added 2 additional zip entry integrity checks that were missing
1.1 - Support for additional devices with modified core libraries (e.g. MTK6589)
1.0 - Initial version
Sources
Available on GitHub
If you appreciated this fix, consider donating with Paypal.
Thanks!
FAQ
Fequently asked questions
[ 1 ]
Q: Bluebox Security Scanner still says my phone is unpatched after installing this... Any ideas why?
A: Make sure to click the Refresh entry on the app's menu and it should change to green once the mod is active.
[ 2 ]
Q: Bluebox Security Scanner says that the 2nd bug is not patched even after refreshing but SRT AppScanner says it's patched. Which one is right?
A: The scanner was mis-detecting the 2nd bug and it got fixed in version 1.5. Make sure you update Bluebox from the Play store.
[ 3 ]
Q: Does the module permanently patch the vulnerability or is it only when the module is active? If for example, I activate the module and reboot, then after verifying that the exploit is patched, deactivate the module. Would I still be patched? I guess what I'm asking is if I need to have this module active at all times to be patched? Permanent fix, or Just while the module is installed?
A: The fix is not permanent. It's applied only whenever the module is installed and active. If you remove it, after the next boot you're back with the original code from your ROM (which might have the bug or not).
Thank you, this would help a lot
Sent from my GT-I9500 using Tapatalk 4 Beta
Thank you but I don't see any link to the xposed patch app
Envoyé depuis mon LT28h en utilisant Tapatalk 4 Beta
Marsou77 said:
Thank you but I don't see any link to the xposed patch app
Click to expand...
Click to collapse
Have a look now
I needed to create the thread first in order to include the link on the app itself.
Thanks! I was just googling to see if someone had already done this before writing it myself!
XPosed is amazing sauce for Android.
The 4.1.2 update for the T-Mobile galaxy s3 is already patched.
Thanks for the info OP.
Maxamillion said:
The 4.1.2 update for the T-Mobile galaxy s3 is already patched.
Thanks for the info OP.
Click to expand...
Click to collapse
The second bug as well? Check java.util.zip.ZipEntry on /system/framework/core.jar and see if the readShort() values are properly converted to unsigned.
.....
Bluebox security still says my phone is unpatched after installing this... Any ideas why?
Sent from my HTC Sensation Z710e using xda app-developers app
Shredz98 said:
Bluebox security still says my phone is unpatched after installing this... Any ideas why?
Click to expand...
Click to collapse
No idea why it doesn't refresh automatically each time you execute the app, but access the Refresh option from the menu and it should change to green once the mod is active.
Tungstwenty said:
No idea why it doesn't refresh automatically each time you execute the app, but access the Refresh option from the menu and it should change to green once the mod is active.
Click to expand...
Click to collapse
Yeah you're correct mate, says patched when I rescanned so all good the patch does exactly what it says, brilliant work! Was beginning to think I would have to live with this security hole active on my device!
Sent from my HTC Sensation Z710e using xda app-developers app
Shredz98 said:
Yeah you're correct mate, says patched when I rescanned so all good the patch does exactly what it says, brilliant work! Was beginning to think I would have to live with this security hole active on my device!
Click to expand...
Click to collapse
Added to the FAQ (post #2)
Hey Everyone,
I've found an alternative for the blueboox app. It's called the SRT AppScanner and seems to work better than the BlueBox Scanner and it provides more functionality, too.
Since I'am a new user, i can't post links. Simply query SRT AppScanner in the PlayStore.
Best regards
Boradin
Thanks for great patch.
I've tested with SRT AppScanner and found I'm still vulnerable to bug 9695860.
How do I make sure bug 9695860 was fixed?
mnirun said:
Thanks for great patch.
I've tested with SRT AppScanner and found I'm still vulnerable to bug 9695860.
How do I make sure bug 9695860 was fixed?
Click to expand...
Click to collapse
When I initially installed SRT it was always giving me 2 greens even with the mod disabled, even though I checked the code for my ROM and the 2nd bug is there.
Now, after a very recent update, it always gives me a red on the second bug even with the mod active. I'll need to double check how they are doing the detection because it doesn't seem to be correct.
Bluebox Security, on the other hand, does reflect the change although it only detects the first bug. Running it on an emulator with a vulnerable ROM correctly said so, and after applying the mod and forcing a rescan it will change to no longer vulnerable.
SRT AppScanner has just received an additional update from Play and now appears to correctly detect the status of bug 9695860 depending on whether the mod is active or not and if your base ROM is vulnerable.
The sources are now available on GitHub (check 1st post).
Tungstwenty said:
SRT AppScanner has just received an additional update from Play and now appears to correctly detect the status of bug 9695860 depending on whether the mod is active or not and if your base ROM is vulnerable.
Click to expand...
Click to collapse
Confirmed, you patch is now detected by SRT AppScanner.
Thank you.
Tungstwenty said:
You may be aware of recent news about 2 different security vulnerabilities that allow replacing code on a signed APK without invalidating the signature:
Master Key (Bug 8219321)
An issue related with duplicate entries on the ZIP / APK files.
It was patched by Google back in February 2013 and shared with OEMs, and some of the newer devices might have already received the fix in a recent stock update. At least both Xperia Z 4.2.2 and Galaxy S2 4.1.2 contain the fix; CM has also recently patched it, on this commit.
An easy way to know if you're vulnerable is installing this app by Bluebox Security. Update: An ever better one is SRT AppScanner, which can detect both bugs.
More info can be found on @Adam77Root's thread here: http://forum.xda-developers.com/showthread.php?t=2359943
Bug 9695860
This also originates in the ZIP file parsing routines, and was disclosed just a few days ago immediately after the previous one was made public. The correction has already been applied by Google to the code (this commit), but it's very likely that its rollout on stock ROMs will take a long time especially on non-Nexus devices.
You can read more about it here.
To know if you're vulnerable, use SRT AppScanner mentioned above.
Unless you're running CM 10.1.2, there's a fairly big chance that you have this issue, at least as of this moment.
While technically different, both of these vulnerabilities permit that legitimate APKs can be manipulated to replace the original code with arbitrary one without breaking the signature. This allows someone to take an update from a well known publisher (e.g. Google Maps), change the APK, and a device receiving it will happily apply the update as if it was indeed from that publisher. Depending on the apps being updated in this way, priviledge escalation can be achieved.
Google has already mentioned that all apps published on the Play Store are checked for this kind of manipulation, but those of us installing APKs from other sources aren't safe.
The universal patch
Since decompiling, fixing and recompiling the code for every possible ROM version is way beyond anyone's capability, the awesome Xposed framework by @rovo89 proves itself once again as an invaluable tool.
By creating hooks around the vulnerable methods and replacing the buggy implementation with a safe one, it's possible to patch the 2 issues on the fly without ever changing the original files. Applying the fix is as easy as installing and enabling an Xposed module.
Installation steps
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key dual fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key dual fix
4. Reboot the device (a Soft reboot is sufficient)
You should now see an image similar to the attached one. The green text shows that the module is active and the 2 vulnerabilities have been patched.
Download
Grab it from Google Play or use the attached APK.
Sources
Available on GitHub
If you appreciated this fix, consider donating with Paypal.
Thanks!
Click to expand...
Click to collapse
Thank you for this patch, but can we install this mod over "REKEY" patch or remove rekey and enable this patch instead ??
Hi there -
short prologue: I am working on my bachelor thesis and must develop a service that keeps a record of how often a user actively uses the application permission settings of Android 6 and above. The main goal is to have a custom ROM which can be deployed on several phones to conduct a survey.
I identified the file where these settings are stored:
Code:
/system/users/0/runtime-permissions.xml
I want to set up a service running a FileObserver to keep track of the changes in this file. The file is not accessible by normal applications (permission -rw-------) but the service has to run without superuser.
So I want to sign my application with the platform key to obtain system permissions. I am totally clear on the purpose of this security concept and I know that I cannot get the original key. The resulting ROM is not going to be public and is used only in a controlled group for research purposes.
My question is how to exchange the signature/key with what the system applications of my actual ROM are signed. So that I sign my own apk with the same key so it has the special permission. I found the answer to this exact question on stackoverflow but it is quite old and I did not succeed with this explanation.
Do you know if there is another, more current approach?
Thanks in advance!
Device is a Xiaomi Redmi 4X running stock MIUI 9 (Android 7.1.2)
Just have the app built as part of the rom. This will make sure they both have the same signature.
zelendel said:
Just have the app built as part of the rom. This will make sure they both have the same signature.
Click to expand...
Click to collapse
What do you mean by "built as part of the rom"? I cannot build the rom from aosp because the device should run the original MIUI firmware. I used SuperR's Kitchen to modify the rom. Is this not suitable?
That will not work no. Maybe you could try using their patch rom setup. As very little is done with miui here, you mugjt be better off asking in n their forums.
zelendel said:
That will not work no. Maybe you could try using their patch rom setup. As very little is done with miui here, you mugjt be better off asking in n their forums.
Click to expand...
Click to collapse
Can you explain, why this wont work? I supposed I just have to exchange all the signed apk files. When I re-sign them with apksigner then they also obtain the self-signed certificate containing the public key. So why is this not enough? Is there another instance in the OS which checks the app signature on boot?
The entire system partition uses the same signature. So I guess you could go through and recompile everything with the new key but I doubt it would work. Many oem system apps won't work without their oem signature.
Like I said. You maybe better off asking over in the miui forums as very little is done here for it.
Hi everyone,
I own a PonoPlayer which is running Android 2.3 (ARM v7 / Cortex A8). I'd like to perform some software upgrades but sadly the device is not running adb.
I'd like some tech advice before going deeper, just to make sure I'm using the proper approach and not wasting my time
Disclaimer: I read everything I could find about the Pono (there's some old thread about it on this forum) but that didn't really help.
What I already tried:
Because I'm more a developper and vulnerability researcher I started by what I'm comfortable with: looking for vulnerabilities. I decompiled the main APK (player-release.apk) but found nothing obviously exploitable.
The last available firmware update is version 1.0.6. The upgrade bundle is clearly based on that : https://github.com/Lekensteyn/make-gapps-zip
Decompressing the archive using apktool shows:
boot.img
META-INF (which contains META-INF/com/google/android/updater-script)
recovery
system
The update bundle seems to be signed using the test-keys found on the above repository. So I tried to forge a fake 1.0.7 update bundle by simply unpacking 1.0.6 and repacking + signing. This fails, the player detects the 1.0.7 update bundle, tries to perform the upgrade and is stuck. Obviously, someting wrong happens but since I've no log or any kind of remote access, there's no way for me to debug.
Next step:
I plan to setup a Android 2.3 emulator, running a dummy ARMv7 image and use it to load the 1.0.6 legit update bundle. Thus I would have something close to the real Player image.
From this, I would be able to load my 1.0.7 fake update and see what goes wrong.
I this something obvious that I'm missing? I this the proper approach?
Thanks for any advice!
Allright, here's my own follow up !
I ended up finding how to create an OTA package for the Pono Player.
Basically, I start from the last known firmware (1.0.6), patch it and re-bundle it.
Hopefully, the Pono Player uses the Android test keys ...
My main issue (for the last 4 years..) was that the whole OTA package is signed, not just its contents, by adding a specially crafted zip comment.
This can be enabled by using the "-w" option of the signapk command.
I've successfully updated the licences.txt (let's start small ) file on the device.
All the required scripts for unpacking/repacking an OTA package are available here: https://github.com/NothNoth/PonoPwn
hello, this is my first time posting in the forum and I apologize if by any chance I have wrong section of the forum to present my problem.
Basically my problem is this:
Until yesterday with my android device "Samsung Galaxy TAB A" android 7.1.1 version I could play the game "Match Masters" which you can download the apk directly from here "https://play.google.com/store/apps/details?id=com.funtomic.matchmasters&hl=it&gl=IT".
As of today opening the game I get a screen where it tells me that in order to play the game you must have "Android 8 or higher" on your device. I will preface this by saying that I have not updated the app which was working perfectly until yesterday, so I assume the android version check is done server side. I ask if there is a way to circumvent the device version check by going to modify the apk? If yes, what is the procedure?
I thank you for your help.
I also attach the screen with the message
Modifying an app's version would require to rewrite its APK.
xXx yYy said:
Modifying an app's version would require to rewrite its APK.
Click to expand...
Click to collapse
I have downloaded the application "APK editor Studio" which allows you to edit the APK game file in all its parts and then automatically recompiles the new file already signed with the signature in order to install it. The problem is that I don't know what is the string in the APK file that sends the device version check. If I could block or modify this string so that I could make the game think I was using an Android 8 phone, I would be able to play again. Is there any gurus in the field of APK editing who can direct me on how I can edit the file? Thank you, I look forward to hearing from you.
So you want to fool the app about tablet's Android version? If so then that's a complete other thing: this can be done by modifying Android's system file named build.prop what is located in partition /system
Note: Editing build.prop requires Android is got rooted and re-booted after changes made.
xXx yYy said:
So you want to fool the app about tablet's Android version? If so then that's a complete other thing: this can be done by modifying Android's system file named build.prop what is located in partition /system
Note: Editing build.prop requires Android is got rooted and re-booted after changes made.
Click to expand...
Click to collapse
I modified the file you told me by writing the Android 8.0 version but unfortunately opening the game always shows the same screen. I also tried using the emulator application "Bluestacks" on the computer but my computer does not have the requirements to virtualize the game. Is there any emulator that can be installed directly on the tablet that goes to emulate another device?