Prev: ReportViewer hangs my application
Next: Changing the space between characters using DrawString()
From: ZTekalp on 23 Nov 2009 02:50

Hi All,

All you know that, if you develop dotnet application, It s not hard to use
it by someone, no matter it s an application or assembly dll

I tried a solution against this,

Think about I have an application consist of "one login form, launcher",
"one main application, lets say MDI form" form and an assembly dll (real
business application thatt shouldn't be used or decompiled by others)

If I encrypt my dll file with another delphi application before deployment

When user runs my delphi launcher application (consists one login form),
after authentication, this delphi app also decrypt assembly dll

After that again my delphi app launches real dotnet application (after
decryption) and closes itself

Then dotnet application loads dll assembly, and deletes it again

In summary; 1) Run Delphi App 2) This app decrypt dll file 3) This app runs
main dotnet app 4) This app closes 5) main dotnet app uses decrypted dll and
deletes it 6) and application is alive now, no dll available as file in app
folder (except encrypted one)

Would this work ?









From: Peter Duniho on 23 Nov 2009 03:10
ZTekalp wrote:
> [...]
> In summary; 1) Run Delphi App 2) This app decrypt dll file 3) This app
> runs main dotnet app 4) This app closes 5) main dotnet app uses
> decrypted dll and deletes it 6) and application is alive now, no dll
> available as file in app folder (except encrypted one)
>
> Would this work ?

Define "work". You can probably get all of those steps to successfully
complete.

But, presumably you have the larger goal of protecting your DLL from
reuse elsewhere. And for that, the answer is "no". There is in fact
_nothing_ you can do to reliably secure your DLL against illegal reuse,
if you allow your DLL to execute on a computer not fully controlled by you.

In the scheme you describe, someone simply needs to either debug the
Delphi application to reveal your encryption method and key, or just
wait for the Delphi application itself to decrypt your DLL and then copy
the results.

Since your proposal is apparently to save the decrypted DLL to a file,
that makes the latter approach trivial: all a person needs to do is
start up the program, go find the decrypted DLL (trivial to do with any
decent process viewer...just look at all the loaded modules to find the
path) and copy it to a new file.

Even if you decrypted and executed strictly from memory, the decrypted
version is accessible to the enterprising hacker. It's only slightly
harder for them to get to.

There are modifications to your proposal that could increase security,
but at increased cost of effort too. The fact is, if it is worthwhile
to invest some specific amount of effort in copy-protecting your code,
it is also just as worthwhile for a hacker to defeat your copy-protection.

At most, take minimal steps to limit the use of your DLL to legitimate
clients. For example, require some kind of encrypted key to be passed
to it during initialization. This is easy to defeat for a determined
hacker, but also easy to implement. You won't waste a huge amount of
time building in some elaborate copy-protection scheme that someone else
is just going to bypass anyway, and you get then get on with adding the
features to your DLL that make it worth someone's while to actually pay
your license fee to use.

Pete
From: ZTekalp on 23 Nov 2009 03:29
Thanks for your answer,

Actually, I am not fighting with hackers, any protection will not stop them,
my basic goal is to prevent normal user, or normal coders, basically use my
dll or decompile and see business logic in it,

That would be much much harder to hack delphi app,

After Installing my app, no one will see any assembly dll, and this is
enough for me now, your encrypted key proposal is plus for me.

Thanks

ZT


"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
news:%231GftRBbKHA.5608(a)TK2MSFTNGP05.phx.gbl...
> ZTekalp wrote:
>> [...]
>> In summary; 1) Run Delphi App 2) This app decrypt dll file 3) This app
>> runs main dotnet app 4) This app closes 5) main dotnet app uses decrypted
>> dll and deletes it 6) and application is alive now, no dll available as
>> file in app folder (except encrypted one)
>>
>> Would this work ?
>
> Define "work". You can probably get all of those steps to successfully
> complete.
>
> But, presumably you have the larger goal of protecting your DLL from reuse
> elsewhere. And for that, the answer is "no". There is in fact _nothing_
> you can do to reliably secure your DLL against illegal reuse, if you allow
> your DLL to execute on a computer not fully controlled by you.
>
> In the scheme you describe, someone simply needs to either debug the
> Delphi application to reveal your encryption method and key, or just wait
> for the Delphi application itself to decrypt your DLL and then copy the
> results.
>
> Since your proposal is apparently to save the decrypted DLL to a file,
> that makes the latter approach trivial: all a person needs to do is start
> up the program, go find the decrypted DLL (trivial to do with any decent
> process viewer...just look at all the loaded modules to find the path) and
> copy it to a new file.
>
> Even if you decrypted and executed strictly from memory, the decrypted
> version is accessible to the enterprising hacker. It's only slightly
> harder for them to get to.
>
> There are modifications to your proposal that could increase security, but
> at increased cost of effort too. The fact is, if it is worthwhile to
> invest some specific amount of effort in copy-protecting your code, it is
> also just as worthwhile for a hacker to defeat your copy-protection.
>
> At most, take minimal steps to limit the use of your DLL to legitimate
> clients. For example, require some kind of encrypted key to be passed to
> it during initialization. This is easy to defeat for a determined hacker,
> but also easy to implement. You won't waste a huge amount of time
> building in some elaborate copy-protection scheme that someone else is
> just going to bypass anyway, and you get then get on with adding the
> features to your DLL that make it worth someone's while to actually pay
> your license fee to use.
>
> Pete

From: LogicNP on 7 Dec 2009 06:18
What if app crashes and the dll remains on the file system. Instead of what
you are doing, use an obfuscator on your assembly. Check out Crypto
Obfuscator (http://www.ssware.com/cryptoobfuscator/obfuscator-net.htm)


 | 
Pages: 1
Prev: ReportViewer hangs my application
Next: Changing the space between characters using DrawString()