Take a look at Crypto Obfuscator - it supports obfuscation of F# assemblies.
[link:www.ssware.com]

By on 4/25/2012 4:22 AM ()

This depends on why you're obfuscating. I've seen little to no reason for any product to be obfuscated, and have only run into issues with providers who choose to take that direction. If it's just so some "average" worker at an office can't as quickly dump C# out of your DLL, F# already takes care of that - compilation often generates code that doesn't look exactly like source. If you need more "protection" than that, you probably shouldn't give the assemblies to attackers.

By on 7/23/2009 9:21 AM ()

What an interesting reply.

You clearly come from a completely different world than I am familiar with.

I simply can't imagine anybody giving assemblies to attackers.

By on 7/23/2009 3:32 PM ()

"I simply can't imagine anybody giving assemblies to attackers."

Maybe I misunderstood you. Isn't that the supposed point of obfuscators in the first place? To "prevent" attackers from playing with your assemblies? If attackers never get them, then where's the need for obfuscation? If your assembly has your special super-secret algorithms you can't have people disassembling, don't ship it out to customers or people who want to attack it - keep it on your server.

By on 7/23/2009 3:58 PM ()

You certainly did misunderstand.

This is the problem with these fora. Can't live with them can't live without.

I don't feel it's a great idea to go into unnecessary detail on what's happening, but I'll take that time now.

Firstly, you may think you have super secret algorithms, I don't think that way. Though I don't intend to help somebody who has no idea about programming or save a competent programmer months of work!

The situation I'm pondering at the moment is deploying work on a third party hosted web site. The code (compiled or source) is not distributed.

I'm assuming that when F# goes public with the next iteration of .NET this will be fairly easy to do. (Just the usual problems with assemblies, WCF, precompiled sites...)

I monitor some instrumented web sites and have seen the attempted attacks even on sites that fly below the radar. It's better to be safe than sorry and use protection if it's sane and sensible to do it. I have my doubts about sane and sensible though, when it comes to obfuscation.

I've had an interest in obfuscators since before .NET went live. A very mixed bag and there are issues, so I'm after real experience from people who have know what they are talking about.

The ideal is a process that once developed simply gets incorporated into the build and that the developer doesn't really notice.

So back to the issue in hand.

What experience do the citizens of this forum have about obfuscating F#?

Have you got it to work?

What are the issues?

What are the pitfalls?

For those who aren't familiar with this area there is a "work in progress" page about .NET obfuscators at [link:en.wikipedia.org]

A rudimentary look at one of the 33 or so listed there will often show why that product is wrong for you.

A note on whether code is worth obfuscating. A lot of code on the web is wizard generated glue code, moving stuff into and out of databases, little transformation. I see F# as a breath of fresh air, a chance to do some really valuable work with all those CPU cycles. A bit like the difference between writing APL and writing glue-UI code. I hope, that power will soon to be within the easy grasp of those who want to use it. That sort of thing is worth protecting (even where you think the chance of somebody getting hold of it is small).

By on 7/23/2009 4:57 PM ()

Well, I guess I just don't know what "protection" is then. Maintaining a decompiled program is a lot of work. Someone with "no idea" isn't going to be able to do much, obfuscated or not. Even for experienced programmers, wholesale copying lots of code via decompilation is a lot of work. Again, F# is even more work, especially with options like static linking.

Is the threat that someone might take the app, modify it to say their name and logo, etc. and sell it as their own? In this case, obfuscation is going to be a minor obstacle -- anyone in position to do all the reverse engineering in the first place probably won't be stopped. In the end, you'll end up pursuing legal methods to resolve the problem.

Last time I dealt with obfuscation, it was because a commercial company had obfuscated one of their products. The commercial obfuscator they used thought it was cool to screw up the IL and metadata to make it harder to decompile. Result? It would just crash on Mono. Fix? A 20 line F# script that just went through and renamed everything and removed the bad IL. That company decided to stop obfuscating their assemblies. I guess I just don't see what gets "protected" by running an obfuscator.

At any rate, to help answer your question, if you stick to basic, non-problematic obfuscation features, like basic renaming, you should be fine. At least, I haven't seen any case where the F# compiler emits some dynamic lookup based on type or member names. So, for example, you could write an F# script with the Cecil library to go through and rename every type to some increasing value (t1, t2, t3...). And quite frankly, I don't see much value in any more "advanced" techniques (like converting ref types to object, overloading to the same name, etc.) -- they're just asking for trouble, and anyone who puts up with renamed identifiers will work through those, too.

By on 7/23/2009 5:58 PM ()

Hi MichaelGG.

It's very impressive what you did with VistaDB. I'd be interested to know what obfuscator they used.

I suspect that faced with your talents much obfuscated code might be a fairly open book.

There is a good chance though that the bad guys aren't so competent.

I wasn't originally thinking of writing my own obfuscation. I'll give your points some thought. I'm planning ahead and have some time.

By on 7/24/2009 3:25 AM ()

No not really impressive at all - Mono's Cecil library is just excellent and makes short work of managed code. It's not a matter of talent anyways - it's a matter of resources. If the application is worth anything, then it'll be opened. Look at the $50,000 3D packages of the 90s, or just drop by a certain Swedish torrent site.

Sure, reflector has plugins that make making changes easy. Sure, you can get the source out, and if you use C#, it'll look a lot more like your source. But, try pulling out Hex Rays on compiled C. With that, making patches is far from difficult.

Either way, I don't see the worry about people lifting code wholesale and stealing months of work. The code is just not that maintainable. Even in C# -- try reflector on an iterator. That code gets totally blown away. No doubt, Reflector'll get better, but F#'s generated code is even more different from your source.

All this, and then you get crap stack traces on top? No thanks.

But anyways, myy point was that so long you stick to simple obfuscators, you should be fine. Like, I saw in that list some free ones that use Cecil and just go around renaming things. If you insist on obfuscating, they'll mess things up enough to make maintenaince of decompiled code really impossible, while not screwing with enough stuff to cause problems beyond reflection.

In IL, the names are almost irrelevant. Everything is given a reference anyways, and that's what's in the IL stream. Last time I checked, you could simply overwrite all the identifiers with "x" and things would still execute just fine (although it won't PEVerify).

By on 7/24/2009 9:14 AM ()

Either way, I don't see the worry about people lifting code wholesale and stealing months of work. The code is just not that maintainable. Even in C# -- try reflector on an iterator. That code gets totally blown away. No doubt, Reflector'll get better, but F#'s generated code is even more different from your source.

Agreed. Someone wanting to steal a significant portion of code from reflectored F# code is going to have to put in as much effort as for writing the code from scratch. The more functional you get, the harder it gets to decypher. Add in some  simple name-mangling and I wouldn't worry too much.If on the other hand you want to prevent someone from circumventing your copy-protection or some such by patching the assemblies, then it's just a matter of how much resources you're going to want to put in, and how much resources your attackers are willing to put in.Anyway, I don't think there is much obsfuscated F# code out there - simply because there are only a few distributed commercial applications that may need obfuscation. (this will no doubt change, at which point obfuscators and other tools will catch up.)

By on 7/25/2009 10:18 AM ()

Even for experienced programmers, wholesale copying lots of code via decompilation is a lot of work. Again, F# is even more work, especially with options like static linking.

It's not really that hard work. Long story, but one of my friends recently decompiled his own code via reflector, made some changes, and compiled again. There are reflector plugins for this kind of stuff.

Anyway, to answer the question. I have no experience with code obfuscation in particular, but I have had some experience with other kinds of tools that do program transformation or inspection at the IL level.

My guess is that you will run into unexpected problems - although in theory the IL should be the same, all these products have been tested with is C# and VB, and the F# compiler produces significantly different IL structure. I wouldn't trust it at the moment, or expect to do a lot of testing before putting it out there.

By on 7/24/2009 2:39 AM ()

You're right Kurt.

Decompiling via reflector is very easy. You can go directly to code in the available languages in a few seconds.

A real shock is to look at your own assemblies, and be confronted by something that is very close to your source. It makes you think.

Like you I suspect that F# might be an unexplored land for the tools.

I'd be surprised though if somebody in the F# community hadn't tried it on a real job.

By on 7/24/2009 3:05 AM ()

A real shock is to look at your own assemblies, and be confronted by something that is very close to your source.

The only reason to be shocked about this is if you had expected more optimization from the compilation to IL. Apart from that question I'd be shocked if what the compiler outputs doesn't reflect what I wrote, not if it does.

By on 7/24/2009 9:36 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper