No announcement yet.

Mask DLL exports

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mask DLL exports

    Hi all,

    This might be a stupid question, but is there a way (or any utility) to 'hide' exported functions from a PowerBasic DLL, I have seen some DLLs (such as the Win32 core DLLS) have 'hidden' functions which show up as 'N\A' in Dependency Viewer.

    It could be invaluable as an extra security measure.


    Kev G Peel
    KGP Software
    Bridgwater, UK.
    mailto:[email protected][email protected]</A>

  • #2
    I don't know how to mask them but I do have a DLL that is password protected, and the options to you if the password does not match are endless (Reboot machine, send an email, etc..)...

    I'd be curious to know the answer too, one would think it would be in the LibMain function.


    mailto:[email protected][email protected]</A>
    Scott Turchin
    True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi


    • #3
      (Ok I don't know if this works or not... haven't tried it )

      But... Why export any functions at all?
      Export 1 function which returns CODEPTR()'s to each function
      then simply call the pointers with CALL DWORD.

      TYPE myPtrs
        function1 AS LONG
        function2 AS LONG
        function3 AS LONG
      END TYPE
      GLOBAL funcPtrs AS myPtrs
        funcPtrs.function1 = CODEPTR(func1)
        funcPtrs.function2 = CODEPTR(func2)
        funcPtrs.function3 = CODEPTR(func3)
        FUNCTION = VARPTR(funcPtrs)
      ummm... something like that



      • #4

        A DLL is usually not a good place to try and hide anything for
        security reasons. If you do use a security measure in a DLL,
        make sure it is not in the EXPORT function but called from it
        only as the location of EXPORT function is very easy to find.

        Its not much protection but it means that the would be hacker
        at least has to go through the details of the binary file to try
        and find where the security measure is.

        Password protection is one of the easy ones to break and it is
        normal if you need that type of security to interactively develop
        and test the binary code to see how easy it is to break. Usually
        password protection is vulnerable on the password comparison as
        the strings are in memory.

        The alternate method is to track the location of the function that
        the password code is in and look for a conditional jump which you
        just patch with its reverse (je/jne) so that every password is
        correct except the one you designed it with.

        One method I find atractive when it comes to registration or
        similar is to make a DLL that has the clients name compiled into it
        with and encrypted string. Test if the DLL exists and load it with
        LoadLibrary() getProcAddress()so that the encrypted string data
        is visible in the calling app.

        This means you can freely distribute a demo version without the DLL
        and register it with a compiled DLL that has the registration data
        in it. This style of registration still can be broken but it is
        a magnitude more complex to successfully defeat so it will slow up
        most hackers.


        [email protected]

        hutch at movsd dot com
        The MASM Forum - SLL Modules and PB Libraries