.Net Obfuscators - any tips?

K

kepler

New member
I need to have a look at some obfuscators, does anyone have any tips from personal experience?

I've requested a trial of DotFuscator but they're one of the "call us for the price" companies so I'd rather avoid them if at all possible.

Any pointers appreciated. :up:
 
I've found a list here, I'll have a look through these but again, any personal experience or thoughts are appreciated. :up:
 
Most of my .NET code has been on closed back-end systems so I haven't had any experience with these tools. I'd be interested in hearing what you discover. Most people don't realize that .NET compiles to an intermediate language (IL) that is extremely easy to reverse engineer.
 
Well I've been looking at them on and off for a couple of days. VS .Net 2003 ships with a lite version of DotFuscator if anyone wants to have a play, you can also get one from Macrobject. To decompile the exe/dlls you can get a free version of Xenocode Fox from their site.

It looks like it's certainly useful, but possibly only in certain circumstances. It seems to have issues with remoting and reflection so it may only be possible to apply it to certain parts of the code (e.g. licencing, security) but that imo puts a bit of a bullseye on those areas anyway.

If the issues with remoting could be resolved it would be really useful for me, but I don't think they can.

A case of back to the drawing board on this one I think.
 
Out of interest, this is what it makes of a load tester. Decompiling this without obfuscation basically gives you the project and naming structure you'd see in the IDE, obfuscating it (with Dotfuscator, I think) gives

obfus.jpg
 
What do you want it to do then? Insert random ****s of code that do nothing, but degrade performace, so that someone will be less likely to figure out your code? :rolleyes: :D
 
Tisti said:
What do you want it to do then? Insert random ****s of code that do nothing, but degrade performace, so that someone will be less likely to figure out your code? :rolleyes: :D
Click to expand...
Junk code doesn't have to degrade performance does it? The only performance hit that I've read of is encryption, and even that's minor.
 
SD-[Inc] said:
That isn't as obfuscated as I would have hoped???
Click to expand...
Well it's better than the decompiled original code but still definitely possible to re-engineer, yes. You can improve it with string encryption and I would imagine with more severe control flow obfuscation. You can also choose to compile it properly I think, but that restricts it to a specific architecture.

I hinted earlier that it has problems with reflection and such but it's worth mentioning that on some obfuscators you can have it ignore those extra-sensitive areas so it still works.
 
Nothing wrong with VB.NET. In fact, if you started .NET developement with VS 2001/2003, the IDE features available for VB were superior to C#. But since 2005 C# has caught up and even passed VB with 2008.
 
SD-[Inc] said:
Nothing wrong with VB.NET. In fact, if you started .NET developement with VS 2001/2003, the IDE features available for VB were superior to C#. But since 2005 C# has caught up and even passed VB with 2008.
Click to expand...

Exactly. We didn't start using C# until 2005 (.net 2) was released.
 
You must log in or register to reply here.
Back
Top