Do you think it's possible to unlock mango via oem.cab file ?
I know one can rollback, unlock and reupgrade but this cab way would be easier
Sent from my OMNIA7 using Board Express
Can't. Unless you could sign the cab with Microsoft's certificates.
Unless for some reason they made an official cab to do this for manufacturers that got leaked.
Xboxmod cabs only work if the certs are cooked into a rom... And if your flashing custom roms you wouldn't need to do this anyway.
Sent from my HD7 T9292 using XDA Windows Phone 7 App
Incorrect. xboxmod has created a WP7 Cab Builder that you can create your own WP7 Cab Updates. I'm 95% complete. I just need to find a way on the tool to set the password for my MIcrosoft Windows Mobile Firmware Installation PCA.pfx which I will do soon. Once signed, it should be able to be sent to all devices. Providing Interop unlock for ALL devices, regardless of generation. Keep your eyes open. I MAY complete it this month or July. I'll need help from xboxmod and Heathcliff74.
AlvinPhilemon said:
I just need to find a way on the tool to set the password for my MIcrosoft Windows Mobile Firmware Installation PCA.pfx which I will do soon. Once signed, it should be able to be sent to all devices.
Click to expand...
Click to collapse
Well, that will be the problem. You don't have the necessary password, so you can't sign it. And all devices will just reject the cab. (just like reeg420 said) Sry, but the odds are against you.
AlvinPhilemon said:
Incorrect. xboxmod has created a WP7 Cab Builder that you can create your own WP7 Cab Updates. I'm 95% complete. I just need to find a way on the tool to set the password for my MIcrosoft Windows Mobile Firmware Installation PCA.pfx which I will do soon. Once signed, it should be able to be sent to all devices. Providing Interop unlock for ALL devices, regardless of generation. Keep your eyes open. I MAY complete it this month or July. I'll need help from xboxmod and Heathcliff74.
Click to expand...
Click to collapse
You asked me for help. I replied to you, but you didn't get back to me. I am reticent about this, but I always keep an open mind. Tell me what you need and I hope I can help.
Ciao,
Heathcliff74
I just need to find a way on the tool to set the password for my MIcrosoft Windows Mobile Firmware Installation PCA.pfx which I will do soon.
Click to expand...
Click to collapse
This tool is called SignTool.exe, but... Do you know the Microsoft master password for MS certificate??? How come? Do you own a 10 millions PC botnet working two years, brute-forcing MS cert?..
P.S. Seems like you don't understand what are you talking about...
So... I actually had a silly little thought about this. Not sure if it'll work for CABs, but it might work for other areas where we need a MS cert.
Anybody read about how the Flame malware was able to spoof a Windows Update package for PCs? It used a cert produced by a Microsoft tool. The tool is supposed to produce certs used for allowing PCs to connect to a Remote Desktop server, but for some reason the certs were also marked to allow code signing and other useful things. These certs also chain back to the Microsoft root certificate (meaning they are trusted as though issued by MS itself).
Now, for WP7 CABs, I don't know that this will work, because the CABs may need to be signed with a *specific* cert, not just one that chains to the same root. However, it's possibly worth checking...
GoodDayToDie said:
So... I actually had a silly little thought about this. Not sure if it'll work for CABs, but it might work for other areas where we need a MS cert.
Anybody read about how the Flame malware was able to spoof a Windows Update package for PCs? It used a cert produced by a Microsoft tool. The tool is supposed to produce certs used for allowing PCs to connect to a Remote Desktop server, but for some reason the certs were also marked to allow code signing and other useful things. These certs also chain back to the Microsoft root certificate (meaning they are trusted as though issued by MS itself).
Now, for WP7 CABs, I don't know that this will work, because the CABs may need to be signed with a *specific* cert, not just one that chains to the same root. However, it's possibly worth checking...
Click to expand...
Click to collapse
Don't you think that microsoft has learnt its lesson after Flame? Would be reat though
GoodDayToDie said:
Anybody read about how the Flame malware was able to spoof a Windows Update package for PCs?
Click to expand...
Click to collapse
Actually (according to Kaspersky Lab report), Flame malware isn't a simple worm/malware by black-hats but kinda "cyber-weapon" written by professionals from some kind of intelligence/security service (with unknown origin). And of course, some of (by unknown origin ) intelligence/security services have enough computer/human power to obtain a MS certs (by brute force attack with supercomputers or by traditional spy methods - I believe these methods are much more effective than computer-based attack).
I don't think this AlvinPhilemon is genius enough to overcome all mathematicians and security experts in the world. Probably he just has no idea what he's talking about (may be he's just discovered ability to push provisioning file via .cab files on the full unlocked handsets ).
Bah... this is why, even though I actually work in the computer security world, I don't like to even mention Flame; it's been hyped through the roof and seems to trigger some kind of "go crazy" circuit in people. Government-created malware has existed for decades, at least. No need to get all excited about it. In security terms, it is infact just a malicious worm written by blackhats (the "malicious" and "blackhat" parts are redundent; malice is how you define a blackhat). They might be "good guy" blackhats, but they're blackhats all the same.
Getting back on topic, did you actually read the rest of what I wrote? It's possible to get Microsoft-trusted certs, ready for code signing, out of a MS tool. On the PC, MS has pushed a patch that breaks the authorization chain those certs were using, so that it no longer looks like things signed by it are signed by MS itself. However, WP7 has received no such update yet. It's a long-shot, but it's a possibility.
EDIT: Agreed that trying to either brute-force the private key or find a hash collision (which apparently the Flame developers did, but they probably used massive computations resources to do it) is impractical for any individual on this forum.
Hello,
I am a student of Computer Sciene at the University of Udine, Italy.
And recently I have received a AT&T HTC Surround with Windows Phone 7.5.
The problem is always the same. We need to INTEROP-UNLOCK a HTC device.
People greater than me have tried and I do not want to compare to them (I am a noob as stated in the introductory video) but I came up with a sort of idea on trying to develop a new method of interop unlocking.
Since as stated by Heathcliff74 the INTERP-UNLOCK is related to the number of MaxUnsignedApps and the number of max unsigned apps is determined when the Developer Phone Registration program communicates with the server I thought that it could be possible to analyze the behaviour of this app when it communicates with the server and, instead of sending to the phone 3 or 10 send the max number available.
Modifying an exe is a pain so could it be possible to create an emulated server that communicates with Developer Phone registration program by sniffing the connections between the program and the server (I do not know how to do it either since I have just started the network course )?
Maybe it has been already tried but I wanted to tell you anyway since you're great hackers and I am not.
It's a good idea, but I wouldn't hold my breath. This is how the original ChevronWP7 Unlocker hack worked, essentially - you installed a certificate on the phone for a server (normally it uses Microsoft's server and certificate). You then sent the unlock command to the phone and it would try to communicate with the server, but would get the ChevronWP7 server instead, which always said "yes, unlock!"
The catch in your idea is that the fix for ChevronWP7 was to change which certs the unlock process will use - in particular, you can't use user-installed certs anymore - and that means that a user probably can't catch the communication between the phone and the server anymore (which is, I'm sure, where the "value for MaxUnsignedApp" command comes from).
So is the phone that communicates with the server to get the number of apps, not the developer registration program?
Sorry to disappoint you, but it won't work. First of all, it is not the registration-program that communicates with the microsoft server. The registration-program simply send a command to the phone to start the registration process. The phone will contact the Microsoft registration server. The original ChevronWP7 tool spoofed the registration server. Since NoDo this is not possible anymore, because the phone only accepts ssl connections with certified servers (ie servers which have a certificate that roots to a certified authority). The maxunsignedapp is sent over the ssl connection between the phone and the microsoft server, which can't be spoofed or changed with a man-in-the-middle-attack.
Ciao,
Heathcliff74
---------- Post added at 12:57 PM ---------- Previous post was at 12:20 PM ----------
And by the way, Chevron already announced they will release a new Chevron tool, which will do a legit unlock for just a couple of bucks. Just a little more patience.
I have read they launched this now. However how many max unsigned apps till they release and since I have a legit student account on AppHub (I'm a dev) it won't invalidate my account. Just increase the max unsinged apps i think.
Wait for other methods of INTEROP-UNLOCKING.
And thanks to everybody.
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
revxx14 said:
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
Click to expand...
Click to collapse
Compiling desktop apps for ARM using VS 2012 gives an error message, but it can be bypassed. Not sure if the results will run in Windows RT though.
Of course there's no way to find out until Windows RT devices are released to the public, because everyone who has access to one is under NDA. Have some patience.
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Pseudonym117 said:
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Click to expand...
Click to collapse
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
lseidman said:
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
Click to expand...
Click to collapse
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
xanderkaiber said:
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
Click to expand...
Click to collapse
well the simple way would be to sign it. HOW to sign it is a completely different problem... there may be a group policy change or registry edit to turn off signature verification, but i am not familiar with windowsRT at all.
phailyoor said:
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
Click to expand...
Click to collapse
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Windows RT is basically just Win8 recompiled for ARM, with one major exception: EXE files need to be signed by Microsoft before they will run. This means that MS can release desktop apps just fine - they have the signing keys, after all - but third-party software can't run by itself (as a desktop app) and will need to be bundled as an .APPX file (Metro-style app bundle).
If you want to try bypassing the signature check, there are a few things you could attempt. One would be to create your own signing certificate, install the public key in the OSes root code signing cert store (not the per-user store, though it qprobably wouldn't hurt to install it there too), and then sign your test apps with that cert. MS *probably* used certificate pinning - where a specific cert is used, rather than just any cert present in the OS of sufficient trust level - but they may not have, too. Alternatively, you could try looking for some legacy or debug functionality to disable the code-signing. Finally, you coul try using a built-in program, rundll, to invoke your applications.
I can't test any of this right now, because I don't have an RT device. There's a lot of research on them that I want to do, though.
Quote from one very old MS Windows 8 document, from those times when windows RT was called "woa" (2011). Everything could have changed from those days.
Description of the change:
WOA platforms will require that all desktop binary images be signed with a trusted Microsoft certificate. Any unsigned code will fail to load. This document describes the technical steps required to enable unsigned test, development, or manufacturing applications to run. This document does not cover Metro Style applications for which there is a separately documented signing requirement and developer licensing.
Action required
In order for any test binary or tool to run on WOA platforms you must do one of the following:
· Register the install location of your test binaries as an exclusion path, OR
· Attach a Kernel Debugger and disable checking by setting the appropriate registry value
...cut...
2. Scripts - Scripts will be allowed to run if the script host (e.g. cscript.exe, cmd.exe, etc.) is Microsoft signed or is run under an exclusion path.
...cut...
How to register your test binaries in an exclusion path
...cut...
Exclusion paths are listed in the following registry key in REG_MULTI_SZ format:
Key: HKLM\SYSTEM\CurrentControlSet\Control\CI\TRSData
Value: TestPath
Paths added to this key should be in one of two formats:
1. Path (recursive): \Program Files\TestAutomationPath
2. Binary (specific): \Program Files\TestAutomationPath\mybinary.exe
Note: Do not include the drive letter of the volume. Each path will be excluded across all volumes.
...cut...
The following paths are restricted and cannot be added as an exclusion:
1. \
2. \Windows
3. \Windows\System32
4. \Program Files
...cut...
How to disable signature verification with an attached Kernel Debugger
To disable signing verification when a Kernel Debugger is attached the “DebugFlags” value must be deleted from the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI” registry key and the system must be rebooted. After this Signing Verification will not take place.
This can be scripted by putting the following in a .cmd script and executing with admin privilege:
cmd /c reg delete "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI" /v DebugFlags /f
shutdown -r -t 0
...cut...
Note: Enabling Kernel Debug will not be allowed by default on machines with Secure Boot enabled. Either Secure Boot will need to be disabled, or during boot the F8 menu selection to EnableDebugging must be chosen.
...cut...
At a later point, changes will be made to Windows 8 builds which will enforce that only machines configured as “Debug System” will support exclusion paths.
A “Debug System” is will initially be identified by the presence of the Microsoft Test Signing CA in the UEFI signature database (“db”).
...cut...
Note: If there is a need to run unsigned tools, the system can be configured as a “Debug System” during manufacturing but there must be a step in the production process that removes the Microsoft Test CA.
Production machines must not ship with the Microsoft Test CA in the db.
Click to expand...
Click to collapse
First we need to get hands on ARM device. I'd recommend Qualcomm-based, as chinese friends regularly leak their docs/sources. MS Surface is Tegra-based, so don't buy it
And one more thing:
This document “Enabling Debug Mode for Development, Manufacturing, and Support of Windows RT Devices” discusses placing a production device into ‘Debug Mode’ is accomplished by creating a per device Windows Debug Policy using tools provided by Microsoft.
Click to expand...
Click to collapse
Unfortunately I don't have “Enabling Debug Mode...” document, as I don't have access to connect.microsoft.com. Anyway it would not be helpful for us, end-users.
So to turn on a device to debug mode - you'll need a special "something" that is signed for your particular device. Sign is based on 2048-bit key, so you can't bruteforce it. But you can try to hack UEFI. UEFI is partially opensourced, so you can start to study its code now from edk2.sf.net
And one more way. Remember the test signing mode in Win7+. It is still present in Win8. Turn it on via bcdedit on your RT-device, use your own certificate to sign your driver or your program, ..., profit.
But be careful when hacking. There are known problems with BitLocker when test signing mode is on. The OS simply would not boot. Lets hope that we could disable BitLocker on our devices...
Just tried editing the registry to add a testing path. Didnt work
Still asks for certificate
xanderkaiber said:
Just tried editing the registry to add a testing path. Didnt work
Click to expand...
Click to collapse
According to MS document - this would work only on "debug mode"/"debug system" devices.
Can you turn on the test-signing mode:
Code:
In elevated CMD type:
bcdedit.exe /set {globalsettings} testsigning Yes
bcdedit.exe /set {bootmgr} testsigning Yes
bcdedit.exe /set {current} testsigning Yes
and try to sign your app with your own certificate I hope that test signing is still present on WinRT.
But first check that you are not using BitLocker (the "get-bitlockerVolume" command in admin's powershell). According to MS docs the retail device would not boot in this case (this info is taken from windows phone 8 "portico" docs, so may be unrelated to WinRT devices).
danchar4 said:
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Click to expand...
Click to collapse
Theres some info on the web somewhere for a config change to VS2012 that lets it build ARM desktop apps
Not that you can run them due to the signing issues
http://stackoverflow.com/questions/...op-programs-be-built-using-visual-studio-2012
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
xanderkaiber said:
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
Click to expand...
Click to collapse
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
eorsini said:
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
Not a surface, a Qualcomm engineering sample device. But I imagine it would definitely work on the surface also.
xanderkaiber said:
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Click to expand...
Click to collapse
Great news
Seems that turning on the test-sign mode would soon be a must on ARM devices, at least for those of us who need programs like VLC player, DosBox, FAR manager and so on.
As far as I can see, you could port pretty much anything (as long as it's c++) if you can get the source code.
Might give VLC a try now
Doesn't seem like a very good solution to me though.
While it's nice that progress is made, I think that running unsigned apps should be the primary focus - Microsoft could revoke the keys at any time.
What is the current best method to get Microsoft debug tools and symbols onto a windows RT tablet?
Mainly looking to get cdb working
Thanks
BradStevenson said:
What is the current best method to get Microsoft debug tools and symbols onto a windows RT tablet?
Mainly looking to get cdb working
Thanks
Click to expand...
Click to collapse
I don't believe you will be able to install cdb, but I could be wrong.
The following articles may help:
Remote debugging on Windows RT, http://msdn.microsoft.com/en-us/library/windows/apps/bg126234.aspx
Running Windows Store apps on a remote machine, http://msdn.microsoft.com/en-us/library/windows/apps/hh441469(v=vs.110).aspx
For completeness, I have not been able to get any USB/Ethernet NIC adapters to work, even though its Microsoft's recommended [required?] method. I'm fairly certain USB/Ethernet NIC adapters on RT are mythical like unicorns and leprechauns:
Which USB/Ethernet NICs are supported for Remote Debugging?, http://answers.microsoft.com/en-us/...r-remote/59e36bd6-62c4-4b4f-8364-ae25a50a0fbf
Need USB-Ethernet NIC for Windows RT Remote Debugging, http://stackoverflow.com/questions/17387573/need-usb-ethernet-nic-for-windows-rt-remote-debugging
Jeff
> Mainly looking to get cdb working
My bad... someone claimed they got cdb running.... see http://forum.xda-developers.com/showpost.php?p=43032646&postcount=14.