Earlier today, we reported on a Windows Phone Store weakness allowing savvy users to download Nokia-exclusive applications onto non-Nokia hardware (well, try to at least, as often those apps are API dependent). But we did a little more digging and discovered the weakness doesn't just cover Nokia apps. You can manipulate the Store into providing any device or operator-exclusive app for your device.
The root cause appears to lie in the fact that the Store makes app metadata and availability decisions based on URL query parameters that are sent via HTTP and can easily be tampered with. For example, when viewing Samsung’s exclusive RSS Times app a Nokia device, your Windows Phone makes a request similar to the one below:
GET /v8/catalog/apps/e7fd6b61-a095-4b06-9fba-005cc9b09267?os=8.0.10211.0&cc=US&oc=&lang=en-US&hw=234879123&dm=RM-820_nam_canada_246&oemId=NOKIA&moId=TRF-US&cf=99-1 HTTP/1.1
Upon receipt of this request, the Store responds with a bunch of XML-formatted data describing the requested app. One of the elements in the reply – isAvailableInStore – controls the visibility of the Install button in the Store app. In this case, because we told the Store we’re using a Nokia-branded device (see the oemId parameter?), a Boolean false is returned. The Install button is disabled; we can’t install the app.
But what if we replaced that oemId value with say, SAMSUNG?
Using the Fiddler Web Debugger and a simple AutoResponder rule, we successfully spoofed a Samsung Windows Phone and installed RSS Times with no problems.
It’s not immediately clear how Microsoft will respond to this issue. We suspect Microsoft can remotely reconfigure Store app behavior, forcing communication through more secure means (e.g. HTTPS). But an increasingly chatty Store app on Windows Phone could impact Store performance and/or incur additional bandwidth costs on both ends of the pipe. We'll see.
Stay tuned and we’ll let you know what we hear from Microsoft.
