Re: IL Code Security
From: Brian W (brianw_at_gold_death_2_spam_rush.com)
Date: 02/05/04
- Next message: Zürcher See: "Re: datagrid crashes program when loading on the fly"
- Previous message: Tim Mulholland: "Re: IL Code Security"
- In reply to: Tim Mulholland: "IL Code Security"
- Next in thread: Tim Mulholland: "Re: IL Code Security"
- Reply: Tim Mulholland: "Re: IL Code Security"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 5 Feb 2004 08:45:50 -0800
If your boss is so convinced that the algorithms are more secure in C++
then just put them into a DLL (if they arent already) and use P/Invke to
call the functions.
That's what I would do, if disassembly was my concern.
My $.02
Good luck
Brian W
BTW, there is another (better?) version of the Dotfucator available
"Tim Mulholland" <Mulholland.NoSpam@alumni.virginia.edu> wrote in message
news:uPWV$DA7DHA.2480@TK2MSFTNGP12.phx.gbl...
> This thread is intended to be more of a discussion thread - because i
value
> the opinions of the posters in this newsgroup, and especially the MVPs
like
> Nicholas Paladino and Jon Skeet (thanks to all of you for your help over
the
> years).
>
> My company has been toying with moving alot of our applications to .NET/C#
> (which makes me _very_ happy). I've successfully gotten them to start new
> projects using C# and we have been very happy with the results so far.
>
> However, the one primary concern i am running up against in this pro-.NET
> push is that my boss, as well as some of the people that wrote the "old"
C++
> code, doesn't want some of the more important algorithms they use in our
> more critical applications to be easily read via a disassembler (even
> ILDASM) or even turned back into C# code by some of the applications out
> there that are available for that.
>
> I'm kind of at a loss for an answer to them on this, so as of now, i
haven't
> gained much ground. The possible solutions (and reasons why i don't like
> them) that i've come up with so far, are as follows:
>
> 1) Obfuscation: Although this makes it more difficult to read, it doens't
> completely hide the algorithms/theory of the classes/functions in the
> assembly. I've also heard that it has caused people some issues where
> assemblies wouldn't execute after being obfuscated.
> 2) Using Managed C++ and including native C++ lib files: I can't remember
if
> i ever got this working when i tried it myself, but i do remember it being
> quite a pain. part of that came from the fact that i don't like the .NET
> implementation in C++ (compared to the C# one) - it seems very kludgy. If
> this does actually work, then its a possibility, though not a very clean
> one.
> 3) Creating native C++ DLLs and using interop to get to them from C#: This
> was the method i was most successful with, but, partially because of the
> complexity of some of the functions/classes our old applications were
using
> and partially because i'm not all too familiar with marshalling/interop, i
> ended up with some not very nice looking code to allow C# to work well
with
> the functions.
>
> #2 and #3 also just didn't seem like very good options for some of the
> thigns i was converting because the algorithms i was trying to hide were
> fairly closely tied in with the main operation of the applications (the
> parts that would be in .NET).
>
> Basically, i'm curious to find out what others think about all this, and
> what others are doing in their own workplaces. I'm big on C#/.NET and i'd
> love to get the company moving to as much of this as possible, but i don't
> know where to go from here.
>
> Thanks in advance for any comments/suggestions!
>
>
- Next message: Zürcher See: "Re: datagrid crashes program when loading on the fly"
- Previous message: Tim Mulholland: "Re: IL Code Security"
- In reply to: Tim Mulholland: "IL Code Security"
- Next in thread: Tim Mulholland: "Re: IL Code Security"
- Reply: Tim Mulholland: "Re: IL Code Security"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
