Dell Venue Pro – Working With The Native Layer
I spent some time trying to better understand of the Dell Venue Pro software internals.
By Den Delimarsky in Hackery
June 25, 2011
Each Windows Phone OS – powered device has its own way of communicating with its hardware. In a non-public environment, this is done through a COM (Component Object Model) layer. A DLL providing this layer is usually shipped as a part of the OS or an official OEM application. When it is distributed the second way, it is fairly easy to intercept the XAP and extract the DLL. And that’s when the experiments begin.
Dell provides probably one of the less popular Windows Phone devices. Nonetheless, Dell Venue Pro has more than decent hardware parameters and it is quite fun to see how those can be leveraged in an application built with bits outside the official SDK.
OurCOM.dll
Image lost since transition to new blog
It all starts with OurCOM.dll
– the library that is shipped by Dell as a part of their EM (Engineering Mode) application. Unlike their competitors from Samsung and LG, the default application is written quite poorly and all interactions with the COM layer are done through plain-text commands that are later parsed to get correct values. Quite an interesting (unusual and unusable?) choice, but if that’s all we have, there is no choice.
WARNING: Before going any further with the experiments described in this article, remember that by using the presented code snippets you might:
- Brick your phone
- Erase all content present on the device
- Render the phone un-usable for unknown periods of time
That being said, I am assuming no liability or responsibility for any of the actions you undertake with your Windows Phone device while following my instructions in here.
The library itself should be added to the Windows Phone application project you plan on working with. In my case, it is set to Content and Copy Always – obviously it is not going to be a standard reference because of the platform restrictions.
Preparing the application
Also, WPInteropManifest.xml
is needed in order to enable interop calls. Its contents are pretty basic:
|
|
Don’t forget about the proper CAPs in WMAppManifest.xml
:
Image lost since transition to new blog
ID_CAP_INTEROPSERVICES
is crucial for any COM interop code to work. Last but not least, you will need Microsoft.Phone.InteropServices.dll
for ComImport
to be available. You can get to the library via Reflection or you can download it as a part of the dumped GAC here.
COM Connection Fundamentals
First, the default program components (read: classes and interfaces):
|
|
These are parts of the default connecting code used in the EM application. I modified it a bit for proper naming and more readable results (at least it will be possible to know what’s going on). EMToComByDriver
seems to be the connecting class that works. There is one that relies on sockets, but it appears that developers forgot to properly integrate it so it fails to actually do anything on the phone.
A lot of the code above is dedicated to parsing commands and COM responses. I am not entirely sure why the guys that wrote the COM DLL didn’t want to use direct function cross-invocation, but alas – I have no real choice here. At least right now.
In my application, I am creating an instance of ICOMConnector
and instantiating a new EMToComByDriver
that is assigned to the interface when the page is initialized:
|
|
The call to Connect
actually invokes the COM registration process and stores the current instance of the COMInteropClass
for later reuse. It is time to learn more about commands now!
String commands
REGISTRY
One of the gray areas on a Dell Venue Pro device is the registry. The problem is – apparently, there is no hook in the native DLL that allows modification of the system registry (although an obvious attempt to link it is there). That being said, to get a registry key, a command like this can be sent:
|
|
The command itself has the following format (in case commas make it difficult to read):
|
|
Here is yet another interesting (and inexplicable) decision – use integer identifiers for key stores instead of direct paths. The ending integer is nothing else but a way to show what is the source of the actual key you are trying to get. These are:
HKEY_CLASSES_ROOT
– 0HKEY_CURRENT_USER
– 1HKEY_LOCAL_MACHINE
– 2HKEY_USERS
– 3
REG_SZ
defines the key type to be read and it pretty much determines the value type. These can be:
REG_DWORD
REG_SZ
REG_MULTI_SZ
REG_BINARY
The SET
command works the same way, but with an included value to set:
|
|
The response (instance of Result) is not informative:
Image lost since transition to new blog
Considering the values that are seen in the screenshot above, it is safe to assume that the SET
command is not implemented in the native layer.
IDEA TO WORK ON: A way to push and execute REG files (like it is in regular Windows systems) to update the registry values.
WORK MODES
These define whether the phone works in Composite or Zune mode. The Composite mode is usually necessary to set the phone up for tethering. Zune mode is the default work mode that allows the phone to be synced with the PC and updated.
The command to set the phone to Composite mode:
|
|
To switch back to Zune mode:
|
|
Once again proves that the values send back and forth are quite cryptic, but they work.
NOTE: Once you invoke one of the commands that causes the work mode to be changed, the phone will automatically restart.
SECOND NOTE: You will not be able to read the Result returned by the COM invocation once the command is triggered.
Make sure that you will have access to the mode-switching application once the phone reboots. You might need to switch modes back eventually. If not, you can always use the default EM app that cannot be removed without significant effort.
Feedback
Have any thoughts? Let me know on Twitter!