Message Boards


All times are UTC - 5 hours




 [ 1 post ] 
Author Message
 Post subject: Obfuscated your WP7 app and now it won't run?
PostPosted: Fri Dec 17, 2010 11:15 am 
Site Admin

Joined: Thu Jun 24, 2010 11:44 am
Posts: 4

Here is a quick set of steps with some supporting info to step a developer through the diagnostic process of figuring out why an app won't run after being obfuscated... Note, the cause of this is almost always connected in some way to renaming (but not always - that would be too easy).

Renaming absolutely is supported on the phone, with Silverlight, XNA, etc. - but some accomodations are often required. Hopefully, this takes some of the "black art" out of the process. Comments, corrections, or suggestions are all welcome...

This post is divided into two parts;
1. A quick list of diagnostic steps a developer can take to quickly identify and remediate runtime errors.

2. A quick list of diagnostic steps a developer can take to quickly identify and remediate build errors.

(Another) Note: Renaming defeats human inspection. Renaming is not necessary to defeat Reflector – use control flow settings to accomplish this. Control flow has very few side-effects and is not impacted by reflection inside your code.

DIAGNOSTIC STEPS (please review the user manual if the instructions below are not clear)

Answering the following questions in order should lead to the quick identification and remediation of any configuration steps required to successfully get your Windows Phone 7 application built and running with the optimal degree of obfuscation.

RUNTIME ERRORS

As I have already said, runtime errors are almost always associated with renaming. If you do not think that you have renaming turned on (if you just want to do instrumentation or code flow for example), please verify that this is indeed the case.

If you are intentionally renaming, check the following:

- Are all 3rd party assemblies marked as artifacts? Renaming 3rd party assemblies can have unpredictable results and may violate their EULA. If not, move them into the Artifacts path.

- Are you using the latest version of Dotfuscator for Windows Phone? Be sure to check both the SKU (for Windows Phone) and the version. We are continuously improving XAP parsing, etc.

- Is the application signed and/or resigned properly? If the application was originally signed, then a delayed signing and a resign is required.

- Now, determine which transform is causing the problem.
o Does the runtime error reproduce if all obfuscation transforms are turned off? This is extremely rare and should be reported to PreEmptive support.
o Does your app work with Library Mode enabled on all input assemblies? If yes, disable Library Mode and answer the following…
* Does your app work with Transform XAML turned off on all input assemblies? If yes, you have now probably achieved a fairly high level of renaming including most, if not all, of your business logic.
- If you want to identify specific methods to exclude, it is helpful to consider the following potential issues:
 Dependency Properties – are the properties and all backing methods excluded from renaming?
 Does the app work with the Property Exclusion Catch-All custom rule?
<type name=".*" regex="true">
<propertymember name=".*" regex="true" />
</type>
- Are all of the warnings on the Warnings tab (generated at build time) accounted for? If not, manually exclude the items that have been flagged.
- Catch runtime exceptions and display them in a messagebox to see what is actually going wrong.

BUILD ERRORS

These first two points are the same as with Runtime Errors above...
- Are all 3rd party assemblies marked as artifacts? Renaming 3rd party assemblies can have unpredictable results and may violate their EULA.
- Are you using the latest version of Dotfuscator for Windows Phone? Be sure to check both the SKU (for Windows Phone) and the version.

- Is Dotfuscator unable to find a reference assembly?
o Run from command line with /v /e /bindlog=true for additional info about where Dotfuscator is looking. Add appropriate paths to the User Defined Assembly Load Path.
- In the case of Dotfuscator errors, get a Dotfuscator stack trace by running from the command line with options: /v /e Send the resulting stack trace to PreEmptive support.

I hope this helps a few of you out there - again - if you have any additional diagnostics that we should add or corrections to suggest - please do so - its much appreciated. *AND thanks to Dave P who put most of this info together!



Top
  
 
Display posts from previous:  Sort by  
New Topic | Post Reply  [ 1 post ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron