The Current State of Windows Phone 7 Modification
Have you noticed that there has been very little Windows Phone 7 development/modification? Devices have been shipping for a few days in the US, and for a bit longer than that in other countries, and we have yet to see the first signs of development and modification on the new Windows Phone 7 platform. We spoke with XDA veteran developer and Senior Moderator Da_G to get some much-needed answers. Here’s a look at his views on Windows Phone 7 modification and its possibilities:
1) Will WP7 ever work on a legacy Windows Mobile device?
Natively, probably not very likely. (“Natively” meaning compiled specifically for, loading and running without any fudging being done) This would require access to source code that we simply don’t have (with very few exceptions, behind tightly closed doors) – the reason for this is that WP7 is not binary-compatible with WinMo. This means that to port anything written in native code (like the kernel, drivers, etc.), it needs to be re-compiled from source code. With some extreme low level hackery, one could accomplish it, however it would not be worth the result.
However, currently Cotulla has WP7 booting and functioning to a certain extent on the HD2. This was accomplished by the use of a “RAM Loader” – in essence it is emulating a disk in RAM, and telling the CPU to start executing instructions from there. The loader also allows access to debug data and other necessary low level information to bring up the platform. This reduces much of the initial complexity (don’t need to know as much about the hardware to bring it up).
Without source code, or heavy documentation of the internals, and a dedicated team of coders/reverse engineering gurus, I would say as Porting WP7 to a legacy Windows Mobile device is next to impossible. The exception at this time being HTC HD2, which we’re likely to see a functioning WP7 ROM for soon (with some caveats discussed below).
2) If yes, which ones? Is there any hope for older devices like Rhodium, etc?
This is pretty much covered by the answer for 1), but to espouse on that a bit, there is some hope for the Wizard, as limited source code is available for that platform, as well.
3) Why is it taking so long to do the port?
There are alot of bugs, quirks, things that just don’t behave how you’d expect, etc. that come about when reverse engineering a platform. Sometimes debugging output doesn’t quite make sense and it takes some heavy tracing to find the real culprit. It would be alot quicker with full access to source code!
1) Will any system modification be possible in WP7? To what degree?
The biggest hurdle here will be “jailbreaking” the device, once that is done, the system will be fully modifiable just as WM 6.x is now. The ROM Filesystem is set up similarly, the package scheme is still there, with extensive additions/changes for security. Most of these security measures rely on the user not having an “escalated” privledge level, so once that is accomplished, the can of worms will open up! It should be even easier to modify the UI portions of the system, as they are based on silverlight and XAML, which is much easier to modify than “Windows Forms” style controls used in WM 6.x.
Much of the paradigm is the same (.dll files containing resources, such as pngs, jpgs, etc.) so alot of the current knowledge will carry over. There are already preliminary kitchens in the work (although they can only work on devices with an unlocked bootloader that allow flashing of unsigned images at this time)
2) What are the hurtles preventing developers from modifying the system?
Microsoft laid down some extremely strict rules, regarding the security design, and how much leeway they allow the OEMs in implementing security. On WM 6.x, as an OEM, you could get a device licensed and certified without implementing 90% of the security features microsoft designed. They left most of that up to the OEM to implement. But in WP7 the design is very strictly regulated, because they realized that the holes we are exploiting to flash custom roms on WM 6.x devices, are nearly all vulnerabilities in the OEM’s implementation of security. So far none of the MSFT implemented security protocols have yet been cracked (probably more due to the lack of need, due to there being easier ways to do it, like attacking the OEM security code)
This is going to make it extremely tough to get “superuser” access at first. But similarly to rooting on the android platform and jailbreaking on the iphone platform, the security revolves around the superuser concept so it’s the only barrier to access. With one sticking point…
3) Will it be possible to side-load apps, etc?
This will probably be the easiest thing to get going at first. There are many methods of ingress in this scenario, anything from the bootloader, to the kernel, on up to the code used for extracting/validating signatures, to the app store itself could have a hole to be exploited that will bypass the normal security checks. The ability to side-load along with most other security restrictions are controlled by simple settings in the registry any Windows “Power User” would be familiar with.
Thoughts, Comments, etc…
A major concern for any modification done to an existing WinMo device is “Xbox Live” and “Cloud Services” eligability and connectivity. Nearly all the major functions on the device operate by shuttling data to and from the “cloud”, presenting different methods to the user for getting their data on to the device. However as these services interact quite a bit with Microsoft’s own servers, they have considerably beefed up the security in this area. Each device contains a “Device Provisioning Partition” or DPP that contains a unique certificate assigned to the device at the factory. Each certificate is verified locally by the device in several places, and also uploaded and verified by the “Cloud” for each transaction. Loading Windows Phone 7 on to a device that did not originally come with the platform would result in having an invalid certificate, and these services will not function properly.
I’ve seen evidence that Microsoft is invested heavily in the platform, and bringing updates to the table soon. There are already several branches of code in concurrent development (those who followed the WM 6.5 and 6.5.x development cycles will be familiar with how many code branches Microsoft works on at one time, with different features or fixes in each, later merged together into a “Mainline” branch)
Somewhere down the line, Microsoft intends to support limited access to Native Code for third party developers (OEMs like HTC, LG, etc. already have access to many of these methods.) The more native code we’re allowed to run the more likely we can find a “way in”, if we still haven’t gotten there by that time.