Protecting My Assembly DLL

[ZTekalp]

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 ?

 

[Peter Duniho]

[...]
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

 

[ZTekalp]

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

[...]
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

 

[LogicNP]

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)