Need good obfuscator that won't break remoting...
-
Anyone have good experience with a particular obfuscator that still allows remoting (binary serialization)? A large part of the fields/properties can't be mangled because of this, and also because of the .NET data binding, which needs the property names to remain intact. Right now I'm considering CodeVeil (gonna try that one tomorrow), because it at leasts encrypts the assembly, so I don't have to worry as much about the field/property names not being mangled.
Wout
I've tried a lot of different ones. XenoCode and SmartAssembly seem to be up there, but I still run into problems with those, just not as many as some other obfuscators. Perhaps you will have better results. After a few years of this stuff, I'm convinced obfuscation generally is a big hack designed at the wrong level.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Minnesota Bridge Collapses The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
I'll gladly beta test the Windows Gravity Eliminator for you. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Mark Salsbery wrote:
After a few years of this stuff, I'm convinced obfuscation generally is a big hack designed at the wrong level.
NO! You seem ok... there are a couple guys in the SB though.... ;)
I bet that would have made way more sense to Judah! I just want to be a beta tester, sheesh!
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Anyone have good experience with a particular obfuscator that still allows remoting (binary serialization)? A large part of the fields/properties can't be mangled because of this, and also because of the .NET data binding, which needs the property names to remain intact. Right now I'm considering CodeVeil (gonna try that one tomorrow), because it at leasts encrypts the assembly, so I don't have to worry as much about the field/property names not being mangled.
Wout
We've tried and seemingly bought all of them at one time or another also the encrypting kinds and we've settled on use Spices.Net[^]and it works fine with remoting I can absolutely attest to since our app uses remoting heavily, it's a very large app with multiple assemblies, also an asp.net interface and a winform interface that supports local database access or remoting access via the internet from the winform app. Technically they all support remoting because you simply can't obfuscate some stuff. When you first use an obfuscator you need to play with it a *lot* and configure it carefully. Start with the least obfuscated settings, incrementally turn on more until your app dies, then find out what you can get away with after that. Spices allows you to set configuration method by method etc. There is no product that will work automatically and figure things out for you, none at all, I gurantee you that. You absolutely 100% need to be very patient and test your app thoroughly until you find the right balance of settings and which methods can be obfuscated and which can't. It's a hassle and time consuming but once you get it you're set and from then on it's simply running it after your build. Um..I can tell you all about CodeVeil because we used it for over a year and had to give it up because they didn't have Vista support at the time last fall and we were having other problems and their support literally gave up on us! They were really good at first then their support started to get worse and worse to the point that they simply told us at one point that they would get to us "when they can in the next month or so" because they were busy with some other product they put out. We had a wierd problem that didn't happen in a non encrypted assembly but did in an encrypted one, clearly there was something up and they took a couple of stabs at recommending things then gave us the 'when we get to it' reply. I say "they" but I'm pretty sure it's one guy who runs that project. That was the deal breaking point for us we simply can't afford any down time with our commercial products. My impression is that they were very helpful when they first released CodeVeil and as time went by they either didn't sell enough to put much resources behind it, or they simply give good service when you're new but as time goes by and anything tricky comes up they just start
-
They should have designed protection and licensing into the .NET framework... I guess MS doesn't worry about it since they don't write .NET apps themselves that they ask money for.
Wout
They should have but they didn't. I agree entirely and that was my number one fear of .net which in the end proved to be groundless with a little planning, but I don't know why anyone voted you a 1 for that, you spoke the truth.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
They should have but they didn't. I agree entirely and that was my number one fear of .net which in the end proved to be groundless with a little planning, but I don't know why anyone voted you a 1 for that, you spoke the truth.
"I don't want more choice. I just want better things!" - Edina Monsoon
Maybe a .NET team member took offence. Overall I like .NET, especially the productivity. But I'm not impressed with the business aspect of it: protection, licensing, deployment (ClickOnce, ugh).
Wout
-
We've tried and seemingly bought all of them at one time or another also the encrypting kinds and we've settled on use Spices.Net[^]and it works fine with remoting I can absolutely attest to since our app uses remoting heavily, it's a very large app with multiple assemblies, also an asp.net interface and a winform interface that supports local database access or remoting access via the internet from the winform app. Technically they all support remoting because you simply can't obfuscate some stuff. When you first use an obfuscator you need to play with it a *lot* and configure it carefully. Start with the least obfuscated settings, incrementally turn on more until your app dies, then find out what you can get away with after that. Spices allows you to set configuration method by method etc. There is no product that will work automatically and figure things out for you, none at all, I gurantee you that. You absolutely 100% need to be very patient and test your app thoroughly until you find the right balance of settings and which methods can be obfuscated and which can't. It's a hassle and time consuming but once you get it you're set and from then on it's simply running it after your build. Um..I can tell you all about CodeVeil because we used it for over a year and had to give it up because they didn't have Vista support at the time last fall and we were having other problems and their support literally gave up on us! They were really good at first then their support started to get worse and worse to the point that they simply told us at one point that they would get to us "when they can in the next month or so" because they were busy with some other product they put out. We had a wierd problem that didn't happen in a non encrypted assembly but did in an encrypted one, clearly there was something up and they took a couple of stabs at recommending things then gave us the 'when we get to it' reply. I say "they" but I'm pretty sure it's one guy who runs that project. That was the deal breaking point for us we simply can't afford any down time with our commercial products. My impression is that they were very helpful when they first released CodeVeil and as time went by they either didn't sell enough to put much resources behind it, or they simply give good service when you're new but as time goes by and anything tricky comes up they just start
Hi John, Thanks, that was really helpful. I'm familiar with the Spices.net obfuscator, having used it 2 years ago for my own products. They were always quick to fix bugs that I found, so I was very pleased with that. Early this year I switched to {smartassembly} because it seemed to break disassembly by .NET reflector, which was my major gripe with Spices.net obfuscator at the time, because Spices.net didn't break disassembly. But then 2 weeks later .NET reflector was updated, and it could disassemble the assemblies obfuscated with {smartassembly}, ghaaaaaa! It drove me nuts (and still does). So did Spices.net improve and actually break disassembly? I might go back to their stuff. The encryption thing by CodeVeil has some appeal to me, I just don't like their restrictive licensing.
Wout
-
I've tried a lot of different ones. XenoCode and SmartAssembly seem to be up there, but I still run into problems with those, just not as many as some other obfuscators. Perhaps you will have better results. After a few years of this stuff, I'm convinced obfuscation generally is a big hack designed at the wrong level.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Minnesota Bridge Collapses The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
I do have a smartassembly license already, whoo! I had some problems with it a few months ago, and got tired of it, reporting problems and waiting for fixes. Also .NET reflector broke their obfuscation then. But I just downloaded their latest release, and now it seems to defeat .NET reflector's disassembly! Me happy! Unfortunately I also found a bug (again...) Must be nr 7 or 8 by now in all the obfuscators I've been using.
Wout
-
Hi John, Thanks, that was really helpful. I'm familiar with the Spices.net obfuscator, having used it 2 years ago for my own products. They were always quick to fix bugs that I found, so I was very pleased with that. Early this year I switched to {smartassembly} because it seemed to break disassembly by .NET reflector, which was my major gripe with Spices.net obfuscator at the time, because Spices.net didn't break disassembly. But then 2 weeks later .NET reflector was updated, and it could disassemble the assemblies obfuscated with {smartassembly}, ghaaaaaa! It drove me nuts (and still does). So did Spices.net improve and actually break disassembly? I might go back to their stuff. The encryption thing by CodeVeil has some appeal to me, I just don't like their restrictive licensing.
Wout
I know that I can open my assemblies in reflector but it's damned hard to actually find out what's going on. The bottom line for us was to have something that's difficult to simply reverse into source code. Spices does that well. We don't have any trade secrets or anything that is technically ground breaking and cutting edge, basically business applications. Our only requirement was to protect our licensing code and not allow someone to simply turn it into source code, slap their copyright on it and sell it. We accomplish all that with strong named assemblies and obfuscation. Nothing will ever be perfect and it's a straight up loss of profit to obsess over it and take it too far, you have to at some point accept that it will never be perfect and just like a padlock will only keep the honest people out. In the end it's better to spend time on the features and price it properly so that you reallay don't end up having a lot of piracy and cracking. I don't remember any particularly restrictive licensing on codeveil, maybe they've changed it, in any case give it a whirl and see how you like it. We determined there was just too much trouble with encryption to make it worthwhile without solid support which we didn't get in the end but your mileage may vary.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
Maybe a .NET team member took offence. Overall I like .NET, especially the productivity. But I'm not impressed with the business aspect of it: protection, licensing, deployment (ClickOnce, ugh).
Wout
wout de zeeuw wrote:
(ClickOnce, ugh).
Ugh is right. I have found it an absolutely atrociously unworkable solution for the vast majority of my applications. What were they thinking? What, including a script-based installer in .NET would have been too hard? Freakin.. at least provide decent MSI support.
-
They should have designed protection and licensing into the .NET framework... I guess MS doesn't worry about it since they don't write .NET apps themselves that they ask money for.
Wout
wout de zeeuw wrote:
They should have designed protection and licensing into the .NET framework...
Just out of curiosity... what are you afraid of losing?
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
I've tried a lot of different ones. XenoCode and SmartAssembly seem to be up there, but I still run into problems with those, just not as many as some other obfuscators. Perhaps you will have better results. After a few years of this stuff, I'm convinced obfuscation generally is a big hack designed at the wrong level.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Minnesota Bridge Collapses The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
After a few years of this stuff, I'm convinced obfuscation generally is a big hack designed at the wrong level.
That's exactly it. It needs to be built into the CLR, not even the assemblies - the CLR itself needs to understand name/resource mangling. Ehhh...
-
Anyone have good experience with a particular obfuscator that still allows remoting (binary serialization)? A large part of the fields/properties can't be mangled because of this, and also because of the .NET data binding, which needs the property names to remain intact. Right now I'm considering CodeVeil (gonna try that one tomorrow), because it at leasts encrypts the assembly, so I don't have to worry as much about the field/property names not being mangled.
Wout
try this one... http://www.eziriz.com/[^]
{}*
-
Anyone have good experience with a particular obfuscator that still allows remoting (binary serialization)? A large part of the fields/properties can't be mangled because of this, and also because of the .NET data binding, which needs the property names to remain intact. Right now I'm considering CodeVeil (gonna try that one tomorrow), because it at leasts encrypts the assembly, so I don't have to worry as much about the field/property names not being mangled.
Wout
are you sure you need it? (well, assuming it's not a PHB requirement) http://forum.java.sun.com/thread.jspa?threadID=712642 (it's about java, but the points still apply IMO).
-
Anyone have good experience with a particular obfuscator that still allows remoting (binary serialization)? A large part of the fields/properties can't be mangled because of this, and also because of the .NET data binding, which needs the property names to remain intact. Right now I'm considering CodeVeil (gonna try that one tomorrow), because it at leasts encrypts the assembly, so I don't have to worry as much about the field/property names not being mangled.
Wout
What about the professional version of DotFuscator, obfuscator supplied with VS? Personally, i havent faced any problems with the pro version of DotFuscator.
-
wout de zeeuw wrote:
They should have designed protection and licensing into the .NET framework...
Just out of curiosity... what are you afraid of losing?
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
Go to any ISV conference and ask that question, and you'll get a very definite reply. At the last one I attended we had no more than two or free vendors there who were writing any form of desktop products in .NET (the web is a different matter, of course). The number one reason cited was security and licence key protection. FWIW, the dominant languages in that sector seem to be C++ and Delphi. We're using the former for security and deployment reasons.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Chris Losinger wrote:
strange... i never felt like i had to obfuscate any of my C++ code.
I also have never found good obfuscation tool. I have several products that I have kept off the market until I find such a tool. Windows Light Speed Reducer Windows Gravity Eliminator Windows Sun Rotation Stopper .... and my favorite Windows Reanimator
I love you :laugh::laugh::laugh: (if somebody's curious, I convinced my boss (I am his IT dept for 3 months :P) to get the application I was making for him with a gpl v3 license ;). Just in case he wants to sell it to others at some point, I think it would be good to have them helping in fixing my occasional bugs and adding functionality. After all, I won't be in the same country by then :cool:).)
-
Anyone have good experience with a particular obfuscator that still allows remoting (binary serialization)? A large part of the fields/properties can't be mangled because of this, and also because of the .NET data binding, which needs the property names to remain intact. Right now I'm considering CodeVeil (gonna try that one tomorrow), because it at leasts encrypts the assembly, so I don't have to worry as much about the field/property names not being mangled.
Wout
Take a look at XenoCode http://www.xenocode.com/
-
strange... i never felt like i had to obfuscate any of my C++ code. (though it is fun) i guess that's because C# is better.
image processing toolkits | batch image processing | blogging
What are you talking about? C++ can be disassembled very easily, did you ever use winice/softice? Crackers are able to crack C++ compiled code easier than .NET obfuscated assemblies! Regards, Adam
Make it simple, as simple as possible, but not simpler.
-
What are you talking about? C++ can be disassembled very easily, did you ever use winice/softice? Crackers are able to crack C++ compiled code easier than .NET obfuscated assemblies! Regards, Adam
Make it simple, as simple as possible, but not simpler.
Adam Tibi wrote:
What are you talking about?
no, what are you taking about?
Adam Tibi wrote:
C++ can be disassembled very easily
IL is pretty easy to read, by comparison. everything can be disassembled. everything is assembly/ML, eventually. but assembly is hardly a readable language.
Adam Tibi wrote:
Crackers are able to crack C++ compiled code easier than .NET obfuscated assemblies!
crackers have had 30 years to get good at cracking C++, and there are a whole host of tools out there to help them. and, yes, thanks for stating it again, C# EXEs are easy to crack.
image processing toolkits | batch image processing | blogging