I'll try to put this as simple as possible.
PLEASE tell me if I have missed anything or need to add any more information
First, you have Developer Unlock, which put simply, when you submit an app to the store, it gets "signed" with a digital signature. Windows Phone devices will only run applications with that signature. Since if you are developing an app, it is not "signed" so with a Developer Unlock, you are able to run applications without a "signature" on any Windows Phone device but there are limits.
That's where Interop-Unlock comes in. A developer-unlocked device can sideload an app but the app is not able to access the Windows Phone system and Registry. Every app, whether sideloaded or installed from the Windows Phone Store, MUST declare what functions the apps needs to use to function properly. To access certain parts of the system and registry, it needs to declare "ID_CAP_INTEROPSERVICES" in the WMAppManifest.xml. A normal app, for example "Doodle Jump" declares these functions:
Code:
<Capability Name="ID_CAP_NETWORKING" />
<Capability Name="ID_CAP_SENSORS" />
<Capability Name="ID_CAP_MEDIALIB" />
<Capability Name="ID_CAP_GAMERSERVICES" />
<Capability Name="ID_CAP_IDENTITY_DEVICE" />
Which is basically the app telling the phone "Hey man, I need to be able to access the internet (ID_CAP_NETWORKING), access your motion sensor (ID_CAP_SENSORS), media library, Xbox Live and your device's identity.
Those declared functions are allowed by the Store and to be sideloaded. However to edit the registry, the app needs the ID_CAP_INTEROPSERVICES declaration in the WMAppManifest.xml. The Store does not allow apps with this declaration to be uploaded by 3rd-party developers. Nor does the device allow the app to deploy with that declaration.
Here's where the problem is. In order to allow the app with the INTEROPSERVICES cap to be deployed, you need to override an entry in the Registry (setting the maximum allowed apps to be deployed to over 300 overrides the INTEROPSERVICES cap.). But in order to override the entry, you need the INTEROPSERVICES cap to edit the registry (chicken-and-egg, anyone?).
This restriction was introduced in the Windows Phone 7.5 update but thankfully, 1st-party and 2nd-party developers are able to upload apps with the INTEROPSERVICES cap declared (1st-party, namely Microsoft and 2nd-party being OEMs). So what we do is find a weakness, or exploit in the app to be able to edit the Registry.
How this was done for Samsung Windows Phone 8 devices was that the Samsung Diagnosis app that was hidden, had a registry editor hidden somewhere within the app. @GoodDayToDie and -W_O_L_F- found the editor and managed to Interop-Unlock the Samsung ATIV S, which was found to work on other Samsung Windows Phone 8 devices. This does NOT work on other devices as Samsung uses a method to edit the registry that is not found on other devices.
What we are doing now in the Development & Hacking Sub-forum is trying to find exploits in those 1st-party and 2nd-party applications on Windows Phone. We hope to find a way to Interop-Unlock other devices as soon as possible, but only time will tell...
redacted
So from what i understand, apps which Microsoft/Nokia release have the special ability to change the registry and changing the registry can interop unlock your phone. So you find how the app does that and use it to change the registry. Am i right?
hashmiakbar said:
So from what i understand, apps which Microsoft/Nokia release have the special ability to change the registry and changing the registry can interop unlock your phone. So you find how the app does that and use it to change the registry. Am i right?
Click to expand...
Click to collapse
They have permissions to change the registry settings for their own apps, but that is all.
Use snickler's registry app to see it in action.
Sent from my Lumia 928 (RM-860) using Tapatalk
Related
Can somebody please tell me if there is a registry edit program for the DHD.I have looked everywhere with no luck.Thanks
Unfortunately android doesn't use a registry for speed reasons.
but the alternative to a registry would be simply rooting your phone and patching features or files.
Unlike Windows Mobile, android is open source meaning that any hidden features or tweaks would be discovered reasonably quickly.
This thread is for announcements and discussion around the WP8NativeAccess project (https://wp8nativeaccess.codeplex.com/). The purpose of this project is to provide general-purpose libraries, usable from C++ or .NET, which enable access to the underlying functions of the OS. In some cases, this will mean simple wrappers around native APIs; in other cases, these will be more advanced operations which simplify using the low-level APIs.
Some of the functions that the Native Access project exposes are already available via the official APIs. Other functions, however, are not. While I have no objection to these libraries being used in Store apps (license permitting), it is unlikely that Microsoft will permit the ones which use unofficial APIs.
Note that this library does not provide any method for elevation of privileges. Consequently, the use of these APIs will be constrained by the sandbox in which all third-party WP8 apps run, as defined by the capabilities in the app manifest. In practical terms, this means that most of the system will be either inaccessible or read-only. Even so, it has already proven useful to myself. When combined with interop-unlock and Capability-unlock hacks (making it possible for apps to obtain higher privileges), these APIs become much more useful. In fact, the EnableAllCapabilities utility uses the Registry library. Similarly, if you have the ability to use restricted Capabilities in an app you are developing, you may find these libraries useful.
The libraries are as follows:
FileSystem version 0.4.0: Implements functionality to read, write, and get information about files and directories, plus supports creating symbolic links and enumerating file system volumes. This version contains a breaking change from 0.3.x: the NativeFileSystem functions are now static and the constructor is removed. This library may be built with or without the macro USE_NON_PUBLIC_APIS; by default it now includes this macro and require kernelbase.lib to build. If this macro is not defined, it builds using the public APIs without requiring any special libraries.
Registry version 0.2.9: Implements functionality to read and write registry values, and to create and delete registry keys and values. Many, though not yet all, registry value types are fully supported. This library consists entirely of non-public (for WP8) APIs and requires the KERNELBASE.LIB and ADVAPI32LEGACY.LIB export libraries for Windows Phone 8 in order to build (the DLLs are in C:\Windows\System32 on the phone; you can use Dll2Lib.exe to extract the .LIB files).
Processes version 0.1.0: Implements basic functionality to get information about your process, and to create or kill a child process. Very early version.
They are licensed under the Microsoft Permissive License.
The FileSystem and Registry libraries are currently being used by my WP8 File Access Webserver project (http://forum.xda-developers.com/showthread.php?t=2355034).
My EnableAllSideloading app uses the Registry library (http://forum.xda-developers.com/showthread.php?t=2435697).
@hjc4869 has a basic FileExplorer app which uses the FileSystem library (http://forum.xda-developers.com/showthread.php?t=2497788).
You may need to use 7-Zip or another extraction program better than the built-in Windows Zip extractor to open the archive.
Reserved for OP...
Updated. This will be the main place on XDA for releases of the NativeAccess libraries going forward. Additionally, please report problems or make feature requests here.
I think there should be some way to list all the volumes...
Perhaps windows runtime has provided an async win32 file API wrapper which has the same ability as win32 ones ,so I think undocumented file API and registry ,process and etc are more important.
The latest version of the NativeFileSystem library can give you the mount points (as strings) for all volumes (C:\, D:\, etc.)... I implemented that a few days ago; it should be in this update. Sorry for not highlighting that more clearly (typo in the OP fixed now).
Can't open "NativeAccessLibraries_040_029_010.zip"
Edit Ok with 7-zip
How odd, you're right. I didn't do anything terribly fancy while building that ZIP, so I really don't know what's up with that.
I have added the NativeFileSystem library to my PDF to Office app...
Thanks again for all your work !
@GoodDayToDie: Congratulations, good work! Unfortunately I can't import the registry library, it says it's not a valid DLL. I have Visual Studio 2013 Pro. Does it work for WP8? Please help me solving the problem. Thanks!
Sent from my Windows Phone using Tapatalk
myst02 said:
@GoodDayToDie: Congratulations, good work! Unfortunately I can't import the registry library, it says it's not a valid DLL. I have Visual Studio 2013 Pro. Does it work for WP8? Please help me solving the problem. Thanks!
Sent from my Windows Phone using Tapatalk
Click to expand...
Click to collapse
You need to reference .winmd file, not the .dll file.
Thanks! Can we also modify hex registry values with it?
Sent from my Windows Phone using Tapatalk
If you have the required permissions, yes. There's read/write functions for REG_BINARY, and also a simple wrapper around RegSetValue that will work for any type.
However, the library doesn't actually give you any privileges your app didn't already have. Without special Capabilities (which usually require hacks to enable), you won't have write access anywhere in the registry at all...
GoodDayToDie said:
If you have the required permissions, yes. There's read/write functions for REG_BINARY, and also a simple wrapper around RegSetValue that will work for any type.
However, the library doesn't actually give you any privileges your app didn't already have. Without special Capabilities (which usually require hacks to enable), you won't have write access anywhere in the registry at all...
Click to expand...
Click to collapse
OK, thanks, but another question: I referenced .winmd file, but it gives me error, the component was not found. Any idea how to fix it?
Do you have the DLL and the WINMD in the same location? Are you creating a WP8.0 app (I don't know if apps targeting 8.1 specifically will work)? Are you building for ARM?
Yeah, I have. Library now working, but it doesn't recognize the commands, I mean if I write NativeRegistry.ReadDWORD command not found :/ Can you help me?
Sent from my RM-915_lta_lta_330 using Tapatalk
You're going to need to be way more specific.
How far did you get, i.e. can you compile the app? Install the app? Launch the app? Does it crash immediately or does it actually load? Etc.
What, *exactly*, breaks? Does it break when you try to reference the NativeRegistry library, or only when you try to actually use ReadDWORD function, or some time later? If you are able to call readDWORD, what is the return value? If it fails, what is the error code?
Are you getting an exception, or does it just not work? If it's an exception, give me as much detail about it as you can (the type, the message, the code where it happened, etc. if possible).
myst02 said:
Yeah, I have. Library now working, but it doesn't recognize the commands, I mean if I write NativeRegistry.ReadDWORD command not found :/ Can you help me?
Sent from my RM-915_lta_lta_330 using Tapatalk
Click to expand...
Click to collapse
Try to rebuild the solution.
GoodDayToDie said:
You're going to need to be way more specific.
How far did you get, i.e. can you compile the app? Install the app? Launch the app? Does it crash immediately or does it actually load? Etc.
What, *exactly*, breaks? Does it break when you try to reference the NativeRegistry library, or only when you try to actually use ReadDWORD function, or some time later? If you are able to call readDWORD, what is the return value? If it fails, what is the error code?
Are you getting an exception, or does it just not work? If it's an exception, give me as much detail about it as you can (the type, the message, the code where it happened, etc. if possible).
Click to expand...
Click to collapse
Hi, I can't even build it, it doesn't recognize the command and makes a red line under it. I can reference the library, but not use any commands like ReadDWORD, WriteDWORD and so on. Screenshot is attached, this is happening if I load your EnableAllSideloading App, for example. With self-created projects I have the same problem. My system is Win 8.1 Pro x64 and I'm using Visual Studio 2013 Professional. Can you help me? Thanks!
You have added
Registry.winmd in reference library
and
Using Registry;
in your source code
Source code for EnableAllSideloading already has the requisite using directives...
When you look in the project's References, is the Registry library referenced correctly? By default it'll try to use a relative path that I use on my PC, but probably not the same path you use. You may need to manually adjust the reference, or delete it and re-create it.
Alternatively, what auto-fix options does Visual Studio give you when you click on those red lines?
Rebranded to WP8 Registry Tools from Lumia Registry Modifier
This is a basic registry viewer/editor demonstration using Registry dlls pulled from Nokia xaps within the latest FFUs.
First, a few things to note.
1) This only retrieves values from HKEY_LOCAL_MACHINE
2) It CAN read DWORD values now, but can't write. (Hell you probably won't be able to write ANYWHERE, but the code is there)
Instructions are quite simple.
To Read Values:
1) Put the Registry key in the first box (ex. SOFTWARE\Classes\MIME\Database\Codepage\1254
2) Put the Registry Value in the second box (ex. 1254)
3) Press Get Value.
To Set Values:
1) Put the Registry key in the first box (ex. SOFTWARE\Classes\MIME\Database\Codepage\1254
2) Put the Registry Value in the second box (ex. 1254)
3) Put the new registry value result in the Set Value box.
4) Press Set Value.
This is very very basic, but I wanted to just show off something using what Nokia has provided us.
We can't write dword values unfortunately so hopes of using this to change the MaxUnsignedApp value are lost. This MAY be possible with @GoodDayToDie 's WP8NativeAccess library, but with this it isn't.
In case everyone wondered what that key is... SOFTWARE\Microsoft\DeviceReg\Install
Side load away
Hmm... I get Access Denied in my library on most keys that I've tried to write. If you can write the codepage, that's interesting (generally speaking, HKLM has stronger protections). I'll double-check whether I can write there myself. If not, but you can, then we have an elevated privilege attack vector...
Also, we should see whether the app runs on non-Nokia devices. I suspect that it will, if it works the way I think it does, but in that case it also won't have much in the way of permissions.
Getting DWORDs to work is a good project, I'm sure it's possible (works fine in NativeAccess, incidentally).
EDIT: Any chance you could include the source?
snickler said:
This is a basic registry viewer/editor demonstration using Nokia's Native Registry dll pulled from one of their apps.
First, a few things to note.
1) This only retrieves values from HKEY_LOCAL_MACHINE
2) DWord values aren't supported.
Instructions are quite simple.
To Read Values:
1) Put the Registry key in the first box (ex. SOFTWARE\Classes\MIME\Database\Codepage\1254
2) Put the Registry Value in the second box (ex. 1254)
3) Press Get Value.
To Set Values:
1) Put the Registry key in the first box (ex. SOFTWARE\Classes\MIME\Database\Codepage\1254
2) Put the Registry Value in the second box (ex. 1254)
3) Put the new registry value result in the Set Value box.
4) Press Set Value.
This is very very basic, but I wanted to just show off something using what Nokia has provided us.
This doesn't seem to work with dword values unfortunately so hopes of using this to change the MaxUnsignedApp value are lost. This MAY be possible with @GoodDayToDie 's WP8NativeAccess library, but with this it isn't.
In case everyone wondered what that key is... SOFTWARE\Microsoft\DeviceReg\Install
Side load away
Click to expand...
Click to collapse
atleast its a start.
GoodDayToDie said:
Hmm... I get Access Denied in my library on most keys that I've tried to write. If you can write the codepage, that's interesting (generally speaking, HKLM has stronger protections). I'll double-check whether I can write there myself. If not, but you can, then we have an elevated privilege attack vector...
Also, we should see whether the app runs on non-Nokia devices. I suspect that it will, if it works the way I think it does, but in that case it also won't have much in the way of permissions.
Getting DWORDs to work is a good project, I'm sure it's possible (works fine in NativeAccess, incidentally).
EDIT: Any chance you could include the source?
Click to expand...
Click to collapse
ah yes, sorry about that. Let me load up my laptop
EDIT: Source added.
Hi I found the Registry item
(File path : <ffu>\Windows\Packages\RegistryFiles\SOFTWARE.REG)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\KindMap
where we can set extensions and their types.so is it possible to add a new extension so that it will also be supported and visible in sdcard ?
vivekkalady said:
Hi I found the Registry item
(File path : <ffu>\Windows\Packages\RegistryFiles\SOFTWARE.REG)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\KindMap
where we can set extensions and their types.so is it possible to add a new extension so that it will also be supported and visible in sdcard ?
Click to expand...
Click to collapse
It doesn't support creating new key values, only modifying existing ones. If the data is within one key value and it's able to be read, then it should be able to have things added to it.
EDIT: From what I've seen, what you're trying to do won't be possible with this. Each extension has a different key value.
We may need to start an "interesting registry values" thread here, similar to the one for WP7. Of course, it'll be more interesting if we can actually change any of them.
Oh, and the app works on my ATIV S, just by the way. Need to find some interesting paths to test it on, though.
EDIT: Have you been able to write to *any* values using this? It fails for me every time, but I haven't tried that many yet.
GoodDayToDie said:
We may need to start an "interesting registry values" thread here, similar to the one for WP7. Of course, it'll be more interesting if we can actually change any of them.
Oh, and the app works on my ATIV S, just by the way. Need to find some interesting paths to test it on, though.
EDIT: Have you been able to write to *any* values using this? It fails for me every time, but I haven't tried that many yet.
Click to expand...
Click to collapse
it has failed for me also. The only values I could write to were the ones that corresponded to Nokia. I'll look through the code again and make another update. I'm going to also rebrand it since it works for non Lumia phones.
Interesting about the Nokia paths working. That could be some characteristic of the DLL you use having better permissions or something specific to OEM stuff, but I actually suspect it's just that Nokia didn't bother to lock down the ACLs on their parts of the registry. You can easily adapt the app to my NativeRegistry class to test this, if you want.
Hmm that's a good idea. I just rebranded it to WP8 Registry Modifier. I'll add in your NativeRegistry class to work along with the RegistryRT class to see what comes about.
DWORD support
For DWORD support, take a look at the Nokia.SilentInstaller.Runtime.wim... The "CSilentInstallerRuntime" class contains multiple methods to interact with the registry including:
CreateKey
GetRegDWORDValue
GetRegSZValue
GetRegSZValueL
IsRegistryDWORDValueExists
IsRegistryKeyExists
IsRegistryREGSZValueExists
SetRegDWORDValue
SetRegSZValue
A bit off topic, I found a way to launch any URI... Literally, ANY URI (app:// http:// or anything). I can launch any application (using the GUID - so it must be a registered application but doesn't have to be one that you see in your programs list) and go to a specific page within that application. I can also pass any kind of query string that could unlock some hidden features in an application (such as the Extras+Info application - I can launch it using any dial string even though my ROM has that particular dial string disabled). I do so by launching a Toast message which allows me specify a launch uri and once it pops up, I click it. If anyone's interested, I can post a code sample for that...
@GoodDayToDie I'm able to read DWORDs with your NativeRegistry framework. I haven't been able to write though (I've only looked at the MaxUnsignedApp reg value).
What I think I'm going to do is possibly scrap the RegistryRT framework and just use yours. I can then make an even more robust app.
cpuguy said:
For DWORD support, take a look at the Nokia.SilentInstaller.Runtime.wim... The "CSilentInstallerRuntime" class contains multiple methods to interact with the registry including:
CreateKey
GetRegDWORDValue
GetRegSZValue
GetRegSZValueL
IsRegistryDWORDValueExists
IsRegistryKeyExists
IsRegistryREGSZValueExists
SetRegDWORDValue
SetRegSZValue
A bit off topic, I found a way to launch any URI... Literally, ANY URI (app:// http:// or anything). I can launch any application (using the GUID - so it must be a registered application but doesn't have to be one that you see in your programs list) and go to a specific page within that application. I can also pass any kind of query string that could unlock some hidden features in an application (such as the Extras+Info application - I can launch it using any dial string even though my ROM has that particular dial string disabled). I do so by launching a Toast message which allows me specify a launch uri and once it pops up, I click it. If anyone's interested, I can post a code sample for that...
Click to expand...
Click to collapse
I was actually looking at the SilentInstaller not long ago. I got sidetracked by the fact that I could use the NativeRegistry read DWORD values. I'll check that out and upload a new build in a few
GoodDayToDie said:
We may need to start an "interesting registry values" thread here, similar to the one for WP7. Of course, it'll be more interesting if we can actually change any of them..
Click to expand...
Click to collapse
I can write one up later. I have several registry keys that I'd like to bring attention to.
NOTE: I don't see anything editable yet, at least I can read it to compare it to the files in the ffu.
Launching a URI should be possible more directly than that, using ShellExecute, or similar, but that way is cool (and doesn't require importing unofficial native functionality).
Just a word of warning: NativeRegistry is under heavy modification. I hope to have the next Alpha release done soon, which brings a ton of changes, but in the meantime you might want to follow the changes on CodePlex; while I test every build that I push, I don't always publish the binaries.
There will be two ways to use the registry through NativeAccess soon: one is to use fairly thin wrappers around the native functions (that's mostly what's implemented now, but it will be expanded to include key and value enumeration, key creation, etc.), and the other is to use a class more akin to a .NET RegistryKey class, offering the ability to interact in a more object-oriented manner (where the object itself represents an open key).
Something I did notice when I tried to compile the NativeRegistry source (I just ended up using the binary you had for my testing) is that it kept blowing up on the include for WinReg.h. I don't have that anywhere. Am I missing something?
snickler said:
Something I did notice when I tried to compile the NativeRegistry source (I just ended up using the binary you had for my testing) is that it kept blowing up on the include for WinReg.h. I don't have that anywhere. Am I missing something?
Click to expand...
Click to collapse
I'm not sure how GoodDayToDie did it himself (probably same approach I take it) but I compiled it using the "WinReg.h" from the Windows 8 SDK and removing the desktop-only compiler "if" instruction (lines 49 and 1446). And like he mentioned, you also have to create the KERNALBASE.LIB with the required registry export functions for the linker.
cpuguy said:
I'm not sure how GoodDayToDie did it himself (probably same approach I take it) but I compiled it using the "WinReg.h" from the Windows 8 SDK and removing the desktop-only compiler "if" instruction (lines 49 and 1446). And like he mentioned, you also have to create the KERNALBASE.LIB with the required registry export functions for the linker.
Click to expand...
Click to collapse
Ah ok, thanks!
cpuguy said:
A bit off topic, I found a way to launch any URI... Literally, ANY URI (app:// http:// or anything). I can launch any application (using the GUID - so it must be a registered application but doesn't have to be one that you see in your programs list) and go to a specific page within that application. I can also pass any kind of query string that could unlock some hidden features in an application (such as the Extras+Info application - I can launch it using any dial string even though my ROM has that particular dial string disabled). I do so by launching a Toast message which allows me specify a launch uri and once it pops up, I click it. If anyone's interested, I can post a code sample for that...
Click to expand...
Click to collapse
Yes, please post your code and give yourself your own thread (at least keep it here in development ). There are a lot of underlying dialer codes that Nokia disabled when flashing the 928s. Also this could mean we could have a custom app launcher, if you wanted to customize it that way. Most of the work we have done on WP8 has occurred in the past few months; we are finally getting so close to the first InteropUnlock for Nokia/WP8.
Sent from my RM-860 (Lumia 928) using the OFFICIAL Tapatalk app.
I'm trying to figure out the correct method prototype (since this is a method that appears to be WinPhone only and isn't part of the SDK so, no details on it whatsoever)... I stumbled upon this toast functionality in "NokiaFrameworkOBAWinPRT.dll" under the "DevPropHelper" class. The method to call is "InvokeToast". This method ends up calling "Shell_PostMessageToast" in "ShellChromeAPI.dll" (this is what I'm trying to invoke directly without going through the Nokia dll).
Add a reference in your project to "NokiaFrameworkOBAWinPRT.winmd" (you can find this in newer versions of the Extras+Info app)
Add the necessary <InProcessServer> tag (to allow the "NokiaFrameworkOBAWinPRT.DevPropHelper" class) in the <ActivatableClasses> section of you WMAppManifest.xml file
In the code... Create an instance of "NokiaFrameworkOBAWinPRT.DevPropHelper"
In the code... Call the "InvokeToast" method (of the previously created object) passing it:
Application GUID (can be your local app's GUID - doesn't seem to matter)
URI to launch in string format
Toast title (can be anything)
Toast content(can be anything)
When the Toast notification pops up, click on it and that's it.
This is a new thread created in order to clean up most of the Hacking and Development forums. Several hardworking developers and myself (I can't exactly call my self a developer, but I still can contribute in some way) have been plugging hours into this and it needs its own thread in order to help understand what Interop was for WP7, how it worked then, and how we work for finding it in WP8. For most of this, I can't say I'm a definitive source for this type of knowledge. I'm just another WP8 user who wishes for more tweaks .
Anyways, I have a few PMs to send and this and the next few posts will be updated with the relevant information.
EDIT: This first post will be about the process to getting close edit things required for InteropUnlock on WP8 devices as of now, as it hasn't been achieved yet.
At the moment the complete process requires installation of WP SDK and/or installing Windows Phone Power Tools, downloading and deploying @snickler 's Lumia Registry Editor.
snickler said:
I did find THIS.
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\DeviceReg\Install]
"MaxUnsignedApp"=dword:7FFFFFFF"
That translates to the value of InteropUnlock by default which means we should be able to sideload more than 10 apps at a time.
I also found these within policy xml files.
Code:
Microsoft.BaseOS.SecurityModel.policy.xml
<Capability ElementID="2EF45E94A01864DE3387212D6E73AEA885E709AD0F24FB97FE2E84728CB09D14" AttributeHash="49B8EC80A54998B68D7F65A44A340FD28B535494B7A41D650FD94851E38A6B6B" Id="ID_CAP_DEVELOPERUNLOCK" AppCapSID="S-1-15-3-1024-2489250862-3731101856-757172019-2830005102-2903107461-2549818383-1921265406-345878668" SvcCapSID="S-1-5-21-2702878673-795188819-444038987-1443" FriendlyName="Enable bearing chamber to load unsigned modules" Visibility="Internal" />
<Capability ElementID="BAFBED1970753822A266C1985F4A2CA2BA7A97CCE149F874743D00F678643C26" AttributeHash="54A2744DE064E139FD4403623C2AB9F1E130BC5C0786F56C1CE39AC814DC3F03" Id="ID_CAP_DEVELOPERUNLOCK_API" AppCapSID="S-1-15-3-1024-435026874-574125424-2562811554-2720811615-3432479418-1962428897-4127210868-641492088" SvcCapSID="S-1-5-21-2702878673-795188819-444038987-1450" FriendlyName="Enable setting of registry key protecting developer unlock mode." Visibility="Internal">
<CapabilityRules>
<Rules>
<RegKey ElementID="F0921CC3ADB2FEE5B7DC90F9F2BBDDB6E4D7BFAF9CE189C1585A90CD71E36882" DACL="(A;CI;KRKW;;;S-1-15-3-1024-435026874-574125424-2562811554-2720811615-3432479418-1962428897-4127210868-641492088)(A;CI;KRKW;;;S-1-5-21-2702878673-795188819-444038987-1030)(A;CI;KRKW;;;S-1-5-21-2702878673-795188819-444038987-1450)" Flags="515" Path="HKEY_LOCAL_MACHINE\Software\Microsoft\SecurityManager" />
</Rules>
</CapabilityRules>
</Capability>
<Capability ElementID="BAFBED1970753822A266C1985F4A2CA2BA7A97CCE149F874743D00F678643C26" AttributeHash="54A2744DE064E139FD4403623C2AB9F1E130BC5C0786F56C1CE39AC814DC3F03" Id="ID_CAP_DEVELOPERUNLOCK_API" AppCapSID="S-1-15-3-1024-435026874-574125424-2562811554-2720811615-3432479418-1962428897-4127210868-641492088" SvcCapSID="S-1-5-21-2702878673-795188819-444038987-1450" FriendlyName="Enable setting of registry key protecting developer unlock mode." Visibility="Internal">
<CapabilityRules>
<Rules>
<RegKey ElementID="F0921CC3ADB2FEE5B7DC90F9F2BBDDB6E4D7BFAF9CE189C1585A90CD71E36882" DACL="(A;CI;KRKW;;;S-1-15-3-1024-435026874-574125424-2562811554-2720811615-3432479418-1962428897-4127210868-641492088)(A;CI;KRKW;;;S-1-5-21-2702878673-795188819-444038987-1030)(A;CI;KRKW;;;S-1-5-21-2702878673-795188819-444038987-1450)" Flags="515" Path="HKEY_LOCAL_MACHINE\Software\Microsoft\SecurityManager" />
</Rules>
</CapabilityRules>
</Capability>
Click to expand...
Click to collapse
How Interop works
I'll start by adding this from a different thread
GoodDayToDie said:
It's a valid point. Interop-unlock loosened a lot of restrictions on WP7, and was presumably used by OEMs and MOs who needed easy ability to install ID_CAP_INTEROPSERVICES apps to test their high-privilege apps.
However, in WP8, things are different. What capabilities can be installed is now controlled via the policy engine, or whatever it's WP8 equivalent is called. Policy "classes" are indicated via key usage identifiers in the certificates used to sign XAPs. ID_CAP_INTEROPSERVICES (and nearly all other interesting capabilities) requires the class intended for use by OEMs. If we can't get our hands on such a signing key, or find some way to spoof it, we may be in a pickle with regard to a jailbreak via this approach.
It's possible that interop-unlock will function much as before too, though; freeing the limitations on app capabilities for all apps, even unsigned ones. It's worth a shot. Somebody might want to decompile the relevant code and investigate, though.
Click to expand...
Click to collapse
Reserved Post 2 - What Interop's purpose served, ect
ssoo I can't read...
Check out the thread I just started/please merge the other thread with this one (If it belongs here). Hopefully my find will be useful! http://forum.xda-developers.com/showthread.php?t=2407441
compu829 said:
Check out the thread I just started/please merge the other thread with this one (If it belongs here). Hopefully my find will be useful! http://forum.xda-developers.com/showthread.php?t=2407441
Click to expand...
Click to collapse
Yes, please move your post. I'd do it voluntary before mods start having to clean this board.
So I want to explore my Samsung ATIV S' registry as I do not know almost all its entries and I want to see what I can customise so I want to ask: will there be a registry explorer for WP8? Because according to GDTD, all interop apps on wp7 don't work on WP8.
The native webserver I built already works pretty well as a registry browser; it just can't make edits (at this time). I'm working on one with a bit more functionality (I've already gotten reading multi-strings supported, and I'd like to get editing working).
An on-device one would, of course, be nice. One option here would be to take the source code to a WP7 one and upgrade the project to WP8, then remove the COM interop used for WP7 homebrew and replace it with the C++/CX native component and .WINMD file for interfacing. Re-write the native interface layer to use the .WINMD (should be easy, actually, since there had to be a COM interop interface already; just replace that interface) and add ID_CAP_INTEROPSERVICES, and it *should* work.
GoodDayToDie said:
The native webserver I built already works pretty well as a registry browser; it just can't make edits (at this time). I'm working on one with a bit more functionality (I've already gotten reading multi-strings supported, and I'd like to get editing working).
An on-device one would, of course, be nice. One option here would be to take the source code to a WP7 one and upgrade the project to WP8, then remove the COM interop used for WP7 homebrew and replace it with the C++/CX native component and .WINMD file for interfacing. Re-write the native interface layer to use the .WINMD (should be easy, actually, since there had to be a COM interop interface already; just replace that interface) and add ID_CAP_INTEROPSERVICES, and it *should* work.
Click to expand...
Click to collapse
Erm... in English? :laugh::laugh::laugh:
AlvinPhilemon said:
Erm... in English? :laugh::laugh::laugh:
Click to expand...
Click to collapse
Take the source code from one of the WP7 Registry Browsers, upgrade the source to a WP8 project, strip out the old COM code and replace it with GDTD's libraries.
Well, and the code from the Samsung Diagnosis app (the native DLL, which is accessed using a .WINMD or WINdows MetaData file, which can be added as a Reference to a C# phone app project). So far, using the RPCComponent + ID_CAP_INTEROPSERVICES still offers much greater write access than any of the Capabilities that can otherwise be added even with interop-unlock.