please help

thanks again Satyric0n, im on it. ill read it right now...

hey satyric0n, I didnt have any such luck. The call is coming from one of the temp dll's. sh_t! any ideas?= check it out:

Call stack of main thread
Address Stack Procedure / arguments Called from Frame
0012DACC 77D43C53 Includes 7FFE0304 USER32.77D43C51 0012DB00
0012DAD0 77D4B3F2 USER32.WaitMessage USER32.77D4B3ED 0012DB00
0012DB04 77D4D9A0 USER32.77D4B265 USER32.77D4D99B 0012DB00
0012DB2C 77D6AE8E USER32.77D4D8EC USER32.77D6AE89 0012DB28
0012DDE4 77D6A911 ? USER32.SoftModalMessageBox USER32.77D6A90C 0012DD6C
0012DF2C 77D6AFD5 ? USER32.77D6A7D7 USER32.77D6AFD0 0012DEB4
0012DF84 77D6B0BD USER32.MessageBoxTimeoutW USER32.77D6B0B8 0012DF80
0012DFB8 77D6B04A ? USER32.MessageBoxTimeoutA USER32.77D6B045 0012DFB4
0012DFD8 77D6B02E ? USER32.MessageBoxExA USER32.77D6B029 0012DFD4
0012DFDC 0003041A hOwner = 0003041A ('Software Registration',class='#32770',parent=0003
0012DFE0 003A6450 Text = "Registration Failed - your registration key has not been acce
0012DFE4 003A3ED0 Title = ""
0012DFE8 00000030 Style = MB_OK|MB_ICONEXCLAMATION|MB_APPLMODAL
0012DFEC 00000000 LanguageID = 0 (LANG_NEUTRAL)
0012DFF0 00428B04 ? USER32.MessageBoxA 6D79C0BD.00428AFE /6d79c0bd (6d79c0bd.dll) is on of the two elusive dll��s that are written in C:\Documents and Settings\jdog\Local Settings\Temp and then deleted!!
0012DFF4 0003041A hOwner = 0003041A ('Software Registration',class='#32770',parent=0003
0012DFF8 003A6450 Text = "Registration Failed - your registration key has not been acce
0012DFFC 003A3ED0 Title = ""
0012E000 00000030 Style = MB_OK|MB_ICONEXCLAMATION|MB_APPLMODAL

thanks,
Jeff

I'm sorry, it appears I misunderstood what you were asking for. I thought you were having trouble finding the code in the dynamically created .DLL that is checking your registration status.

So what you are actually asking is how the .DLL is stored in the original .EXE, so that you can modify the .DLL before it is extracted (and crack the code in the .DLL that checks your registration status, etc)? If that is the case, I'm not sure I can help you... Without knowing what packer/protector is being used to encapsulate those .DLLs, or which specific application you are working on, I have too little information to go on to even hazard a guess.

Sorry I couldn't be of any real help.

Regards,
Satyric0n

Satyric0n check your pm...

Satyric0n check your pm...again

anyone else have any ideas??

[dyn!o]

There is no problem (as always ).

First of all you have to discover how the dll communicate with the base (exe or other dll). Generally there are two possibilities:

1. The dll is physically extracted at runtime to TEMP folder and then communicate via usual way. If you encounter this one then it is more than easy - all you have to do is to find the place where this dll is extracted and make a backup during usual program execution. Then you can dance and make yourself "feel good".

2. The dll is dynamically hooked at the runtime via loader (which can be executed as part of a packer) and it is being hidden during usual program execution. You can't see it because all API calls and dll initialization moment is being handled by the loader. In this case you have more work (about 20 minutes) because you need to extract the dll at its initialization moment, thus you need to verify if import table does need rebuilding.

Bla bla...
Anyway, you can always prepare direct attack on the dll - no matter how much layers it uses. Just look at the latest Paradox SwishMax 2004.02 crack - they did fuck**g good job (as the only one). Probably you can learn a lot from this crack (multiloader).

Best regards,
dyn!o