I've got some minor x86 assembly knowledge so I'll have a quick look at it. Hopefully I'll find something,
Possible Interop Unlock Idea
- Thread starter compu829
- Start date
-
- Tags
- interop unlock wp8
Hey guys,
A member has pm'd me as below:
EDIT: i cant confirm the above actually exists yet, i cant d/l as im mobile (8mb file size), but will update soon.
EDIT2: Heres the link: http://www63.zippyshare.com/v/16864065/file.html by Habib.Mouissat (thank him if the info is useful )
A member has pm'd me as below:
Im just waiting for his permission to post the d/l link, i assume this will be useful to you chaps
EDIT: i cant confirm the above actually exists yet, i cant d/l as im mobile (8mb file size), but will update soon.
EDIT2: Heres the link: http://www63.zippyshare.com/v/16864065/file.html by Habib.Mouissat (thank him if the info is useful
)
Last edited:
I received the same PM. I looked through the contents already and came to the conclusion that it won't be THAT much helpful. What we need are the native compiled Dlls looked at (the ones I've listed in my prior replies) in order to see exactly what's going on. A lot of the phone registration .NET files are just COM wrappers.Hey guys,
A member has pm'd me as below:
Im just waiting for his permission to post the d/l link, i assume this will be useful to you chaps
EDIT: i cant confirm the above actually exists yet, i cant d/l as im mobile (8mb file size), but will update soon.
EDIT2: Heres the link: http://www63.zippyshare.com/v/16864065/file.html by Habib.Mouissat (thank him if the info is useful
H
Habib.Mouissat
Guest
hey i can try to decompile this
C:\Program Files (x86)\Common Files\Microsoft Shared\Phone Tools\CoreCon\11.0\Bin\IpOverUsbSvc.exe
C:\Program Files (x86)\Common Files\Microsoft Shared\Phone Tools\CoreCon\11.0\Bin\IpOverUsbSvc.exe
As I've said in my previous posts, I've already decompiled this exe since it is .NET compiled. It references a .NET dll that happens to function only as a COM wrapper for a native PE compiled dll. We will need someone that has x86 assembly experience to use IDA Pro or some other tool to disassemble the DLL(s) and see what they are doing. Any file that can be decompiled using ILSpy or dotNetPeak, etc wont be of any use for this. All of the important functionality come from the native compiled DLLs
Are you sure? I quickly went through the code and saw that it gets an authcode from https://deviceunlockservice.windowsphone.com/passport/login.aspx?url=/&wa=wsignin1.0 and passes it to the device via standard tcp to unlock. The key is to generate a valid authcode from the service. The above url can be overriden via a registry key in HKLM\Software\Microsoft\Windows Phone Registration\8.0\LoginUrlProd. Maybe a reverse custom https service can reveal what the COM code does (not really useful anyway)
What is this sdk anyway? internal or public? There is a lot of code for PROD and INT environments (production and integration?)
There is a b-e-a-u-t-i-f-u-l xap sign tool there too (wrapper around standard signtool). Wasn't there a way to resign a modified .net dll via signtool ... ?
The xapsign tool is only to sign corporate apps. This would be a good one to possibly reverse, but to answer your first question we still need to know how the tool communicates with the device to unlock it. I saw the deviceunlock service endpoint call, but as you said we'd need to generate a valid authcode. Since the authcodes are handed by the server on Microsoft's end, it might be difficult to know how to generate one unless we can dig unto the COM Dlls and discover the algorithm and/or somehow recompile it to unlock regardless. That might be a little impossible if the DLLs are signed.
Well, the xapsign tool gives the whole algorithm of how the xaps are signed. the whole structure. it is useful information!
The way the pc communicates with the device is written in .net as I said. It's tcp, in a custom byte protocol that the main data is an authcode. The authcode is retrieved by calling the url via a com dll. So, we could tell the com dll to call a custom service (probably with a trusted cert). We can see what requests are posted. Forwarding those to the real url, we also get the result. So the logic is kind of revealed without digging in the dll. But anyway, I do not think this will get anywhere if the url returns the authcode and the dll just wraps some tcp logic. If the dll has some validation logic, we could brute-force it to also reveal the validation rules. useful info too!
Whether the dlls are signed or not makes no difference... since i do not think ms put their unlock code in a distributable dll and not on their servers.
Oh I imagine they don't have the unlock code in a distributable dll, but I would imagine they have the logic for determining whether the unlock code is in the valid format in one of those COM Dlls. Microsoft puts ENOUGH things in .NET to spark our curiosity, but the bulk backbone of these essential services are in native code. I'm hoping GoodDayToDie will have some time eventually to take a look at it and see what can be done
this is great news. At least this is a positive step in terms of potentially modifying ROM dumps to change the Hive. That is what I got from the post on the Huawei W1. Right now, this still doesn't mean that Inter-Op unlock is possible, but this gives us great potential. Perfect way to start my Friday
Assuming interop lock is implemented on WP8 the same way as on WP7 (requires MaxUnsignedApp >= 300 to sideload interop apps) then the Huawei hack permit unlocking just fine. I'm considering ordering one just to hack on and try things... that doesn't directly help us with the rest of the devices though (also, no surprise Huawei was the first to fall; I've never seen Huawei code that comes within shouting distance of the word "secure" which means I really would rather not use it as my day-to-day phone). It's also a chance to look at some other aspects of the system, though, and that might help find breakthroughs that can be used on other devices.
A
aclegg2011
Guest
true..
Now that we have a custom rom, we should be able to peek through the files and look for exploits. Then the next step would be to find a way to implement the exploit to a stock phone.