Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

  • Oops, something didn't work.

    Getting "follow" information
    Start following this thread
    Removing your "follow"
    Setting up your "follow"
  • CodeGuru123CodeGuru123

    evildictaitor wrote:
    If you're releasing complex algorithms (such as compilers, or solution solvers or hashes or implementing protected network protocols) which might legitimately be sought after with the intent of gaining knowledge or algorihms (but not code) then you should be looking to build those algorithms in C and use a commercial grade obfuscatior over it.


    Bingo.

    We do exactly that for the VERY sensitive algo's we include in our app.

    We also do include a hardware key for some sensitive algo's too, however our app requires a crippled functionality w/o the hardware key so we're forced to do the method you described as well.

  • evildictaitorevildictait​or Devil's advocate

    CodeGuru123 wrote:
    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.

  • Thread Closed

    This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
    or Contact Us and let us know.