Mask DLL exports

[K Peel]

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.

Thanks,


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

[Scott Turchin]

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.

Scott

------------------
Scott
mailto:[email protected][email protected]</A>

[Andreas_Allerdahl]

(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.



Eg:

TYPE myPtrs
  function1 AS LONG
  function2 AS LONG
  function3 AS LONG
END TYPE

GLOBAL funcPtrs AS myPtrs

FUNCTION myDllInit() EXPORT AS LONG
  funcPtrs.function1 = CODEPTR(func1)
  funcPtrs.function2 = CODEPTR(func2)
  funcPtrs.function3 = CODEPTR(func3)
  FUNCTION = VARPTR(funcPtrs)
END FUNCTION

ummm... something like that


------------------
http://www.sublevel6.f2s.com/

[Steve Hutchesson]

Kev,

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.

Regards,

[email protected]

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