Related
Does anyone know how to programmatically enable the network location finding? I've read that it's not possible to do normally because of user privacy protection (i.e. you can't even request a permission that lets you do it), but I'm wondering if it's possible to do it using a rooted phone. Does anyone know? I can write apps using the normal SDK, but I've never tried to do anything using the fact that my phone is rooted or the superuser permissions app.
This would be for an HTC Hero running a (very old) Android v1.5 MoDaCo ROM.
Or, if a widget already exists that lets you do this, please let me know
Steven__ said:
Does anyone know how to programmatically enable the network location finding? I've read that it's not possible to do normally because of user privacy protection (i.e. you can't even request a permission that lets you do it), but I'm wondering if it's possible to do it using a rooted phone. Does anyone know? I can write apps using the normal SDK, but I've never tried to do anything using the fact that my phone is rooted or the superuser permissions app.
This would be for an HTC Hero running a (very old) Android v1.5 MoDaCo ROM.
Or, if a widget already exists that lets you do this, please let me know
Click to expand...
Click to collapse
Note that Settings.apk is just an app and it can change these settings. My guess is it uses some private APIs to accomplish that. You could look into Android sources and check, what is this API, then use it in your own application. You will have to use system shared user in it and sign it with testkeys.
Brut.all said:
You will have to use system shared user in it and sign it with testkeys.
Click to expand...
Click to collapse
That's the part I don't know how to do. I've found the settings calls it makes from the source code:
Code:
Settings.Secure.putString(getContentResolver(),
Settings.Secure.LOCATION_PROVIDERS_ALLOWED,
"+" + LocationManager.NETWORK_PROVIDER);
but that dies with a permission failure "java.lang.SecurityException: Cannot write secure settings table". I've tried to grant myself that permission in the manifest using:
Code:
<uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS"/>
but that permission doesn't seem to be granted, as a this.checkCallingPermission always returns -1.
Is there a tutorial on how to use a "system shared user", or would it be easy for you to explain?
I'm not really sure, this is knowledge of rom cookers and I'm not one of them
But... look into AndroidManifest.xml from Settings.apk:
Code:
<manifest android:sharedUserId="android.uid.system" android:versionCode="7" android:versionName="2.1-update1" package="com.android.settings"
xmlns:android="http://schemas.android.com/apk/res/android">
This apk uses android.uid.system and so it has superpowers. You must set this UID for your apk, but to do that apk must be signed with same keys as other system files. I think you must use testsigner tool and fortunately there are many threads/articles about that
Yeah, it looks like I'd have to resign the whole ROM to make sure that my app had the same key as the system files. Hmm, I've swapped tracks to investigating how to get my app to work through the Superuser app, which I can half do now. However, this is getting more complicated to solve than I had hoped for - I think for a while I might just accept that clicking on button that directly brings up the settings menu will be enough. Thanks for trying!
I'm trying to gain read-only access to one of the sqlite databases on my phone via an installed application. It seems as though the typical use case is for applications to only interact with their own databases, but I cannot find any documentation explicitly saying that sql readonly database access is sandbox'd.
When I attempt to use SQLiteDatabase.openDatabase("/path/to/the/database.db", null, SQLiteDatabase.OPEN_READONLY) I get an error stating that the file could not be opened. Unfortunately no details on the reason get thrown along with the error.
So my question is this: Is it possible for an installed application to gain read only access the system's sqlite databases, in particular com.android.providers.settings/settings.db? There are settings in there that I cannot access via the typical API calls so it looks like a query is my only option.
Thx,
Nick
I've developed an open-source java library for signing files onboard the device and an app that demonstrates its use.
The app is "ZipSigner" and its in the market. Binaries and source for the libraries and app are available at http://code.google.com/p/zip-signer.
More information on using the app can be found at http://sites.google.com/site/zipsigner/
BASIC API USAGE:
Code:
import kellinwood.security.zipsigner.ZipSigner;
try {
// Sign with the built-in default test key/certificate.
ZipSigner zipSigner = new ZipSigner();
zipSigner.setKeyMode('testkey');
zipSigner.signZip( inputFile, outputFile);
} catch (Throwable t) {
// log, display toast, etc.
}
I developed this code as part of an effort to create a theming application that creates update.zip files on the device (ZipThemer).
I tested by having Titanium Backup generate its update.zip, signed it with the ZipSigner app, and then flashed it in recovery.
Enjoy,
Ken
Version 1.1
Version 1.1 is out. The library code size is significantly smaller in this version since I reduced the need to include sun.security.pkcs and sun.security.x509. For example, the ZipSigner app is now 1/6 its former size (now 47kb).
I'm not sure I see the relevance of this. I don't know about all devices, but from my understanding, for and update.zip to be accepted by the device, it needs to be signed by a trusted authority (i.e HTC or Samsung, etc.). On the other hand, if you're rooted and have a custom recovery partition, they ignore signatures anyway. Is it the case that some devices require a signed update.zip, but then don't give a hoot who signs it?
Yes, the root recovery programs do verify the signature, and no, the certificate does not need to be trusted.
I'm assuming this API its only going to be picked up for use in root-enabled apps where the developers can assume the users have the ability to flash updates.
kellinwood said:
Yes, the root recovery programs do verify the signature, and no, the certificate does not need to be trusted.
Click to expand...
Click to collapse
All of them? Are you sure? Clockwork recovery on my HTC Aria cares not-at-all about signatures on update.zip's.
Am I sure? No. After a bit of research it appears the recovery programs, if they verify the signature, require the signing certificate to match one built into recovery itself. In the case of most root recovery programs I think this is the test certificate available from Google, and also the one used by default in my code.
Clockworkmod recovery has the option to turn off signiture verification
Sent from my ADR6300 using XDA App
Runawaycoder said:
Clockworkmod recovery has the option to turn off signiture verification
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
Yes, but the question seems to be: what signatures does it accept? The whole point is to verify the authenticity of the update, but if it uses the google debug key, then anybody can sign an update with that key thus eliminating any benefit of authenticity verification.
In other words, why bother turning it on at all?
Gene Poole said:
Yes, but the question seems to be: what signatures does it accept? The whole point is to verify the authenticity of the update, but if it uses the google debug key, then anybody can sign an update with that key thus eliminating any benefit of authenticity verification.
In other words, why bother turning it on at all?
Click to expand...
Click to collapse
If you use Amon_RA you need to sign them.
I'm not familiar with Amon_RA (other than the Egyptian deity). What certificates does it use for authentication?
Amon_RA on my Droid Eris allows update.zip files to be flashed if they've been signed with the Google test key.
Sent from my FroyoEris using XDA App
I was force to released "ZipSigner 2" today to deal with app signing issues that prevent further updates to the original app. There will be no more updates to the original version. Please uninstall ZipSigner and install "ZipSigner 2" in its place. See this page for the gory details of what went wrong.
Ken
Hello developer! I found your app while desperately trying to sign an app that I modded. It seems to work, but the output file is in .zip. I renamed it to .apk but it doesn't allow me to install, and gave a parse error message. Is it possible to troubleshoot for me? Thanks!
Send me a pm and attach the unsigned apk and I'll try and reproduce the problem.
Ken
qHD (Sensation XE). Bug?
App name change
I've just uploaded version 3.3 to Google Play. In this version I've renamed the app from "ZipSigner 2" to just "ZipSigner".
Ken
[zipsigning] Hacked Candy Crush
Hi Dev,
Great work! i have a question though, i have modified the file inside the candy crush APK files (1000 lives + 200 moves), and using your app to sign it again, it installs but the game cannot connect to facebook. Would you know why is this?
vertcam9 said:
Hi Dev,
Great work! i have a question though, i have modified the file inside the candy crush APK files (1000 lives + 200 moves), and using your app to sign it again, it installs but the game cannot connect to facebook. Would you know why is this?
Click to expand...
Click to collapse
Yes, I know why it doesn't work. Its complicated, but I'll do my best to explain...
In order to login to Facebook from an Android app, the app developer must first register the app with facebook. Facebook provides the developer with an API key value, and the developer provides Facebook with the app's "keyhash" value (computed from the certificate used to sign the app).
Developers usually hard-code the API key value into the app because it must be passed to Facebook when the app requests a login, along with any credential information such as the user's email and password. Facebook then recomputes the keyhash value using the app's certificate, and if the API key and computed keyhash combination don't match the expected value the login fails.
Long story, short... resigning the app with a different key/certificate is what breaks the login. In theory you can fix this but the level of effort is high... You'd have to register an app yourself on developers.facebook.com, then hack the Candy Crush code to swap in the API key value you've been provided by facebook, and register the keyhash of the certificate you are using to re-sign the hacked app. The difficult part IMO is finding and modyfing the API key value inside the original app.
Ken
@kellinwood, I sent you an email recently with this message:
First I want to thank you for creating ZipSigner library as I don't have to rewrite the whole thing.
I have some troubles using your latest zipsigner-lib 1.17 though as I can't use the zip signed with either media, platform, shared, testkey key with CWM 6.0.4.3 (on N7 2012 for that matter). The produced zip does not pass signature verification. I also tried your app version 3.4 and it has the same issue.
I attach the unsigned zip here for you. This zip is generated by my app here https://play.google.com/store/apps/details?id=me.timos.busyboxonrails
Click to expand...
Click to collapse
Any help will be greatly appreciated.
bigeyes0x0 said:
@kellinwood, I sent you an email recently with this message:
Any help will be greatly appreciated.
Click to expand...
Click to collapse
What are you using to verify the signature created by ZipSigner, the thing that says it can't verify the signature... e.g., jarsigner on the desktop? the recovery program on your device? Please attached the signed version of the zip file that doesn't pass verification. Thanks,
Ken
I've got NST rooted with Nook Manager and I had installed NTGAppsAttack. My problem is that wherever I go with https I get security certificate error and text: "The name of the site does not match the name on the certificate". I know that I can get this kind of error if I would have wrong date but I have correct date.
The problem involves any website accessed via https.
I don't know if I had this problem from beign or it started after rooting. I have backup but I will have access to it in a week or so and maybe there's a simple solution to my problem.
I've removed GAPPS and changed browser from stock to Opera Mini and don't get those errors.
dflt said:
I've got NST rooted with Nook Manager and I had installed NTGAppsAttack. My problem is that wherever I go with https I get security certificate error and text: "The name of the site does not match the name on the certificate". I know that I can get this kind of error if I would have wrong date but I have correct date.
Click to expand...
Click to collapse
I have the same problem (and a problem with the Market). Did you find the problem, or a way to fix it?
The stock browser has problems with wildcard certificates (e.g. *.example.com instead of www.example.com). Use another browser as dflt discovered.
So after reading about all the App Store hacks that have developed around Fiddler2, I decided to give it a go myself. After setting up the proxy, I noticed that most SSL-based transactions were failing to connect on my device (Windows Updates, Email, etc).
I exported the SSL cert that fiddler 2 installed on my development PC, emailed it to myself, and installed it on my Windows Phone device. LO and Behold, Most of my SSL issues went away! (App store still woudn't auth). More Interestingly, Windows Updates started checking for updates successfully. These transactions are done with SOAP calls.
The basic process is as follows:
1. Phone initiates a connection to the windows update server
2. a series of cab files are downloaded containing certificate and base URL info of the update server
3. the phone connects to the update server with a list of all updates it has installed as well as a unique device identifier.
4. the server responds with a list of updates that it wants the phone to evaluate.
5. If the phone decides it needs the update, it sends a request to the server for instructions to deter
6. the server responds with a specially crafted packet that contains a link to where the microsoft cab can be downloaded from as well as a checksum of the cab file and evaluation instructions to determine if the update is needed. (checking registry keys, etc the SOAP commands contain things like RegRead32)
7. the phone then downloads and installs the update, if needed.
Fiddling around with fiddler, I was able to remove the "filter" GUID from the phones request to the server. As a result, it evaluated and installed any update it could get its hands on. The Hardware Test app still shows that my last update was 5/1/2013, but the number of updated packages included in that update jumped from 83 to 200!
I have some more experiments I would like to try (such as trying to blindly write a reg key instead of just reading it...anyone know of a good one?). I am also wondering if I can somehow package a Microsoft cab file, and tell the update mechanism to download and install it. Depending on how it evaluates the cabs, I might be able to get away with signing the cab with the private key from the Fiddler certificate I installed.
Just thought I'd pass along
Very, very nice finds! I had noticed the cert pinning used on the store and on dev-unlocking, but apparently had failed to look into the update process.
Give me a little while and I'll find you the reg key used for dev-unlock. I can't guarantee you that I'll be able to give you the exact value you need - they seem to have changed the format since WP7, and I'll be working blind from templates and policy files here - but it's worth a shot. Mind you, I wouldn't be surprised if the whole process is read-only, or if the responses from Microsoft are signed (although you could try re-signing them, I guess). For what it's worth, creating an entire update from scratch (or even editing one) is unlikely to work; Windows has required a Microsoft signature (not just any trusted signature) on update files for many years now. It's certainly possible that they messed that up, though.
I also kind of want to see if some of the recent ZIP signature validation bypass exploits from Android (where you could create a ZIP file containing multiple files that have the same name, and the original would be used for the signature but the *last* copy of each file would be the one actually unpacked) might be made to work as well. I've got some ideas about that... not sure if it would work for the update format, though.
Please keep researching this!
Not that i seriously looked into that, but you may probably consider these entries as interesting
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\DeviceReg\Install]
"MaxUnsignedApp"=DWORD:A
[HKEY_LOCAL_MACHINE\Software\Microsoft\PackageManager]
"EnableAppLicenseCheck"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\PackageManager]
"EnableAppSignatureCheck"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\PackageManager]
"EnableAppProvisioning"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\.NETCompactFramework\Managed Debugger]
"Enabled"=dword:0
"AttachEnabled"=dword:1
[HKEY_LOCAL_MACHINE\Software\Microsoft\Silverlight\Debugger]
"WaitForAttach"=dword:1
Some of those might get obsolete already, though.
Though, the most interesting thing one can do with registry is enabling KD.
For what it's worth, creating an entire update from scratch (or even editing one) is unlikely to work; Windows has required a Microsoft signature (not just any trusted signature) on update files for many years now.
Click to expand...
Click to collapse
Yeah
I've never really looked at the fact: which certificate is used by actual cabs? look at *.cat file
GoodDayToDie said:
Very, very nice finds! I had noticed the cert pinning used on the store and on dev-unlocking, but apparently had failed to look into the update process.
Give me a little while and I'll find you the reg key used for dev-unlock. I can't guarantee you that I'll be able to give you the exact value you need - they seem to have changed the format since WP7, and I'll be working blind from templates and policy files here - but it's worth a shot. Mind you, I wouldn't be surprised if the whole process is read-only, or if the responses from Microsoft are signed (although you could try re-signing them, I guess). For what it's worth, creating an entire update from scratch (or even editing one) is unlikely to work; Windows has required a Microsoft signature (not just any trusted signature) on update files for many years now. It's certainly possible that they messed that up, though.
I also kind of want to see if some of the recent ZIP signature validation bypass exploits from Android (where you could create a ZIP file containing multiple files that have the same name, and the original would be used for the signature but the *last* copy of each file would be the one actually unpacked) might be made to work as well. I've got some ideas about that... not sure if it would work for the update format, though.
Please keep researching this!
Click to expand...
Click to collapse
Will do! Here is where it gets interesting...The attached screenshots are of a SOAP request from my phone to the update server (I disabled filtering, so the GUID isn't present) and then it's response for "missing" updates to evaluate.
the section labeled "xml" contains the instructions on how to evaluate if the update is needed.
here is a cleaned up, friendly dump of what is in the "XML" section it needs to parse to determine if an update is applicable:
Code:
<UpdateIdentity UpdateID="f092f820-8161-410b-ab11-c7a6d36b7837" RevisionNumber="101" />
<Properties UpdateType="Software" />
<Relationships>
<Prerequisites>
<UpdateIdentity UpdateID="eb644fbf-5e6e-4719-b97c-485ffb9e867f" />
<AtLeastOne>
<UpdateIdentity UpdateID="450b8808-d056-4c18-a383-2db11e463eb0" />
</AtLeastOne>
</Prerequisites>
</Relationships>
<ApplicabilityRules>
<IsInstalled>
<CspQuery LocUri="./DevDetail/SwV" Comparison="GreaterThanOrEqualTo" Value="9.0.0.0" xmlns="http://schemas.microsoft.com/msus/2002/12/MobileApplicabilityRules" />
</IsInstalled>
<IsSuperseded />
<IsInstallable>
<And xmlns="http://schemas.microsoft.com/msus/2002/12/LogicalApplicabilityRules">
<CspQuery LocUri="./DevDetail/SwV" Comparison="LessThan" Value="9.0.0.0" xmlns="http://schemas.microsoft.com/msus/2002/12/MobileApplicabilityRules" />
<b.RegSz Key="HKEY_LOCAL_MACHINE" Subkey="Software\Microsoft\Windows\CurrentVersion\DeviceUpdate\Agent\Protocol" Value="TestTarget" Comparison="EqualTo" Data="72c5dc6d-00a9-412f-9d13-f4f483f2ed7f" xmlns="http://schemas.microsoft.com/msus/2002/12/BaseApplicabilityRules" />
</And>
</IsInstallable>
</ApplicabilityRules>
an interesting URL with info from someone else that was looking into this for Win7...
http://withinwindows.com/2011/03/06/notes-on-windows-phone-7-update-process-thus-far/
I wonder if we can figure out what "updates" are actually required if we can trick the server into giving us more OOB updates/othercarrier updates/updates we aren't "supposed" to have..
Found some info on the "Evaluate" action:
Action: The action that clients in the specified target group will perform on this revision: Install, Uninstall, PreDeploymentCheck (which means that clients will not offer the update, just report back on the status), Block (which means that the update will not be deployed, and is used to override another deployment), Evaluate (which means that clients will not offer the update and will not report back on the status), or Bundle (which means that clients will not offer the update for install; it is only deployed because it is bundled by some other explicitly deployed update).
Click to expand...
Click to collapse
source:
http://msdn.microsoft.com/en-us/library/cc251980.aspx
I was also messing with fiddler and I noticed my phone access two different places when a phone update is selected. One of the pages is: http://ds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab . In that cab is this file wuredir.xml and consists of:
<?xml version="1.0"?>
<WuRedir xmlns="http://schemas.microsoft.com/msus/2002/12/wuredir" redirectorId="1002">
<Protocol
elementVersion="1"
clientServerUrl="https://fe1.update.microsoft.com/v6/"
reportingServerUrl="http://statsfe1.update.microsoft.com/" />
</WuRedir>
the second page accessed is: http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
I hexed the .dll after download and found some download links to some cert files, which are:
Microsoft Windows Phone Production PCA 2012.crt
http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
MicRooCerAut_2010-06-23.crt
http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
MicTimStaPCA_2010-07-01.crt
http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
can any of this info help us?
If either that DLL or any of those certificates are not signed (highly unlikely, but worth checking), or if the DLL doesn't enforce the signature check (extremely unlikely), or if any of the certs include the private key or use a weak hash algorithm or a short key... maybe. I checked the certs, though; they at least are clean. Nothing useful that I saw.
Reverse engineering the DLL may be useful, but it's probably native code and therefore a pain to decompile.
aclegg2011 said:
I was also messing with fiddler and I noticed my phone access two different places when a phone update is selected. One of the pages is: http://ds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab . In that cab is this file wuredir.xml and consists of:
<?xml version="1.0"?>
<WuRedir xmlns="http://schemas.microsoft.com/msus/2002/12/wuredir" redirectorId="1002">
<Protocol
elementVersion="1"
clientServerUrl="https://fe1.update.microsoft.com/v6/"
reportingServerUrl="http://statsfe1.update.microsoft.com/" />
</WuRedir>
the second page accessed is: http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
I hexed the .dll after download and found some download links to some cert files, which are:
Microsoft Windows Phone Production PCA 2012.crt
http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
MicRooCerAut_2010-06-23.crt
http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
MicTimStaPCA_2010-07-01.crt
http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
can any of this info help us?
Click to expand...
Click to collapse
Those are the first steps in the update process. Basically, it gets the certs that it will use for validation and server communication. then the CAB file contains the info on what servers are used for Windows Update communications. It then logs that a request has been made to the tracking server. After that, it gets a list of updates from the v6 address. If there are no updates, Once the update process is complete, it logs the result to the tracking server.
Do you guys think I could use this to fix the problems I seem to have when trying to stream or download music from Xbox Music? I get a lot of errors, or this song can't be played on your device and some times the app crashes. I have had this problem since I switch from my Windows Phone 7 device to my Nokia Lumia 920, and I am on my 4th 920. I think for some reason the Music store is getting botched certificates or something.
Kind of on the same subject. anyways i extracted around 140 Certificated from a HTC 8x Ruu. then installed them to my pc. Which is windows 7. The cool part was i was able to install windows phone sdk 8 and 8.1 with emulators and visual studio 2013. which i though all of these were not possible to run on windows 7. all because of certificates from a rom.