<Martani/> Blog

The folks over xda are doing a great job with all the new Windows Phone 7 hacks, but it seems that the HTC devices are the ones getting all the fun there.

For instance, the member xboxmod have found a way to install provxml on WP7, and hence total access to the registry, which allowed them to change the WP7 themes with custom colors, disable relocking the phone once unlocked with ChevronWP7 and a lot of other stuff.

On the other hand, a lot of the member have been asking if there is a way to do so on Samsung devices (Omnia 7 and the Focus). While we have access for read/write on the registry for Samsung devices, it is so limited compares to the provxml method on HTC devices.

I developed a simple app showing how to write the registry using the Samsung native DLLs, so hopefully some guys will pick this up till we come up with a full functioning method to manage the registry on Samsung Devices.

This is the link to the application (the XAP file with the source code), you find in the same thread a homebrew registry viewer too which allows the traversal of registry keys.

Happy hacking!

I worked lately on a simple application in OCaml that compresses files using the Huffman compression algorithms. The application is a showcase of how to use the Huffman’s Static compression, decompression algorithms compared to the dynamic (adaptive) algorithms (Vitter algorithm is used in the application).

The source code is available on github here https://github.com/martani/Huffman-compression--OCaml-. Although the code is not as elegant as it should be, we have used excessively the imperative features of OCaml for optimization reasons, especially for the adaptive algorithm where the tree changes with every introduction of a new symbol to code. So it is not really the best place for OCaml beginners who should be baptized with the functional beauty of the language before they see its evil imperative side :).

Although, It might be a great place too to see how the imperative and functional programming could be done on the same land, I don’t promise anything though, since we did the project in the hurry with just few days in our hands to prepare for exams and … you know the rest of the story.

So the project uses only the primitive OCaml modules, there is no libraries to install or anything, there is also an associated Makefile to compile and test the executable.

The Makefile has a make test directive to test the executable on a file named ”input” in the working directory (that you should include yourself obviously), basically it stars a static compression followed by a decompression then compares the original and the decompressed files to ensure the program works correctly. It does the same with the dynamic method too.

On a side note, we were surprised that while compiling the code with ocamlopt, we get sometimes programs that run 15x times faster than the same program compiled with ocamlc.

For a file about 5.8 MB we got some executing time around

   1: ***@****-Studio-1558:~/workspace/huffman$ make test

   2:  

   3: Testing... static huffman

   4: Compress:

   5: 1.18 user 

   6: 0.00 system

   7: 0:01.19 elapsed 

   8: 99% CPU (0avgtext+0avgdata 5504maxresident)

   9:  

  10: Uncompress

  11: 2.26 user 

  12: 0.00 system 

  13: 0:02.27 elapsed 

  14: 99% CPU 

  15: <<<<<<<<<<<<<<<<Compressed = Uncompress ??>>>>>>>>>>>>>>>>

  16:  

  17: Testing... dynamic huffman

  18: Compress

  19: 8.11 user 

  20: 0.01 system 

  21: 0:08.13 elapsed 

  22: 99%CPU 

  23:  

  24: Uncompress

  25: 4.04 user 

  26: 0.00 system 

  27: 0:04.05 elapsed 

  28: 99%CPU 

  29: <<<<<<<<<<<<<<<Compressed = Uncompress ??>>>>>>>>>>>>>>>>>

As you can notice, the static version of the program is faster than the dynamic one, this is due to the fact that we optimized the the static version to use actual bits on compression / decompression, but we used lists to represent the bits (0’s and 1’s as actual 32 bit integers!!), so that was expected.

Link for the source code : https://github.com/martani/Huffman-compression--OCaml-

This is a short post showing how to read IMEI (and other stuff if you want to walk alone over the code) on Samsung devices running Windows Phone 7.

This simple code uses the Samsung native DLLs for Windows Phone 7, so they (surely?) won’t work on LG or HTC devices.

Requirements:

If you are new to WP7 hacking, you may need some research on how to get started executing native code calls on Windows Phone 7, here are the requirements in a quick recap:

• a  <Capability Name="ID_CAP_INTEROPSERVICES" /> inside the <Capabilities> tag in the WMAppManifest.xml file.
• a WPInteropManifest.xml file in the root of your solution containing:

     1: <?xml version="1.0" encoding="UTF-8"?>

     2: <Interop>

     3: </Interop>

  
  
• The Samsung native DLLs, a hint for where to find them? Hack the Marketplace, or just download them from here :D
  
• A reference to Microsoft.Phone.InteropServices.dll, you can grab it from here and then add it to the Windows Phone 7 SDK.
  
• In case you forgot to strong name the DLL above, here’s the last step you need (the Visual Studio command prompt must be started with admin rights)
  
  
  

     1: SN -Vr "PATH-TO-DLL\Microsoft.Phone.InteropServices.dll"

Code :

   1: public partial class MainPage : PhoneApplicationPage

   2: {

   3:     // Constructor

   4:     public MainPage()

   5:     {

   6:         InitializeComponent();

   7:         this.Loaded += new RoutedEventHandler(MainPage_Loaded);

   8:     }

   9:  

  10:     void MainPage_Loaded(object sender, RoutedEventArgs e)

  11:     {

  12:         

  13:         ComBridge.RegisterComDll("COMRilClient.dll", new Guid("A18F6B1A-924E-4787-AA82-19F98B49CF5D"));

  14:         COSecRilControl cls = new COSecRilControl();

  15:         ISecRilControl intrfc = (ISecRilControl)cls;

  16:  

  17:  

  18:         //READING THE IMEI

  19:         string imei;

  20:         intrfc.GetIMEI(out imei);

  21:     }

  22: }

  23:  

  24: [ComImport, Guid("A18F6B1A-924E-4787-AA82-19F98B49CF5D"), ClassInterface(ClassInterfaceType.None)]

  25: public class COSecRilControl

  26: {

  27: }

  28:  

  29: [ComImport, InterfaceType(ComInterfaceType.InterfaceIsIUnknown), Guid("A5857C17-04C2-49c5-A460-05A21660588F")]

  30: public interface ISecRilControl

  31: {

  32:     void Init();

  33:     void Deinit();

  34:     void Run(int mode);

  35:     void End();

  36:     void SetInput(int type);

  37:     void Back();

  38:     void GetDispInfo(out uint svcMode, [MarshalAs(UnmanagedType.SafeArray)] out byte[] info);

  39:     void GetEvent(int type, out int pEvent);

  40:     void SetEventCOM(string name);

  41:     void LaunchExe(string exe, string arg);

  42:     void DoHiddenKey(int hashcode);

  43:     void GetLockingStatus(out uint m_dwLockFacility, [MarshalAs(UnmanagedType.SafeArray)] out byte[] pPasswd);

  44:     void SetLockingStatus(out uint m_dwLockFacility, string data, out uint m_dwStatus, [MarshalAs(UnmanagedType.SafeArray)] out byte[] result);

  45:     void GetIMSI(out string IMSI);

  46:     void GetIMEI(out string IMEI);

  47:     void DoHiddenKeyWithResult(int hashcode, out string jobName);

  48:     void WaitNamedEvent(int timeout, string name);

  49:     void RegSetDWORD(uint HKEY, string pwszPath, string valueName, uint value);

  50:     void RegGetDWORD(uint HKEY, string pwszPath, string valueName, out uint value);

  51:     void RegSetString(uint HKEY, string pwszPath, string valueName, string value);

  52:     void RegGetString(uint HKEY, string pwszPath, string valueName, out string value);

  53:     void ReadTextFile(string path, out string result);

  54: }

This is a great read about Windows Phone 7 hacking [link].

As promised in part 1, here is the rest of the Samsung diagnosis codes for Windows Phone 7. If you don’t know how to use them, refer to part 1 for more information.

Lately I have been working on some hacks for the Windows Phone 7, and was interested especially in the Samsung diagnosis app that uses different codes to debug their devices.
I’ve succeeded to extract more than 60 codes that I will show in this post and the next one, and their basic functionality/use in the diagnosis app.
The following codes were tested on a real Samsung Omnia 7, I’ll be happy if you can confirm their use on other devices as well.
To enter the diagnosis app, type ##634# and press call, the application should now be placed on the list of apps.

A while back Microsoft sent some warning emails to the registered Windows Phone 7 developers about the threats their apps might face once published on the Marketplace. The apps on the Marketplace are available for download without any authentication required. What you need to get an app is simply the direct link to the .xap file, something of the form http://apps.marketplace.windowsphone.com/app-guid-here/CurrentBinary.xap, which contains the DLL that can be disassembled very easily with Reflector for example. More info here.

Here’s an excerpt from the email :

It is important to note that because of the leak containment steps Microsoft takes applications obtained outside of Marketplace will not run on consumer retail devices. Modified files would only run on a limited number of “unlocked” phones, such as those that have been registered by Marketplace developers on App Hub….

One powerful tool for protecting your apps and games is code obfuscation, which is a long standing best practice for managed code. Obfuscation is available tools like the Dotfuscator product recently announced for Windows Phone 7 applications. Microsoft has partnered with PreEmptive Solutions to make this tool, as well as a robust application analytics solution, available to Windows Phone developers for free through March 31st, 2011.

Right now, it seems that the only option to protect your app, is to use a code obfuscator, since anyone is allowed to download it from Microsoft servers without any restriction, whether they are using a real Windows Phone 7 or they are sniffing the traffic made by the Zune software (yes, I’m not going to tell you how to do it! you need to figure it out yourself).

For demonstration purposes, here is what Reflector shows when applied on an obfuscated DLL and on a non obfuscated one:

1. Obfuscated

2. Clear

As you can see, on the obfuscated version, Reflector shows either a message saying that the code was obfuscated and it cannot be disassembled, or a bunch of unreadable variable names with a lot of “goto” instructions.

On the other hand, the non obfuscated version is disassembled to (almost) the original source code, only the comments are missing.

Last word, if you are developing anything for Windows Phone 7, do not forget to obfuscate your code before publishing your app on the market.