[DEVS] XZ Premium DRM fix - Let's find a solution together (brainstorming) - Sony Xperia XZ Premium Guides, News, & Discussion

Edit: I DID IT! DRM is fixed...
Here we go: https://forum.xda-developers.com/xz...hack-mod-sony-xperia-xz-premium-twrp-t3695171
Hello forum community,
Hello developer,
Maybe you've read the last few weeks already that I am currently looking for a solution for the limitations after an unlocked bootloader. Previous solutions (DRM recovery by Tobias Waldvogel and others) unfortunately do not work, since various libraries and other system data have changed. Also in the TrustZone there are various changes, which lead to the fact that previous solutions no longer work.
For some time, I'm busy with the Sony system protection. Although I am very experienced in the field of reverse engineering, but unfortunately I have little experience with the procedure with Android systems, especially with Sony.
I would like to take the opportunity in this thread to exchange ideas with other users about the possible solutions. In order to better understand the connections and thus possibly find a gap in the system, it would be good if we share our knowledge about Sony DRM. What files might be patched, what dependencies exist, ...
It would be great if we could work together and maybe get a DRM fix for the XZ Premium.
Cheers!
To the moderators: I hope the thread is okay. If not, please just lightly hit the back of the head. Thank you!

Thanks for creating a thread for this. I have an interesting question. You may have looked a while back at the one thread with a working Google Camera build. Is there any idea as to why it worked? Maybe instead of fixing DRM, we can work around it.

cdnutter said:
Thanks for creating a thread for this. I have an interesting question. You may have looked a while back at the one thread with a working Google Camera build. Is there any idea as to why it worked? Maybe instead of fixing DRM, we can work around it.
Click to expand...
Click to collapse
Yepp, it's my own thread. The working Google camera is just a compensation for unlocked/rooted users. Because after you unlock/root your XZP, the camera doesn't work (green pictures). It's not working with full supported "specials" from Sony. The resolution of the images is smaller, too. The 3rd-party camera apps are using their own image processing and/or the API to the system camera. So with Google camera or other Apps, we can take pictures, but in relatively bad quality because the resolution for 3rd-party apps is locked by Sony. Other apps are using the system camera with a "light mode" of it. So they take pictures without special effects, but with the stock camera, so you have a green pic after your shot.
So... The big problem is: Without hacking/patching/fixing the Sony device security (DRM/TrustZone) we can not use the full features of the camera. I don't understand why Sony is so bad to their customers, because their "special camera algos" are absolutely not interesting to me. But it's really bad to lock down the whole camera (green pictures). If they would only lock their own algos, it would be absolutely okay (because otherwise other vendors could copie them). But Sony... No... That's not the way to hold customers at a company. If I unlock/root my phone, I want to use the hardware like i want to. And if I install my own camera app with own functions, I don't need the Sony algos. The pictures would be nice, too. I think that's the reason why Sony did that on XZP...
My idea a few days ago was that we could try to port other camera to the stock XZP firmware. Something like Snapdragon Camera (used in AndroPlus AICP for XZP). But my knowledge about that is to bad. I did a few things to test something like that, but everything I tried crashed. I think we would need to patch the driver, libraries, cameraserver and other binary to get a full unlocked camera, that works without Sony. I am a freak on Windows systems, web applications and PC software. But on Android I must pass if it goes to "hacks" like these... sorry.
But... okay... let's find a way to "crack" that security (that's my passion on win/web)... anyway.

What I have been asking myself for some time is why Sony should make so many changes to the system on a single device. Other devices that have also been introduced to the market in this vehicle can be patched with the Tobias solution. If, therefore, Sony had made fundamental changes to the security of the devices, then theoretically all new devices would be affected.
I have compared the XZ Premium with the XZ and the XZs. I had to realize that different libraries and applications have changed. And that's the reason why the DRM fix doesn't work in it's form.
The binary file:
/system/bin/secd
The libraries in /system/lib/ :
- libcredential-manager-service.so
- libdevice_security.so
- libsuntory.so
The libraries in /system/lib64/ :
- libcredential-manager-service.so
- libdevice_security.so
- libsuntory.so
These are high relevant files for the device security in relation to Sony DRM. The "secd" uses "libsuntory" and checks if the keys are stored, active and legit.
The main differences I found, were...
- The secd was merged with other binaries. The old size was ~150 KB and in XZ Premium it's ~1130 KB. I think they merged other functions from old libraries to the file, because they did that to other files, too.
- The old secd uses libtee.so and the new one uses libQSEEComAPI.so. And that's the big problem I think.
I will try to patch the relevant files and test if it works. With modified libsuntory I was able zu manipulate the blob status from "generic error" to "blobs not found". So maybe there is a way to fix this.

Hahaha...
Nice job Sony! I patched the whole libsuntory.so to get "all fine here" everywhere (~300 patches in ONE f*** library!). On the half way it's working and I was really happy to be on the right way - I can manipulate the status of CKB. Buuuuuuuuuuut....
If I am right in my thinking, then Sony uses backup tests and checks if there is some "huj huj huj" (you would laugh... that's really literally there in the functions) ongoing on the phone. So there (maybe) are backup tests in the TrustZone and in other system files, too. And the annoying part is, that if the system recognizes manipulations in relation to the security, some things will be dropped in hidden zones. After that the HUK is f*** up and the camera shows the typical "camera is used by another application" error. Funny is: Also the Google camera doesn't work anymore (green pics... hahaha). The only way to fix it, is flashing the system partition. Simply restore the original files doesn't work.
But... okay... That would have been tooooo easy. So let's check some other files, too. It's almost weekend and I think there will be a bit more time for some crazy things like this.
Why are you all so quiet?

Well, I've wanted to reply but didn't wanna clutter the thread since I can't help. Just know that you're amazing for putting your time on this and I love reading what you post.
You can absolutely count on me to donate if that's any motivation .

I'm not a dev so I have nothing useful to add, but I'm keeping my eye on this thread. Great work so far!

Whats required is someone to take lead and to distribute work. Create a list of possible avenues or things to look in to and let folk who have the ability to see whats going on then use that list to support the project.

sToRm// said:
Maybe you've read the last few weeks already that I am currently looking for a solution for the limitations after an unlocked bootloader. Previous solutions (DRM recovery by Tobias Waldvogel and others) unfortunately do not work, since various libraries and other system data have changed.
Click to expand...
Click to collapse
You might want to check the actual more recent one tbh.
You still need a root exploit for TA backup in the first place (and the lesser kernel being 4.4.21, it's not exactly a cakewalk), but still

mirhl said:
You might want to check the actual more recent one tbh.
You still need a root exploit for TA backup in the first place (and the lesser kernel being 4.4.21, it's not exactly a cakewalk), but still
Click to expand...
Click to collapse
My goal is to find a solution for already unlocked/rooted users (like me). A backup of the TA is useless, if the BL was unlocked before. So we have to find a way to simulate the key(s) or to crack the device security and gain uncontrolled access to functions in the TZ. Would be really nice if we could find a way to get temp root on unlocked devices, to dump the TA and get the original keys to mount them later. But there are a lot of users that have already unlocked.

Oh I see what you mean here. A noCD instead of emulating protection.
I hope you'll release as much info as possible ?

sToRm// said:
A backup of the TA is useless, if the BL was unlocked before.
Click to expand...
Click to collapse
Wait, why useless? All pre xzp devices was able to restore device to the lock state the same one like it was never unlocked. But xzp have that thing diferent?

munjeni said:
Wait, why useless? All pre xzp devices was able to restore device to the lock state the same one like it was never unlocked. But xzp have that thing diferent?
Click to expand...
Click to collapse
He said, if the bootloader has been unlocked already there's no point in backing up TA as the keys are already gone.

FartyParty said:
He said, if the bootloader has been unlocked already there's no point in backing up TA as the keys are already gone.
Click to expand...
Click to collapse
Yeeeeepp... So, why should I backup the TA and mount it if the key is already gone? If the key would be stored on a place somewhere and unlocking the bootloader would only effect that this place is inaccessable, then a relock, export and mount of the TA would be interesting for already rooted users. But if there is no key in the backed TA, mount it is useless. That's what I mean. I want to find a way to get the device thinking there is a valid key in the TA. Maybe it's possible with patching some system files.
@all
Is there somebody with a locked XZ Premium?
I would need a /system/build.prop file from an untouched phone. with working keys.
A friend wants to buy the XZP, too. Maybe I can get her phone to do some research on a unlocked system. I only have to persuade her :laugh:

This is from G8141_Customized CE1_1308-5321_45.0.A.1.229_R6A -> https://pastebin.com/J2qCCmpM I don't think there is something changed in case lock <-> unlock because of the dmverity!

The device key is used to decrypt credentials for various Sony apps. On older Sony phones (e.g. Z3C), there is over 200 credentials. While the device key is device specific, these credentials are not. The drm fix works by hardcoding these credentials and hooking the function to return them when they are requested. The original function would fail to get the credentials because the device key is missing.
Maybe Sony changed these credentials / added additional ones and that's why the drm fix is not working anymore.

Hi, I have a locked, untouched phone, happy to help, can I get the build.prop file?

https://drive.google.com/uc?id=0BzEmiGcuf7IiRnVURVoxaFQyaUk&export=download
This one is from an unlocked G8141 running 45.0.A.7.120 (in the case, there might be any differences to munjeni's version).

The reason why I asked for the build.prop is, that there are some properties which are checked in the secd. When I change them, the FIDO_KEY and ATTEST_KEY change from "Not provisioned" to "Provisioned" in the service menu.
Changed:
Code:
# FIDO key provision state and version
persist.keyprovd.fido.prov=false
persist.keyprovd.fido.version=0
# Attestation Key provision state and version
persist.keyprovd.attest.prov=false
persist.keyprovd.attest.version=0
# Suntory BLOBs have been processing state
persist.keyprovd.suntory.prov=false
to:
Code:
# FIDO key provision state and version
persist.keyprovd.fido.prov=1
persist.keyprovd.fido.version=0
# Attestation Key provision state and version
persist.keyprovd.attest.prov=1
persist.keyprovd.attest.version=0
# Suntory BLOBs have been processing state
persist.keyprovd.suntory.prov=1
Strange...

Hook the send function in credmgr and log the calls which have the first int of the buffer as 1. That's how the cred request worked in earlier versions. Would be interesting to see what's sent back.

Related

[Q] Deactivate the Camera

Hi all,
Firstly, apologies if this has been covered before, I have had a search but not been able to find an answer yet.
Is there a way to temporarily disable the camera (photo + video) function of the Wildfire? The reason being that I am going to be temporarily working in an area where cameras are banned. I am trying to find an alternative to having the camera drilled at the security entrance.
Does anyone know if it is possible?
Cheers,
I dont think there is. Besides, its pointless if you look at it. You show the security the disabled camera, enter the premises, and activate it again. Ofcourse, this is if the security believes that the camera is disabled, which they wont.
However, I think you can root the phone, take a nandroid backup, and, enter /system and mess around with the camera files (camera.apk), due to which even if you start the camera app, it wont start. However, the question remains whether the security will accept this or not. (Because even they would know a software hack is undoable)
IMV, it would probably be better to get a cheap phone for work, if only phone calls and SMS'es are your need at work.
3xeno said:
I dont think there is. Besides, its pointless if you look at it. You show the security the disabled camera, enter the premises, and activate it again. Ofcourse, this is if the security believes that the camera is disabled, which they wont.
However, I think you can root the phone, take a nandroid backup, and, enter /system and mess around with the camera files (camera.apk), due to which even if you start the camera app, it wont start. However, the question remains whether the security will accept this or not. (Because even they would know a software hack is undoable)
IMV, it would probably be better to get a cheap phone for work, if only phone calls and SMS'es are your need at work.
Click to expand...
Click to collapse
Thanks for the advice.
Let me add, this isn't the only line of defence in satisfying the security people, but I would rather keep the discussion the the software part rather than the ins and outs of the policy and if it would satisfy. It is antiquated and largely pointless policy for the modern world. If someone wants to use a camera as a tool for espionage, there are much better & subtler things than using a smart-phone camera.
From reading round various internet forums, this question always seems to generate more discussion on the policy than the actual deactivation.
alongwor said:
It is antiquated and largely pointless policy for the modern world. If someone wants to use a camera as a tool for espionage, there are much better & subtler things than using a smart-phone camera.
From reading round various internet forums, this question always seems to generate more discussion on the policy than the actual deactivation.
Click to expand...
Click to collapse
True. Anyhow, not much you can do here, unfortunately. (Both in terms of policy and temp disabling the cam)
Sent from my HTC Wildfire using XDA App
Sort of gutting the phone (dont you will be responsible and will probibly brick the phone) you would be better off getting a cheap dumbphone
Sent from my GT-P1000 using XDA App

[FAQ]FingerPrint Scanner SDK for Apps

The Fingerprint Scanner SDK (originally posted at http://forum.xda-developers.com/showthread.php?t=1202577) for Android has been released by Authentec. Currently there is only one device(Motorola Atrix) with a fingerprint scanner, but if you release your application with support for the fingerprint scanner (once you get the hang of it it is really not hard to use at all) then users of phones with fingerprint scanners will most likely be happier with your application.
Google has stated that Google Wallet will use fingerprints to unlock the payment system, so clearly more capable devices are on the way (source: http://www.qrcodepress.com/google-unveils-safety-measure-for-their-upcoming-mobile-wallet/853399/). Including fingerprint scanner capability in your application will also future-proof it as AuthenTec will have the same framework in place in other phones that will use their fingerprint scanner (Authentec is a leader in biometric security systems for lots of devices).
MotoDEV Article Guide:
http://developer.motorola.com/docstools/library/writing-fingerprint-enabled-apps
Read and Download the (simple) SDK at their site:
http://developers.authentec.com/
Example of SDK Usage (pulled from the SDK)​At the time of this writing, it is my understanding that before you release the application you need to have them review it to meet their security specifications... They don't want you using this fingerprint scanner library and making their work look bad. It's a fair deal to me. I'm not sure if this is how they want it though - maybe that is just for Advanced SDK or maybe I'm just wrong (taken from their site) It appears right now that there is a mismatch between the developers and the makers of the authentec site... apparently there is no requirement for using the fingerprint scanner, so develop away!
I have an Atrix and the fingerprint scanner is amazing, once you use it you will never go back to patterns or pins. As such this guide was written by a user of the Atrix - future devices might not use the exact methodology but it should be nearly identical.
I have the Advanced SDK but I have not used any of the advanced functions yet. After using the code (And getting it to finally work) I have found some things that are not documented or are documented incorrectly in the SDK docs and I have come here to post items that will save you great time. If you find others I hope to hear about them so I can add it to the list - I'll even credit you (maybe with a post number so you can score some thanks points!)
The swipe fingerprint screen won't show up - but I'm getting a result (mine was always 14)
AM2 (Authentec fingerprint framework - there are a lot of unsubscribed terms in the documentation so just go with me here) requires Internet Permission (perhaps to verify the key for the advanced SDK, it might not be done locally - without a key advanced SDK functions will not load). If you don't, all uses of the tsm.jar will not work. Not listed at all in documentation
AM2ClientLibraryLoaded() doesn't work with the code they provide!?
You must Instantiate Authentec.AM2ClientLibraryLoaded() - SDK Docs shows as static but it is not used in the example program they give.
It goes into verification but does not show anything and locks up the fingerprint sensor.
Do not change the 'screen' in the examples of sScreen... I thought that was the title of the window that would appear, but apparently those strings are built into it... it would work better as static fields passed as integers. For values look at the next answer.
What can I use for sScreen (viaGfxScreen(string))?
The documentation says nothing of this but these are different types of verification screens. There is fingerprint scanning only and then there is the unlock style one where you also get the PIN. I'm guessing a modifed version of this is how the lock screen works.
"lap-verify" is fingerprint and PIN
"get-app-secret" is fingerprint only - hit and miss right now... will update when I get it perfected
Why does it lock up?
Only 1 app at a time can access the fingerprint scanner. Motoblur seems to access it occasionally and I think that's why it died on the Atrix's Froyo 1.8.3. It seems mostly fixed but as you develop you will most likely lock it up as you debug. Having a wrong sScreen variable will kill your FP scanner. If it locks in your app you will lose the ability to unlock the device with the FP scanner.
Use DDMS to kill com.authentec.TrueSuiteMobile and the lock will work again. This might work on 1.8.3 but I'm not sure it works that way. If the application exits with the home button, it seems to also lock it up. I'm looking into a way to avoid this..
I can't register my application, it's failing with code 6 - (System Error)
I encountered this one myself when using my Api key for com.mgamerzproductions.gibbertalk - I changed it to com.mgamerzproductions.gibbertalk.testing and it no longer worked. They did tell me this in the email that it is only for one package - so make sure you choose wisely, or bribe the people giving out the API keys to give you another one. I wish it was more specific (API_KEY_NOT_AUTHENTIC or something)
I'm still having problems. What can I do?
You can use these tags for debugging in logcat:
AMJNI (AuthenTec Mobile - permissions - server)
TrueMobileSuite (some gfx log info - swipe fingerprint screen)
AndroidRuntime (will tell you crash related things, as debugging for errors will produce too much to read at once)
Any other things would be greatly appreciated for all of use Developers so speak up if you have something I don't have listed and I'll add it.
If you want to use the encrypted storage provided by the framework you'll need to apply for the Advanced SDK. You have to give them a description of your app, and it has to be security related (obviously that's the whole point of the fingerprint scanner and they don't want you to abuse it).
If you like the guide, and you are on MotoDev, I wouldn't mind a kudos in the contest http://community.developer.motorola...print-Enabled-Apps-quot-article-in/td-p/17206
RESERVED
Reserved for OP at a later date
Pictures of my use right now (more later)
Spoke to OP, moved to main Android development, as this would be of more interest to the development community in general, as I'm sure other phones will be using fingerprint scanning (and this sdk) in the near future.
Originally posted in the source thread:
heilpern said:
I tried to post in the linked thread, but as I'm a new XDA poster the system wouldn't allow me to.
The INTERNET permission is required, however there aren't any connections made off of the device. The system uses sockets internally and INET sockets are used rather than UNIX sockets.
> Why does it lock up?
> Only 1 app at a time can access the fingerprint scanner.
This should not cause the system to lock up; it should cause your app to delay briefly and either continue with your request or return to you with an error. If you can duplicate some other result reliably, please share details.
> If someone also can upload and create an eclipse project it would be must easier to import and view their source code they post. I tried but eventually gave up cause of so many problems.
The eclipse projects for these examples are very simple -- with the exception of the .project you have everything you need in the example directories. Worst case is you can create a new Android project and replace its manifest, sources and resources with those provided by the examples. Then point the build path at your tsm.jar and you'll be ready to go.
Click to expand...
Click to collapse
What I meant was that if an app is asking for the fingerprint reader (not the app entirely, but actively asking for the FP reader scan), and motorola does something in the background with the FP scanner (on atrix), it can lock it up. This was heavily apparent on Atrix 1.8.3 but in the new update it seems to have been mostly fixed.
Errors: If you bring up the window with anything but lap-verify or get-app-secret, the window will lock up (and i think fingerprint reader will lock up as well - if you return to the lockscreen you'll see it never finishes initializing it) I can attempt to reproduce this error but I want to finish some development I am doing now.
heilpern said:
com.authentec.TrueSuiteMobile drives the UI, directly or indirectly depending on exactly what's going on (indirectly in the case of the lock screen, for example). If this package is killed it will restart with the next fingerprint operation however it will disrupt any currently active verification attempt (causing the requesting app to receive an error -- probably the USER_CANCELED error).
Click to expand...
Click to collapse
I never really kill it except if it locks up. Haven't tested what it returns (perhaps null)
heilpern said:
Here's something you can do to experiment if you're using StoreCredential -- swipe one of your existing fingers (the index fingers) and you'll store data to that particular finger. Swipe a different finger (multiple times as prompted) and eventually (after three swipes if all goes well) you'll be asked which finger you just enrolled (and your credential will be stored to that finger). This new finger can be used for subsequent Store Credential requests (without the automatic training session) and to release data stored with Get Secret... but only the index fingers can be used to unlock the Atrix.
Click to expand...
Click to collapse
Yeah, in the original thread I had that image posted... It's in the framework but it never was used... I'm not sure if it was there for this purpose or was just cancelled at the end because it was incredibly confusing... I don't get why you would need all those credentials. It's not like your phone will get passed around that much. You swipe new fingers just like you would if you were registering a finger, then you choose the finger... but the accuracy of the 'pick a finger' one is pretty bad.
Would love to see a test apk where we can try this out...
Nothing available right now?
My application works with the FP scanner... its not done yet though.
These are the included APK's that are the code samples they use:
Download tsm-apk-pack.zip from Host-A
Will it support HTC Desire HD? It won't right?
The fingerprint scanner is a hardware device, just like a laptop fingerprint reader. Its not touchscreen, unfortunately.
Trolling from my ATRIX 4G on probably the crappiest main US carrier
Mgamerz said:
I can't register my application, it's failing with code 6 - (System Error)
I encountered this one myself when using my Api key for com.mgamerzproductions.gibbertalk - I changed it to com.mgamerzproductions.gibbertalk.testing and it no longer worked. They did tell me this in the email that it is only for one package - so make sure you choose wisely, or bribe the people giving out the API keys to give you another one. I wish it was more specific (API_KEY_NOT_AUTHENTIC or something)
Click to expand...
Click to collapse
I agree that a more telling error code would be a better option. Error 6 is eAM_STATUS_ACCESS_ERROR but that value can be returned for other problems as well.
Note that if a generic API key is needed, TSM-0E08085A-1210171A-001A7465-632E7473 can be used if you name your package com.authentec.tsmgetsecret. You cannot post that package to the Market however if you want a means of creating a test APK with a neutral package name that package/key combination will work.
Has AuthenTec claimed that package name on the market...?
they probably should or someone might take that package...
Mgamerz said:
Has AuthenTec claimed that package name on the market...?
they probably should or someone might take that package...
Click to expand...
Click to collapse
Yes, it's already claimed in an unpublished but uploaded entry.
Hi . question: is it possible to use fingerprint senzor as wake up function? My button is very very hard to push, this function would be great....

[XAP][GUIDE] Interop Unlock for WP8 + all Capabilities

It took us much longer than WP7 did, but the first Interop Unlock hack for WP8 is now available. It's currently limited to SAMSUNG phones, although we're trying to extend it to other phones, of course.
WARNING: Samsung is trying to break this hack! If you take the retail upgrade to GDR3 including the Samsung firmware update, it will not work!
A brief summary, for those unfamiliar with interop-lock: Windows Phone allows a number of high-privilege app capabilities, which can be used to make changes to the OS which are normally not possible for a third-party app. The limitation on whether we can use these capabilities or not is based on what "level" of developer unlock the phone has; standard "ISV" (Independent Software Vendor) dev unlock (max 10 apps or less) is what pretty much everybody gets; OEMs, however, get a special OEM Developer Unlock (300 apps or more) which gives them the ability to use much higher-privilege app capabilities than the standard ISV unlock permits. The name comes from ID_CAP_INTEROPSERVICES, the capability which was most important in WP7. In WP8, however, there are a great many interesting capabilities. Note that Interop-unlock by itself does not enable all of these. However, at least on Samsung phones, it is now possible to enable *all* the capabilities.
Guide for Samsung's ATIV phones:
The instructions are generally well-provided in @-W_O_L_F- 's app (direct link for updated XAP). You will also need the Diagnosis app, which is included (though hidden) on every Samsung WIndows phone.
The instructions are as follows:
Developer-unlock your phone. You will need the Windows Phone Developer Registration tool for this; it comes with the SDK.
Sideload the helper app using Application Deployment (included with SDK) or WPPT. It does not work to just copy the file to your phone, or similar.
Open the Phone dialer (the built-in one) and dial ##634# to install the Diagnosis app (if you hadn't already). You can exit it afterward.
Run the Interop Unlock Helper app and read the instructions, clicking Next until you get to Step 2.
Click the button to generate the toast notification for your phone's Diagnosis app, then tap on the toast to open the hidden registry editor.
Press-and-hold the Back button, and switch back to the helper app without closing the registry editor. Click Next to go to Step 3 in the helper app.
Copy the provided registry paths and values out of the helper app, use the Back-and-hold switcher to return to Diagnosis, paste the values into the registry editor, and write them.
Don't worry if the app says a write failed! Just hit Read afterward to verify the change.
Repeat the previous steps a few times, hitting Next after each set of instructions, until the Helper app says "Finish".
Once all the registry values are written, congratulations; you are interop-unlocked!
At this point, you probably want to run the EnableAllSideloading hack below.
If you want to enable sideloading even more high-privileged apps, you'll want the following:
Install the BootstrapSamsung app attached to this post. This requires having interop-unlock already, and will not work if you have Samsung's ships-with-GDR3 firmware update unless you unblock RPC.
Run the app once, and ensure it displays a success message. You may then exit and (optionally) remove the app.
Install the EnableAllSideloading app attached to this post. This requires the bootstrap step. However, it is not specific to Samsung (we just can't bootstrap anything else yet).
Run EnableAllSideloading once, and ensure it displays a success message. You may then exit and (optionally) remove the app.
At this point, you will be able to sideload any capability, even the ones used for built-in apps and services. However, there appear to still be restrictions, even with a capability such as ID_CAP_BUILTIN_TCB. Multiple XDA members, including @Heathcliff74 and myself, are working to overcome these restrictions.
It may be necessary to repeat these steps after a phone update.
Capabilities which will be enabled, without further modification, by using interop-unlock:
Note: This list is *just* the ones from Interop-unlock; it does not unclude the ones from EnableAllSideloading.
ID_CAP_CALLMESSAGING_FILTER
ID_CAP_CAMERA
ID_CAP_CELL_API_COMMON
ID_CAP_CELL_API_LOCATION
ID_CAP_CELL_API_OEM_PASSTHROUGH
ID_CAP_CELL_API_UICC
ID_CAP_CELL_API_UICC_LOWLEVEL
ID_CAP_CELL_WNF
ID_CAP_CSP_FOUNDATION
ID_CAP_CSP_MAIL
ID_CAP_CSP_OEM
ID_CAP_CSP_W4_APPLICATION
ID_CAP_CSP_WIFI_HOTSPOT
ID_CAP_DEVICE_MANAGEMENT
ID_CAP_DEVICE_MANAGEMENT_ADMIN
ID_CAP_DEVICE_MANAGEMENT_BOOTSTRAP
ID_CAP_DEVICE_MANAGEMENT_SECURITY_POLICIES
ID_CAP_DU_MIGRATOR_STATUS_OEM
ID_CAP_OEM_DEPLOYMENT
ID_CAP_INTERNET_EXPLORER_FAVORITES
ID_CAP_INTERNET_EXPLORER_SEARCH_PROVIDER_KEYS_HKCU
ID_CAP_INTEROPSERVICES
ID_CAP_KIDZONE_CUSTOMIZATION
ID_CAP_MAP_WRITE
ID_CAP_MEDIALIB_PHOTO_FULL
ID_CAP_NETWORKING_ADMIN
ID_CAP_OEM_ADC
ID_CAP_OEMPUBLICDIRECTORY
ID_CAP_PEOPLE_EXTENSION
ID_CAP_PEOPLE_EXTENSION_IM
ID_CAP_PEOPLE_EXTENSION_MOBILE
ID_CAP_PERSONAL_INFORMATION_IMPORT
ID_CAP_RUNTIME_CONFIG
ID_CAP_SMS_INTERCEPT_AGENT
ID_CAP_SMS_INTERCEPT_RECIPIENT
ID_CAP_SYNC_EXTENSION
ID_CAP_VOICEMAIL
ID_CAP_WALLET_SECUREELEMENT
ID_CAP_WIFI_BASIC
One of the goals of this thread will be to explore what we can do with interop-unlock, and look for ways to achieve full permissions. I think I've found one, but it requires the ability to write registry multi-string values. Basically, if we could add a "superuser" privilege, or enable the use of ID_CAP_BUILTIN_TCB, which already has it, this would allow the creation of "root" apps.
Aside from myself, credit for this hack goes to @cpuguy for the Native Toast Launcher tool which permits accessing otherwise-unreachable code, and @-W_O_L_F- for helping put the pieces together. I'm not actually certain which one of us achieved the interop-unlock first; we were both working on it. @Heathcliff74 continues to be a help on the quest for full-unlock.
The source code for the apps below is posted at http://forum.xda-developers.com/showpost.php?p=45606584&postcount=88
Questions and Answers
Can I install WP7 interop apps using this?
They will install, but there's no point. They almost certainly won't actually work. Interop-unlock enables access to parts of the OS which third-party developers were not intended to touch; consequently, there's no backward compatibility. Even the methods used for native code on WP7 (which is different from, but nearly essential to make use of, interop-unlock) won't work on WP8. However, it should be possible to port many of those applications to WP8.
Will this work on Lumia phones / How can I get this on my Lumia / Are you working on this for Lumia phones / What about HTC, or some other OEM?
The current hack relies on a Samsung-specific component. Adding support for other phones will require new hacks. We are looking into it, rest assured; at this time, however, there is no way to gain interop-unlock on any WP8 device other than a Samsung one.
EDIT: It looks like there should soon be a Huawei W1 custom ROM with interop-unlock included. I don't deal with custom ROMs, but you may be able to use homebrew apps on that phone too.
EDIT: Lumia phones *can* be interop-unlocked via JTAG. However, this requires some extra hardware and some phone disassembly. Not an online hack, and not for the faint of heart.
But what if we installed the Diagnosis app on a Lumia phone (using Fiddler proxy or similar) and then followed this guide?
I repeat, Samsung-specific component. Nokia doesn't put the required services/drivers for Samsung's Diagnosis app into their Lumia firmware, so the app would not work!
Can I upgrade my phone to GDR3 if I have this?
Yes. However, be aware: if you install Samsung's updates that come with the retail GDR3 update, it will break your ability to re-unlock, or to use some homebrew apps! (Developer preview updates are fine, as those are purely Microsoft code and don't mess with the Samsung components.)
EDIT: There's a way to unlock the Samsung services for full access again on GDR3. You still need to interop-unlock beforehand, though.
Can I re-lock my phone if I want to?
Yes, easily. The simplest method is to use the Windows Phone Developer Registration tool (the one that comes with the SDK) to de-register the phone (you can then re-register it if you want to get your normal dev-unlock back). This doesn't remove any changes that were made using the interop-unlock, though (for example, it won't undo the EnableAllSideloading hack, not will it set back the Full FS Access hack). Apps that require interop-unlock will still be installed, but may no longer run. To manually remove interop-unlock, you can reset all the registry values that were changed by the interop-unlock hack to their original values, and remove all the apps. There still may be a great many other changes that also need reverting, though, if you want to get back to stock settings. See next question.
Can I get my phone completely back to stock settings without knowing every little thing I changed?
Yes, a hard (factory) reset will undo all changes made by interop-unlock, or any apps (including ones that require interop-unlock), and will remove all apps. If you need to send your phone in for warranty servicing and are worried that they won't take it because you interop-unlocked it, this approach will fix that (they would probably tell you to hard-reset anyhow, if it's conceivably a software problem).
Will the interop-unlock survive a hard reset?
Not using this method! Read the question above. This unlock is purely in software, not firmware; it is reset along with everything else.
Can I upgrade my phone to WP8.1 if I have this?
Tentatively, yes! We're still working on figuring out exactly what WP8.1 means for the homebrew scene. The short version is that most apps and some (but not all) of the hacks they contain seem to still work, though. However, see next question...
Can I interop-unlock my phone on WP8.1?
At this time, I don't believe this is possible (unless you can use a custom ROM). One step of the process appears to have been "fixed" and we will need to find a different way. -W_O_L_F- has indicated that he has one, possibly coming soon...
Apps which use Interop Unlock
SamWP8 Tools Currently includes a basic registry editor and some tweaking tools, including an accent color editor.
Native Access Webserver that requires full capability unlock; still read-only at this time.
PDF to Office enables browsing and moving files.
WPH Tweaks allows easy access to a number of registry tweaks.
AppData Manager allows you to back up the data of an app so you can re-install it (possibly after a hard reset) and not lose its state.
Storage Cleanup allows you to list and delete space-wasting files on your phone.
Reserved for... whatever else is needed.
Awesome!
I suggest first app to the list: my SamWP8 Tools
Upd. I'm little bit late XD
well i ve got an ascend w1 bootloader unlocked if i can help let me know
It's awesome to have my phone Interop Unlocked. I hope to see something to clear my "Other Storage" soon. Its full with faulty Windows Store installation files.. But I guess even with this it will be a lost cause.
Sent from my GT-I8750 using Tapatalk
although the Samsung registry editor will install it will not run on my phone and I believe I was able to interop unlock any idea why it wont run?
@GoodDayToDie your wor is awesome and you are the man
Good luck buddy
@FricoRico: Actually, I'm pretty sure we can clear out those files. I've got a ton of stuff on my plate at the moment, but even if none of the capabilities that work with interop-unlock will natively allow access to the relevant folder (and I wouldn't be surprised if one does; what is the folder in question?) there's a function in the Samsung driver interface to move files; we can move them to a location where we have write access, and then delete them.
@noelito: No idea. If it installs, that means you're unlocked. Make sure your phone didn't re-lock, I guess - try deploying the app again, for example - and make sure you're using the official deployment tool (some of the unofficial ones for WP7 - which may or may not work on WP8 - strip interop capabilities) and then try again. If it still doesn't work, please give a more detailed error report.
I am using the official deployment tool, and I believe the interop unlock does work because I was able to side load operamini, Samsung photo studio, supreme shortcuts and couldn't before BUT that was it they're side loaded but do not work at all ? well actually supreme shortcuts does run but when I try to use a custom shortcut such as brightness it will crash
Sent from my SGH-T899M using XDA Windows Phone 7 App
Aha, an item for the FAQ...
WP7 INTEROP APPS WILL NOT WORK! Interop-unlock lets you develop high-privilege apps, but it's very OS-specific. This is all unofficial stuff; there's no reason for Microsoft to have maintained backward compatibility, and indeed they did not. New apps will need to be developed specific to WP8. That's why there isn't already a bunch of listed apps...
ohhh ok so this interop unlock
is paving the way for future wp8 homebrew apps?
Exactly. Things which I have in mind, beyond the obvious improvements to registry and file system browsing, include options such as sounds customizations, media library access, changing certain "restricted" file/URI associations (alter the default browser?), *possibly* better task management (not sure we have the permissions for that), cleaning up wasted storage space, and as much more as we can manage. There's also a lot of potential for future research which this enables: interop-unlocking more devices, getting even higher permissions, possibly even custom ROMs or at least custom kernel drivers (which is much the same, since once you've got that you can change anything).
Can you write anywhere on the file system?
I can write some places, certainly. We'll see. I've got a couple of ideas for exploits involving writing to System32, but if there's anywhere I *can't* write, it's probably there.
Maybe "test mode" from lumias work like diagnosis app from samsung, really don't know about WP8 because i went from android, but on my motorola some options in fastboot like "Factory Mode" are apk's. Maybe this is a dumb thing (because they are two diferent systems ) :silly: .
Really thank you for your work, u 're awesome.
Sry for my english
GoodDayToDie said:
I can write some places, certainly. We'll see. I've got a couple of ideas for exploits involving writing to System32, but if there's anywhere I *can't* write, it's probably there.
Click to expand...
Click to collapse
Might be able to port @Myriachan 's exploit.
Boss442 said:
Maybe "test mode" from lumias work like diagnosis app from samsung, really don't know about WP8 because i went from android, but on my motorola some options in fastboot like "Factory Mode" are apk's. Maybe this is a dumb thing (because they are two diferent systems ) :silly: .
Really thank you for your work, u 're awesome.
Sry for my english
Click to expand...
Click to collapse
Feature-wise, Test mode is heavily locked on Lumias. One has to authorize to use its the most sweet features.

For Those That Have Not Unlocked Their Bootloaders (XT926)...

...wouldn't this be an option (people more in the know, please correct me if I am wrong):
- Use one of the utilities to revert your system back down to ICS (4.0.4)
- Unlock the bootloader / root / do whatever you want to do that you can't when on the latest software...
- Re-take all of the updates to get you back up to 4.1.2 (or use the utility to get back to 4.1.2)
Easy-peasy, pending the updates that block the unlock exploit are reverted as well when the software is reverted.
I do understand that one would lose all their precious info (contacts, pics, vids, apps, etc.), but making a hard copy list of that stuff (or a backup of some sort - Backup Assistant Plus, DropBox, and Titanium Backup to Cloud storage come to mind) may be worth it to get the bootloader unlocked. To save pics, vids, etc. one could also just drop all of that stuff on to their computer before reverting as well.
Just thinking of a way to help those that cannot unlock but want to... maybe it'll help rid the forum of the "new unlock method needed please" threads as well
From what i've gathered, downgrading the phone from current firmware will not undo their patch that blocks unlocking/rooting.
LifeAsADroid said:
...wouldn't this be an option (people more in the know, please correct me if I am wrong):
- Use one of the utilities to revert your system back down to ICS (4.0.4)
- Unlock the bootloader / root / do whatever you want to do that you can't when on the latest software...
- Re-take all of the updates to get you back up to 4.1.2 (or use the utility to get back to 4.1.2)
Easy-peasy, pending the updates that block the unlock exploit are reverted as well when the software is reverted.
I do understand that one would lose all their precious info (contacts, pics, vids, apps, etc.), but making a hard copy list of that stuff (or a backup of some sort - Backup Assistant Plus, DropBox, and Titanium Backup to Cloud storage come to mind) may be worth it to get the bootloader unlocked. To save pics, vids, etc. one could also just drop all of that stuff on to their computer before reverting as well.
Just thinking of a way to help those that cannot unlock but want to... maybe it'll help rid the forum of the "new unlock method needed please" threads as well
Click to expand...
Click to collapse
along with the many "new unlock method needed please" post, there are many post just like yours, to which in every case we "in the know" state "cant be done/will not work"
as previously stated, the files that need to be modified to unlock can not be reverted.
Yeah, like Bwen said, it's not going to happen. The ability to downgrade was locked up on the update that also patched the unlock. Many have tried, many have failed, and a few have bricked.
1) I apologize if it came off as offensive about the stopping all the "new unlock method needed please" posts. It wasn't meant to be. Was simply thinking that new posts like that wouldn't develop, and the older ones would naturally die off, thus letting us all happily and jointly move on to newer topics or issues and solve them when they arrive. I have seen lotsa posts from people needing a new method to unlock, I haven't seen any along the thought process of trying the method I (apparently unoriginally) suggested.
2) Of course I did not expect this to be a new idea, but hadn't seen it posted so I thought I'd give it a whirl and perhaps help others out if it hadn't been thought of... A shot in the dark of an idea.
3) To receiving the knowledge that it cannot be done this way - ah nuts. Oh well, tried to help.
4) I'm glad I went and did the unlock when I did, prior to the corrective action taken by Motorola.
5) Anyone know what caused Motorola to make the fix? Since the XT925 is able to be unlocked, I'm thinking they don't personally care whether people unlock or not... I'm guessing that VeeZeeDub may have forced their hand to make the correction since VeeZeeDub doesn't want the phones unlocked? (disclaimer: I apologize up front if this is not a new topic)
I would blame it on VZW, more than anything else. Moto is somewhat trying to push towards being more dev friendly, but VZW is far from it.
I agree that it must be Verizon. Sorry for the duplicated thanks in the post above.
Sent from my RAZR Maxx HD
Jhall8 said:
I agree that it must be Verizon. Sorry for the duplicated thanks in the post above.
Sent from my RAZR Maxx HD
Click to expand...
Click to collapse
No worries man. I know I can be abrasive and it only gets amplified through the internet, and I apologize if my post came off that way.
LifeAsADroid said:
1) I apologize if it came off as offensive about the stopping all the "new unlock method needed please" posts. It wasn't meant to be. Was simply thinking that new posts like that wouldn't develop, and the older ones would naturally die off, thus letting us all happily and jointly move on to newer topics or issues and solve them when they arrive. I have seen lotsa posts from people needing a new method to unlock, I haven't seen any along the thought process of trying the method I (apparently unoriginally) suggested.
2) Of course I did not expect this to be a new idea, but hadn't seen it posted so I thought I'd give it a whirl and perhaps help others out if it hadn't been thought of... A shot in the dark of an idea.
3) To receiving the knowledge that it cannot be done this way - ah nuts. Oh well, tried to help.
4) I'm glad I went and did the unlock when I did, prior to the corrective action taken by Motorola.
5) Anyone know what caused Motorola to make the fix? Since the XT925 is able to be unlocked, I'm thinking they don't personally care whether people unlock or not... I'm guessing that VeeZeeDub may have forced their hand to make the correction since VeeZeeDub doesn't want the phones unlocked? (disclaimer: I apologize up front if this is not a new topic)
Click to expand...
Click to collapse
it really doesn't matter that this was posted again, you could post it 10 more times and i guarantee within a couple days someone will ask again.
the problem is, there is an ever increasing group of people who want answers spoon fed to them because they are too lazy to read for 5 minutes to find it them self. that may sound harsh, but if you have been around the forums for at least a few years helping people its easy to see it progressing.
i have provided help on various forums through the past few years and the majority of the time when i dont have an answer, i throw some key words into a search engine and come up with the answer within minutes.
its not that im much more knowledgeable than most, its that i would rather read a few minutes and learn how to do something rather than have someone feed it to me. thats why you very rarely see me ask any questions or ask for help. 99% of the answers are out there some where, all you have to do is look...
:semi rant concluded: just my opinion, take it as you will...
I know that we can't load prior software as it won't over write the exploit fix but, here's what I don't understand. When a phone gets sent back for repair, I would think there's a way that they wipe the phone out completely removing any trace of it's previous owner. Including the traces of a new update, boot loader...etc. Then install a completely fresh copy.
Why can't that technique been done to reinstall the previous software that allows boot loader unlocking? Wouldn't a cell phone repair shop have this capability? If you put a new board in the phone, can it be flashed with any software?
Or even in the refurbish process, not everything gets wiped?
bear263 said:
I know that we can't load prior software as it won't over write the exploit fix but, here's what I don't understand. When a phone gets sent back for repair, I would think there's a way that they wipe the phone out completely removing any trace of it's previous owner. Including the traces of a new update, boot loader...etc. Then install a completely fresh copy.
Why can't that technique been done to reinstall the previous software that allows boot loader unlocking? Wouldn't a cell phone repair shop have this capability? If you put a new board in the phone, can it be flashed with any software?
Or even in the refurbish process, not everything gets wiped?
Click to expand...
Click to collapse
I'm sure moto or verizon can do it, but they have access to the software that contains the encrypted key that is necessary.
But, in any event, they probably would just update it to the latest software if that hasn't happened already.
I got lucky. When I had to replace my RAZR MAXX, they "upgraded" me (for free) to a RAZR MAXX HD. I was lucky enough to have it come in with the 9.16 version, which meant I was able to unlock it, which I did immediately.
The main thing to understand is, if you don't unlock at the 9.14/9.16 version BEFORE applying any other updates, there is NO way to unlock the bootloader. It was an exploit that wasn't meant to be there. Said exploit has now been patched, and if you didn't take advantage of it when it was there, then you have no one to blame, not even Verizon or Moto since it was a security issue that they didn't know existed.

FYI: KEYone susceptible to Janus vulnerability - rooting possible?

Using the Janus vulnerability, you can swap out the classes.dex from apps without tripping the Android security features. This works up until the November patch versions on the KEYone.
You can use this to swap the classes.dex of system apps, e.g. the Updater, and make it do whatever you want (with system rights). Just decompile the Updater APK, make your modifications, compile it back and attach the modified classes.dex to the original APK (downloaded from your device). Then "update" the app via adb / pm.
Any progress?
Actually this sounds not that bad, this would be a "key feature" when buying an Android phone, no root is an absolute no-go for me.
On the other hand I really would like to get hands on a KeyOne, not as "daily driver" (I still love my Q10 and I have a second as backup), but in addition. Why I want to have "root"? Just simply to be able to make full, local backups from the phone and because I want to decide, which software is running or even installed on my device!
BTW: Are there older and current ROMs for the KeyOne to be downloaded somewhere?
Thanks a lot, regards,
thgxda said:
Actually this sounds not that bad, this would be a "key feature" when buying an Android phone, no root is an absolute no-go for me.
On the other hand I really would like to get hands on a KeyOne, not as "daily driver" (I still love my Q10 and I have a second as backup), but in addition. Why I want to have "root"? Just simply to be able to make full, local backups from the phone and because I want to decide, which software is running or even installed on my device!
BTW: Are there older and current ROMs for the KeyOne to be downloaded somewhere?
Thanks a lot, regards,
Click to expand...
Click to collapse
I feel the backup pain, however - the difference between data backup (easy) versus full system backup - really is it necessary? Or just a "want to" item? (you have to answer that one for yourself...)
AFA the ROMS list, there is a good write up over on Crackberry about that:
CB-how-upgrade-downgrade-keyone-beginners
NOTE: there are many (!) variants of the KEYone - and so many variants of what's out there. NONE allow root. That goes against the very thought of being "secure" - but heck, your Q10 doesn't really give you root access - all you can do is use the leaked versions of whatever BB10 is floating around. - I was an early user of BB10, and just got my KEYone because my Passport went sideways... so yeah, I get it. I also know that, so far, other than the want to, I haven't seen much need in actually rooting it (unlike the Huawei that I carried for the better part of a year)
YMMV.
Paisley Pirate said:
I feel the backup pain, however - the difference between data backup (easy) versus full system backup - really is it necessary? Or just a "want to" item? (you have to answer that one for yourself...)
Click to expand...
Click to collapse
for me I can say, that mostly the possibility to make real full system backups and to create a backup of every app with Titanium is the most important reason, getting full root access. For me, that is mandatory!
NOTE: there are many (!) variants of the KEYone - and so many variants of what's out there. NONE allow root. That goes against the very thought of being "secure" -
Click to expand...
Click to collapse
I know, the my hope was, getting a sudo installed, when a bug in Android would make this possible. Anyway I will not get a KEYone, because I do no like the device very much, mostly I do not like the current keyboard, nor the rounded screen.
but heck, your Q10 doesn't really give you root access - all you can do is use the leaked versions of whatever BB10 is floating around.
Click to expand...
Click to collapse
You are absolutely correct, BB10 means no root and mostly no backup of internal data, like SMS or app-data that do not support any backup from within the app.
I do not like this and I don't want this again with my next device. But right now, I didn't found an successor for my Q10. It's currently just the perfect device for me.
Maybe the "KEYtwo" will be a more interesting device, at least the keyboard should be much better, it seems to be similar to one in my Q10. But again, no root access available ...

Categories

Resources