Its not arrogance. Please don't be so close minded.
We develop software tools that interface with hardware built by others..
(These are just examples to get open your thought processes)
For example, it could be iPods, cell phones, pda's, etc.. devices built by vendors who we have no communication with and in many cases do not even know about us.
So in our src is methods and keys to access these "devices". So yes, to do what we do you would have to write the SAME exact code as there is one and only one way to do these things.
And I know someone is going to say to put these secure pieces in a native dll or something else.. however the methods and keys are not as simple as you would think. They are actually very complicated and are really embedded into the parent .net program. To
extract them into a seperate DLL would really muck up the entire program structure..
I think the list I came up with on the first page is a great list.prevents viewing the MSIL from both a reflector type app and also via RAM dumpers.
Packs the exe into a loader application that isn't easily unpacked. Prevents .net extraction via modification of the native core .net dll's. Prevents debugger attachments, softice, etc... Disables .NET profiling Protects against ProcDump Does not require packing the entire .net framework into the exe to achieve the above protection
Also, if you think that list is unrealistic, there is an app on the first page that does the above. It is also the most expensive one listed by far. I'm looking for more options.
Okay. The first thing you need to do is identify and eliminate every use of reflection within your entire program. Reflection by definition makes use of metadata embedded within the source program (such as method names, how types are stored etc). Be thorough
when you do so - things like the binary and XML serializer also use reflection to obtain data about how your program works.
The next thing you really must
do is migrate all of your code to one project so you can eliminate DLL dependencies. You'll hate me for even suggesting it, but every call out to a DLL (in .NET or native) conveys a certain amount of information with it,
particularly in the case of .NET. By migrating all of your code to one solution you can build the whole thing without dependencies (excepting the main dependencies such as System and System.Windows.Forms) and any .NET profiler worth it's salt will show you
redundant code paths that you can eliminate as well.
Do everything now that you want to do testwise as you will not have the opportunity to do so later. This includes profiling and tests. You should then ask the CS compiler to compile with maximum optimisations and generate a big EXE in .NET.
You should now run a .NET obfuscator over the assembly, and then using the result and an NGEN make a native executable. It'll be big, and you should ask the program to make sure that all metadata is eliminated. You should now check that the program still works
(if it doesn't that means there was probably some reflective code in the original CS, such as using the Object.ToString() on an object that doesn't overload it.
Now you should be able to run a commercial grade native obscator over the program, and you should then do final testing to make sure that the output is still the expected output. Try using various decompilers to see what code is outputted.
Now if you're really really paranoid, you can zip up the file (with a password or then encrypt it) and write a C app that unencrypts the file and de-zips it into memory and then runs it. You should run a commercial grade obfuscator over the C app if you do
so, and you may find that the zipping process makes the program smaller (but slower) too.