|
PureBytes Links
Trading Reference Links
|
>
>I believe it would be harder than disassembling a DLL, since you
>*know* what all the assembler instructions are in the DLL. Plus,
>with a DLL, all you have to find (and remove/disable) is the security
>checks -- remove those few spots and the rest of the DLL is
>unprotected. I think this is probably the weakest point in a DLL
>protection scheme. With DL the entire thing is protected -- none of
>it will work without the proper DL key -- so you have to reverse-
>engineer and re-implement the entire DL subroutine.
Let's say two more words on this topic. It's possible to protect a DLL
against disassembling and against debugging... the code is put in a
protecting evelope. The main advantage is that DLL are quite more flexible
than DL and you can code every sort of trick to check against copy,
including dongles.
DL is a nice way to protect your code, but it's not a free tool and in my
opinion there are more secure and less expensive solutions.
>
>And unless the DLL coder hand-built his DLL in assembly language, the
>DLL will contain some predictable high-level language structures to
>give you some clues. On the other hand, the DLL will be much larger
>and more complex than the DL codes, so that would tend to make the
>DLL harder to crack. Writing DL code is a major pain for the
>programmer. This is the major weakness of DL, since it sharply
>limits the amount of code that you can realistically lock up.
>
An expert programmer can code a DLL using low level programming and realize
complex math in 15/18 Kb code. I'm not telling you to use VB! :)
|