I’m trying to crack target <name deleted>. It’s packed using ASProtect unknown version. I didn’t find any tutorial which would fit the version used in this program. Anyway, I managed to find the OEP (original program entry point), but I can’t extracted it using methods described in some tutorials. Basically my problem is that export table contains invalid data. Bellow there is portion of the table extracted from the memory. How can I overcome that problem and reconstruct import table?

004083D8 -FF25 900D6500 JMP DWORD PTR DS:[650D90] ; USER32.SetWindowPlacement
004083DE 8BC0 MOV EAX,EAX
004083E0 -FF25 8C0D6500 JMP DWORD PTR DS:[650D8C] ; USER32.SetWindowPos
004083E6 8BC0 MOV EAX,EAX
004083E8 -FF25 880D6500 JMP DWORD PTR DS:[650D88] ; USER32.SetWindowTextA
004083EE 8BC0 MOV EAX,EAX
004083F0 -FF25 840D6500 JMP DWORD PTR DS:[650D84] ; USER32.SetWindowTextW
004083F6 8BC0 MOV EAX,EAX
004083F8 -FF25 800D6500 JMP DWORD PTR DS:[650D80] ; USER32.SetWindowsHookExA
004083FE 8BC0 MOV EAX,EAX
00408400 -FF25 7C0D6500 JMP DWORD PTR DS:[650D7C] ; USER32.SetWindowsHookExW
00408406 8BC0 MOV EAX,EAX
00408408 -FF25 780D6500 JMP DWORD PTR DS:[650D78] ; USER32.SetWindowRgn
0040840E 8BC0 MOV EAX,EAX
00408410 -FF25 740D6500 JMP DWORD PTR DS:[650D74] ; USER32.ShowOwnedPopups
00408416 8BC0 MOV EAX,EAX
00408418 -FF25 700D6500 JMP DWORD PTR DS:[650D70] ; USER32.ShowScrollBar
0040841E 8BC0 MOV EAX,EAX
00408420 -FF25 6C0D6500 JMP DWORD PTR DS:[650D6C] ; USER32.ShowWindow
00408426 8BC0 MOV EAX,EAX
00408428 -FF25 680D6500 JMP DWORD PTR DS:[650D68] ; USER32.SubtractRect
0040842E 8BC0 MOV EAX,EAX
00408430 -FF25 640D6500 JMP DWORD PTR DS:[650D64] ; USER32.SystemParametersInfoA
00408436 8BC0 MOV EAX,EAX
00408438 -FF25 600D6500 JMP DWORD PTR DS:[650D60] ; USER32.TrackPopupMenu
0040843E 8BC0 MOV EAX,EAX
00408440 -FF25 5C0D6500 JMP DWORD PTR DS:[650D5C] ; USER32.TranslateMDISysAccel
00408446 8BC0 MOV EAX,EAX
00408448 -FF25 580D6500 JMP DWORD PTR DS:[650D58] ; USER32.TranslateMessage
0040844E 8BC0 MOV EAX,EAX
00408450 -FF25 540D6500 JMP DWORD PTR DS:[650D54] ; USER32.UnhookWindowsHookEx


00650D38 8E BD D4 77 75 05 6B 05 0C 94 D4 77 95 FB D5 77 Ž½Ôwu k .”Ôw•ûÕw
00650D48 F9 D7 D4 77 BD 99 A1 CF 1D C7 D4 77 F3 0D D5 77 ù×Ôw½™¡Ï ÇÔwó.Õw
00650D58 F6 8B D4 77 07 FB D5 77 D6 4E D9 77 92 0A D5 77 ö‹ÔwûÕwÖNÙw’.Õw
00650D68 E0 9B D5 77 A4 D8 D4 77 CA F2 D5 77 7E 5E D8 77 à›Õw¤ØÔwÊòÕw~^Øw
00650D78 DD 02 D5 77 AF E4 D5 77 E9 11 D6 77 36 BC D4 77 Ý Õw¯äÕwé Öw6¼Ôw
00650D88 43 F5 D5 77 1B C0 D4 77 46 DF D5 77 2B D6 D4 77 CõÕw ÀÔwFßÕw+ÖÔw
00650D98 0D D6 D4 77 2E 8C D4 77 73 F9 D5 77 28 F7 D5 77 .ÖÔw.ŒÔwsùÕw(÷Õw
00650DA8 56 90 D4 77 E2 C2 D4 77 C6 B5 D4 77 D8 FF D5 77 V�ÔwâÂÔwƵÔwØÿÕw
00650DB8 D2 DC D4 77 1E AA D9 77 F6 F0 D7 77 8D 02 D6 77 ÒÜÔw ªÙwöð×w� Öw
00650DC8 95 47 D5 77 60 DA D4 77 58 BF D4 77 76 0F D6 77 •GÕw`ÚÔwX¿Ôwv Öw
00650DD8 49 FE D5 77 CF E8 D4 77 CE D6 D4 77 CD 48 D5 77 IþÕwÏèÔwÎÖÔwÍHÕw
00650DE8 50 36 D8 77 BA B8 D4 77 9A F3 D5 77 5F 01 D6 77 P6Øwº¸ÔwšóÕw_ Öw
00650DF8 11 FF D5 77 C8 BD D4 77 6C 00 D6 77 C3 91 D5 77 ÿÕwȽÔwl.ÖwÑÕw
00650E08 9D 86 D4 77 EA D6 D4 77 28 8E D4 77 28 8E D4 77 �†ÔwêÖÔw(ŽÔw(ŽÔw
00650E18 9A A3 D4 77 1A E2 AB 4D 6C BF D4 77 41 BD D4 77 š£Ôw â«Ml¿ÔwA½Ôw
00650E28 11 12 D5 77 85 CB D4 77 9B 92 D4 77 6C C9 D4 77 Õw…ËÔw›’ÔwlÉÔw
00650E38 4F 02 D6 77 31 B6 D4 77 AF 00 D6 77 45 96 D4 77 O Öw1¶Ôw¯.ÖwE–Ôw


My next issue is getting rid of NAG screen. Before I describe the issue I’m facing, I need to describe little bit of program behavior I observed. When originally installed, it ran for 30 days, no NAG screen displayed, full functionality. After 30 days, NAG screen is displayed and you have certain number of executions left. I don’t remember the figure, but every time you start the program, it’s decremented by one. When value reaches 0 only option to purchase program is left. What I found interesting and puzzling at the same time, that computer clock change didn’t trigger 30 days period expiry. How could they do it?

Anyway, I found a routine which displays a NAG screen, but I can’t find a point there where they deciding whether trial period is over or not and displaying NAG screen accordingly. I back-traced calls to parent subroutine, but I still haven’t decision making switch/jump. When I tried to NOP the call for NAG window, it didn’t display NAG screen, but application ended, because when NAG screen displays “purchase only” option, when you close the window, application ends. I inspected the stack content at the beginning of the subroutine and I found that all the previous calls are coming from user32 and kernel32. Is it possible that this NAG screen routine would be called from window procedure of one of the application windows? Any suggestion how can I back-trace caller of the routine?

And one more question. Program calls some subroutine from user32.dll which is not exported. How can I find what function it is? Is it a standard to call undocumented library functions in programs?



Thank you in advance for your suggestions and ideas.

Ouch! Ouch! OUCH!!

Please JMI, go gentle...

Have Phun

What does JMI mean?

You'll find out soon

Or if you can't wait, go look in a mirror in a dark room and say "I didn't read the FAQ" three times and JMI will come out and get you!

Aw give the poor guy a break (JMI that is). You just want to see The Dance, don't you?

All the moderators saw this when it was first posted and any of us could've/would've/should've dealt with it.

Robson, we don't usually allow ANY target specific code if it's directed towards cracking a named commercial software. If you had read the FAQ in big bold letters as you were supposed to, or if you had lurked a bit and read enough other threads before posting you would have gathered as much.

JMI, as our main "enforcer", would normally inform you of this. Since many first time posters seem to not want to accept these rules and instead endlessly argue the point in self justification instead of spending the effort in learning how to reverse, the non-pertinent posts escalate and "The Dance" ensues.

I think the general feeling was that the post was innocent enough and the questions generic enough to allow generic answers and the mild transgression was ignored. If someone replied with specific addresses to patch for example, then the moderators would have put the kibosh on the thread for sure. Most people here know that.



As I said, these are generic questions that didn't need the target to be named. Carry it forward logically. As you are aware, you need to rebuild/reconstruct the import table. There are many articles on the subject, find and study them, then come back with a more detailed question if necessary. Are you familiar with Imprec?

What is the program call to the subroutine from user32.dll which is not exported? Need more details, show some code.

I did what I was going to do a couple of days ago, removed the target name. There, it's done. Sorry, no Dance this time


Kayaker

*THUD* !!

... Annnddddd, another one bites the dust!!

Hmmm..

Have Phun

Damn! Somehow I missed this one over the weekend. Anyway, Kayaker took care of it and I don't have to do the "dance."

Regards,

Wow, How many responses I've got :-) Glad that I’m still alive :-)

Anyhow, Yes I didn’t read the FAQs 3 times :-), but I was forced to read it after I got all the replies.

I understand that I need to reconstruct import table. I have some idea I try first and I would ask very specific question, if it fails.

Here is part of the program which calls some subroutines from user32.dll.

021F001D 33C0 XOR EAX,EAX
021F001F 68 00010000 PUSH 100
021F0024 50 PUSH EAX
021F0025 50 PUSH EAX
021F0026 8945 FC MOV DWORD PTR SS:[EBP-4],EAX
021F0029 8D45 D0 LEA EAX,DWORD PTR SS:[EBP-30]
021F002C 50 PUSH EAX
021F002D C745 D0 30000000 MOV DWORD PTR SS:[EBP-30],30
021F0034 68 C514D577 PUSH 77D514C5
021F0039 68 01A4D477 PUSH 77D4A401
021F003E C3 RETN

I used checked export tables from user32 against those two pushed addresses, but there is no entry pointing there. Here is also copy of relevant part of the memory map just to confirm that those belong to user32.dll.

Memory map
Address Size Owner Section Contains Type Access Initial Mapped as
77D40000 00001000 USER32 PE header Imag R RWE
77D41000 0005F000 USER32 .text code,imports Imag R RWE
77DA0000 00002000 USER32 .data data Imag R RWE
77DA2000 0002B000 USER32 .rsrc resources Imag R RWE
77DCD000 00003000 USER32 .reloc relocations Imag R RWE

I discovered those call when I was trying to find a call to function RegisterClass and I used return address provided by API spying utility.

Slacker .

OK, so we cut the kid some slack. I am in a good mood these days.

Woodmann

That looks like "asprotect stolen bytes". Searching for that string on the forum I get 29 hits. Searching for that in the RCE CHM Archive (available below, it's a better search engine) I get 55 hits.

Perusing those hits should help explain things, which any self respecting Asprotect tut should describe. I thought you meant the program was doing that, but from the offsets that definitely appears to be Asprotectishisnism. Compare those pushed user32 addresses with the IAT address for RegisterClassA/W for fun.

Out of interest, if I search for those bytes in IDA with my user32.dll version, surprise, it comes up as part of RegisterClassA/W.


We don't bash good newbies, just the bad ones..