I wrote a small assembly language program that makes a few calls to a .DLL This DLL is a commercial utility. It is Time restricted to one month. When I disassemble my program with W32dasm and "LOAD PROCESS", the DLL shows up in the Active DLL's box, and can be freely disassembled and traced. If I move the date ahead 1 month and LOAD PROCESS, a windows message box appears "Cant Load DLL". How can the DLL know I changed the date before it gets run? Does windows check DLL's for date stamps before it can load it? Is it some file attribute.? What the hell is going on?

SideSwipe

Hi SideSwipe:

Just a shot: Actually, more information is needed on whether the DLL is a regular Win32DLL, MFC DLL or MFC Extension DLL or COM DLL Ugh!...

Assuming that that world is simple , I assume a simple Win32DLL. Then it must have a function called DllMain which gets a DWORD fdwReason. If it is DLL_PROCESS_ATTACH, then the app checks "whatever". If "whatever" is true, DllMain returns TRUE and DLL init succeeds (Note Addtionally, the DLL may keep some global variables) else DllMain returns false and app gets Can't load DLL msg?

Does any of this makes sense?

Signed,
-- FoxThree

FoxThree:

Thanks for the reply. There is about 15 function calls, none are called DllMain. How can I tell what kind of DLL it is? Is it possible that the code at the Program Entry Point is being fired when W32Dasm loads it into memory?

Tks SideSwipe

A Dll has some init code (well, doesn't necessarily, but they usually do) that gets executed when it's loaded. Thus, what you're experiencing is that the dll's init function is checking the date, and then returns from it's init function with a false return. This tells the system that the dll couldn't be loaded.

What you need to do is find the init function. Do some PE checking to find the init function entry. Then see whatever it uses to check the date.

Regards
Fake

DllMain is entry point of PE module - just insert here int 3 and launch SoftIce

bpx GetSystemTime
bpx GetLocalTime

(problem is that sice will break many times if u put those breakpoints in it)

try to put the breakpoints in w32dasm (all call references to the apis above)

hope that helped u ...

bye !

Ok, with a PE editor, how can I find the DLL entry point? Is it the same as the W32Dasm Program Entry Point? I cant make Sice 4.05 work on my computer

MYDLL.CPP source code...

Perform all #includes here...
Perform all init functions here...

check_date(){...}

export some_func_1(){check_date(); ...}

export some_func_2(){check_date(); ...}

export some_func_3(){check_date(); ...}


Get it...?

The idea is, if ALL exports after being disassembled in, show call to a single location, specially in their initial 10-15 lines of code, check that call. Might as well be the protection.

No softice? No problem. Download the Microsft debugger from

http://www.microsoft.com/ddk/debugging

or download Ollydbg version 1.06.

...Have Phun

Well it's the same entry point !

If u have problems with sice then u have a NT based system, no ??

Anyway if want to put a breakpoint with sice at the dll entry point u can use 'LordPE - RoyalTS' from www.y0da.cjb.net (very util + lots of features and will work with sice perfectly but u must put first in sice a 'bpint3' and after that run the stupid/fucking prog).

Anyway if u want someone to help u crack that shit upload the file somewhere (with the calling exe preferably). U can post also the www from where u got it

Anyway this how it looks in 32bit asm:

LibMain proc hInstDLLWORD, reasonWORD, unusedWORD
.if reason == DLL_PROCESS_ATTACH
mov eax, hInstDLL
mov hDllInstance, eax
xor eax, eax
inc eax ;return true if all things went ok (that means that the dll didn't expired)
.elseif reason == DLL_PROCESS_DETACH
;if we do somethin' before exit like a stupid messagebox that tells us that the dll expired

.endif
xor eax, eax
inc eax
ret
LibMain Endp

When dll is loaded/debugged LibMain is called by windows loader

best regards,
.:hack3r2k:.