Red Gate forums :: View topic - All method names and fields in DLL are not obfuscated
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SmartAssembly 6
SmartAssembly 6 forum

All method names and fields in DLL are not obfuscated

Search in SmartAssembly 6 forum
Post new topic   Reply to topic
Jump to:  
Author Message
javiersanag



Joined: 27 Sep 2012
Posts: 4

PostPosted: Thu Sep 27, 2012 3:09 pm    Post subject: All method names and fields in DLL are not obfuscated Reply with quote

Hi!

I'm trying to obfuscate a DLL that contains some WPF and some public methods. On these classes, all method names and signatures remain intact, even when they are internal or private. Also, all fields keep their original name. I have set all options to maximum obfuscation.

I have also tried this solution: http://stackoverflow.com/questions/6863759/smartassembly-skipping-obfuscation with the "ExcludePublicMembers="0"" parameter.

Nothing has worked so far. Any way I can force field name mangling on private and internal methods and fields?

PS: I'm using ILSpy to disassemble the DLL.
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 182

PostPosted: Fri Sep 28, 2012 8:14 pm    Post subject: Reply with quote

It looks like something changed in the latest version of SmartAssembly that makes that workaround

<Obfuscation ExcludePublicMembers="0" Obfuscate="1">

invalid, I'm afraid. I've opened a bug for this with reference SA-1389 .


In the meantime, you could downgrade to version 6.6 which I've found still works: http://downloads.red-gate.com/checkforupdates/SmartAssembly/SmartAssembly_6.6.4.95.exe

Sorry for this inconvenience!
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
javiersanag



Joined: 27 Sep 2012
Posts: 4

PostPosted: Mon Oct 01, 2012 3:00 pm    Post subject: Reply with quote

Thanks for the reply. Unfortunately, I get the same behavior with version 6.6, even after specifying "ExcludePublicMembers = 0".

All my DLLs are merged into the main assembly, so I don't understand why they are not obfuscated in the expected way. It is especially worrying that the internal and private members keep their original names. Even the main .exe file has most private and internal members unchanged after obfuscation (this I don't understand why).

I hope something like this can be solved in the next version of SmartAssembly.
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 182

PostPosted: Tue Oct 02, 2012 8:37 pm    Post subject: Reply with quote

Yes, that is strange. SmartAssembly does purposely skip obfuscation of certain types though -- are those objects that aren't getting obfuscated any of the following?

Any type with the Serializable attribute specified will not be obfuscated
Any type with a base class of System.MulticastDelegate will not be obfuscated
Any type with the System.ServiceModel.OperationContractAttribute specified will not be obfuscated
Any type with the System.ServiceModel.ServiceContractAttribute specified will not be obfuscated
Any method with the System.Reflection.DefaultMemberAttribute specified will not be obfuscated
Any type with an attribute starting with System.Xml.Serialization. set will not be obfuscated
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
javiersanag



Joined: 27 Sep 2012
Posts: 4

PostPosted: Thu Oct 04, 2012 12:55 pm    Post subject: Re: Reply with quote

jessica.ramos wrote:
Yes, that is strange. SmartAssembly does purposely skip obfuscation of certain types though -- are those objects that aren't getting obfuscated any of the following?

Any type with the Serializable attribute specified will not be obfuscated
Any type with a base class of System.MulticastDelegate will not be obfuscated
Any type with the System.ServiceModel.OperationContractAttribute specified will not be obfuscated
Any type with the System.ServiceModel.ServiceContractAttribute specified will not be obfuscated
Any method with the System.Reflection.DefaultMemberAttribute specified will not be obfuscated
Any type with an attribute starting with System.Xml.Serialization. set will not be obfuscated


We're not dealing with any of those types. I have activated the logging functionality, and I get many of these messages:

class [PresentationFramework]System.Windows.Controls.Grid GridClose excluded from obfuscation: Has a special base type ([PresentationFramework]System.Windows.Window)

Is WPF not supported?
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 182

PostPosted: Fri Oct 05, 2012 7:19 pm    Post subject: Reply with quote

Oh, I see--SmartAssembly does support WPF, but it will automatically skip obfuscation of some objects in a WPF assembly, I'm afraid. Sad It does this to make sure that the obfuscated version of your application will still work with your xaml file. Are all the objects getting skipped related to WPF?
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
javiersanag



Joined: 27 Sep 2012
Posts: 4

PostPosted: Tue Oct 09, 2012 10:19 am    Post subject: Reply with quote

Most of the classes that are not obfuscated derive from Window or from UserControl, so they are indeed related to WPF. In these classes none of the method names or field names are modified after obfuscation, and for instance, a simple private boolean keeps the name. Is this the expected behavior?

It seems that SmartAssembly has important limitations with WPF (maybe Microsoft's fault). Behavior like the one described above means that we need to move most of the logic to other non-WPF classes, but in many cases this is either not possible or it complicates code in an unnecessary way...
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 182

PostPosted: Wed Oct 10, 2012 8:13 pm    Post subject: Reply with quote

Hi Javier,

I've come across a comment that the developers have made in regards to exclusions. Apparently, exclusions can vary depending on a whole host of factors such as the type of assemblies being processed, which combination of other features may be enabled, the CLR version being targetted and more. I apologize for any inconvenience this may cause!
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 182

PostPosted: Fri Oct 19, 2012 4:32 pm    Post subject: Reply with quote

Hi Javier!

So, it turns out that the actual problem here is that I was having a moment of stupidity..Embarassed

In version 6.7, the attribute is now KeepPublicMembersAccessible rather than ExcludePublicMembers

My deepest apologies for the confusion!
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
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
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group