Announcement

Collapse
No announcement yet.

Protection and Conditional Statements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Steve Hutchesson
    replied
    Mike,

    A few basic things here, for someone to make a crack of you DLL means that
    they have to get at the code first while its on disk, the simple solution is
    to use a compressor, a viable one is the freeware UPX version 0.84 that
    cannot be routinely decompressed. Do not use the later ones as they have a
    decompression option.

    The virtue of this approach is that it forces the cracker to manually unpack
    the compressed code and try and reconstruct the PE header and with UPX 0.84,
    this task is beyong most of them as it makes a real mess of the original PE
    sections.

    You already know how to do the length test so if the length of the DLL has
    changed on disk, you know that someone is messing around with it so you don't
    have to be gracious about how you exit the DLL. I would suggest that if the
    length has changed, link the length into a critical number in your code, the
    instance handle or a window handle or the registered class address or any of
    a number of other things and you will leave them with a mess to debug to find
    out why the DLL just crashes.

    Make basic dynamic strings as GLOBAL values and gradually construct them
    through your app until you need them for string comparison. This way the
    string data is not in the application's .DATA section and it means they have
    to track the progressive construction of the string data, not just simply
    look at the .DATA section in a hex editor and get the starting address.

    A collective heap of things take the fun out of cracking a DLL of the type
    you are distributing and if you make it messy enough, no-one will bother.

    Regards,

    [email protected]

    ------------------

    Leave a comment:


  • Mike Trader
    started a topic Protection and Conditional Statements

    Protection and Conditional Statements

    I think I have all the info I need to make a nice little protection scheme. Thank you to everyone that contributed code. It is really cool to have such a wealth of experience available.

    The final chapter (you all hope and pray!) of this oddesy has to do with what Scott said:

    snip:
    Guys, all of this is interesting but if you do ANYTHING in your code like this:
    lReg = CheckifRegistered(blah blah)
    Any good cracker is going to make a crack, a ONE time SIMPLE JMP command to BYPASS that and set a flag to 1.

    So in my code I have:

    IF TodaysDate > ExpDate THEN
    MSGBOX "This program has expired"
    EXIT FUNCTION
    END IF

    If I were a craker, I would look for the last conditional statement and jump over it with my first attempt or in this case:

    IF TodaysDate > ExpDate THEN
    MSGBOX "This program has expired"
    EXIT FUNCTION
    ELSE
    'rest of my progam
    '
    '
    END IF
    THe second attempt would be to switch the outcome of the conditional statement to the ELSE portion

    SO,
    How about using SELECT instead:

    '----------------------------------------------------
    FUNCTION Bogus() AS LONG
    FOR i = 1 TO 100
    Result = Encrypt(nonsense) ' some fast long winded procedure with a few conditional statements
    FOR j = 1 TO 100000
    IF Result = 42 THEN
    Var1 = 42
    END IF
    NEXT j
    NEXT i

    '---------------------------------------------------
    FUNCTION PBMAIN
    '
    ' beginning code
    '
    '
    SELECT CASE TodaysDate ' or NumLaunches or some other criteria that changes each time an attempted launch is made
    '
    ' more case statements befor
    '
    CASE ExpDate - 5
    CALL Bogus ' execute alot of conditional statements to cloud the trail
    CALL MainCode ' function containing the main code of the app
    CASE ExpDate - 4
    CALL Bogus
    CALL MainCode
    CASE ExpDate - 3
    CALL Bogus
    CALL MainCode
    CASE ExpDate - 2
    CALL Bogus
    CALL MainCode
    CASE ExpDate - 1
    CALL Bogus
    CALL MainCode
    CASE ExpDate
    CALL Bogus
    EXIT FUNCTION
    CASE ExpDate + 1
    CALL Bogus
    EXIT FUNCTION
    CASE ExpDate + 2
    CALL Bogus
    EXIT FUNCTION
    CASE ExpDate + 3
    CALL Bogus
    EXIT FUNCTION
    CASE ExpDate + 4
    CALL Bogus
    EXIT FUNCTION
    CASE ExpDate + 5
    CALL Bogus
    EXIT FUNCTION
    '
    ' and so on
    '
    '
    END SELECT
    '
    '
    '
    END FUNCTION
    '-------------------------------------------------------------------------------

    Can anyone see if this would this be as easy to jump over or around ?



    ------------------
    Kind Regards
    Mike
Working...
X