This little crackme coded by Lazarus, he describes as "uncrackable" and dares us to crack it. Now I have played with it for a while and have learned much , but not enough to crack it. Now I can tell you were I am with it but perhaps those of you wishing to assist me in cracking this might be better off without my input at this juncture. There is also the possibility that this is "over this newbies head" at this point in time, but it sure peaks my interest. It can be found at http://mesa-sys.com/mercution/hf/crackmes/lazarus/crackmes2.zip. Help appreciated.

Link don't work.
Wich one is it, crckmeg2, crckmes2 or crckmew2 ?? (use h**p://mesa-sys.com/mercution/hf/crackmes/lazarus/ to get it) ??

Or register on the board, and post it in your post (chck 'attach file' on the message window)

Regards,
Aleph

Hi All,

Permit me to impose here. If I'm not mistaken I think Raven meant this Lazarus crackme:

http://mesa-sys.com/mercution/hf/crackmes/lazarus/crckmeg2.zip

I apologize Raven for not getting back to you on this, I have attempted it and was hoping to give you some good news ;-) It is tough, probably very tough, but as a unified project effort it just might be crackable. To start with it's packed with Aspack 1.081, so you need to at least start Icedump to get it running with SoftIce (it uses the MeltIce protection). The unpacking is easy, you can actually use Procdump on this older version of Aspack (just choose Unpack with a later version of Aspack selected), or you can manually unpack it with /PEDUMP.

However!, I seem to have problems with the unpacked version, the window is partially drawn and then it receives an exit message, so even unpacked there are difficulties.

As for the keyfile and s/n, I haven't given it too much attention yet since I'd *like* to at least be able to work with an unpacked file.

BTW, the solutions that are listed on the site for this crackme are actually for another crackme, bit of a mix up there I guess.

Good luck to all

Kayaker

Kayaker, you are right.It is the crckmeg2.zip file. It has anti-sice and indeed is packed with aspack 1.082. I used procdump on this and saved the unpacked file. When I tried to open the unpacked file, it blinked, again showed its anti-sice protection even with frogsice running. Its a delphia program and dede shows some interesting patch points; except I can't get to them.

damn you guys ;-)

I had to reformat my HD again......haven't even reinstalled Sice yet & it's been a week and a half. But now you go and get my curiosity piqued right when I was starting to be a productive member of society hehe

Well, time to feed my HD some tools & see what I can see :-D

LOL. Whew! Guess we saved you just in the nick of time. Who knows what trouble you would've gotten into out there in society ^_^

I'm still trying to figure out why the unpacked proggy doesn't run well. There is a MeltIce protection easily bypassed (for anyone unfamiliar with this, read code.txt that comes with FrogsIce) or you can simply start up Icedump.

But there's also a PeekMessageA call during creation of the main window that detects a WM_QUIT = &H12 message while the window is only partially drawn. The proggy shuts down of course. This is why you see it "blink", but this has nothing to do with SoftIce detection. It *might* be a deliberate trick which detects if it's been unpacked (and a damn good one if that's the case), or it just might be a weird glitch.

I tried rebuilding the Import table with Revirgin so I could paste it into a raw dump, rather than using Unaspack or Procdump, but Revirgin crashed on me (curious for just Aspack).

Anyway, that's all the useless information I have to contribute for now.

Cheers,
Kayaker

Hi,

OK, I came up with a workable solution to the "blinking window" problem with the unpacked version of this file, if anyone else is having the same effect as me. I also unpacked it using the 'old-fashioned' method of dumping the Import .idata section BEFORE it's overwritten, which is the "trick" behind Aspack, and inserting it into a raw dump of the file. This produced a working file similar to using Unaspack or Procdump. I can go over this method if anyone's interested, but it doesn't really matter, it's not really necessary but I just wanted to make sure the problem didn't have to do with the unpacking method per se.

Anyway, the problem with the window being partially drawn, then exiting occurs here:

:0041E30D E8DEB9FFFF call 00419CF0 -draw template of window
:0041E312 8B45FC mov eax, dword ptr [ebp-04]
:0041E315 E8F2FDFFFF call 0041E10C -process messages which draw rest of window

In the 1st call, most of the main window is drawn except for the tab controls and the edit box text. You can see this by using F4 or typing 'RS' in SoftIce, which will RestoreScreen so you can see what's behind your SoftIce window.

In the 2nd call is a PeekMessageA, TranslateMessageA, DispatchMessageA series of API calls which process certain window messages to draw the rest of the window. For some reason during the 2nd time through this call, the WM_QUIT message (12h) is received and the progam shuts down. This happens here:

:0041E072 E8F9DB0200 call PeekMessageA
:0041E077 85C0 test eax, eax
:0041E079 0F8485000000 je 0041E104
:0041E07F B301 mov bl, 01
:0041E081 837C240512 cmp dword ptr [esp+05], 00000012 ;if WM_QUIT, then quit of course
:0041E086 7478 je 0041E100


This is the normal course of events IF you opted to close the program. Of course we don't want to. So I found what you can do is change the cmp statement to a cmp of the message WM_CLOSE (10h). This way you can still close the program with CTRL-ALT-DEL, but it won't abort to soon. So just change

:0041E081 837C240512 cmp dword ptr [esp+05], 00000012
to
:0041E081 837C240510 cmp dword ptr [esp+05], 00000010

and we can continue with trying to solve the keyfile/serial part of the crackme. I really don't think the above problem is deliberate, there's nothing in the code processing the message queue indicating that it should send a WM_QUIT message if it detects a bad-cracker attempt. Of course I wouldn't want to be quoted on this

You don't really need to do this if you don't want to, you could still work on the packed file. I just wanted to mention this as an option.

Kayaker

Kayaker, here is this newbie's dumb question. The packed crackme blinks when sice is detected. With frogsice enabled, the packed file opens. Now, after the file is unpacked with procdump and frogsice is still running, the unpacked file "blinks" and will not open. Looking at the packed vs. unpacked PE headers, it would seem that changing the unpacked ep to that of the packed ep would lead to the same oep, and thus the unpacked file would open. Am I way off in my thinking on this?

Hi Raven59,

I may be misinterpreting your question, but the Original Entry Point of the packed and unpacked files are going to be different. The OEP of the packed file is the start of Aspack unpacking code (actually it's a jump from the .text section into the .adata unpacking code, but it amounts to the same thing), and the OEP of the unpacked file is the entry point of the original program at 401000. Not sure if this answers your question.

I did find something else out that's *very* interesting. There IS a check as to whether the file has been unpacked by comparing the File Size with what it should be. If it's greater than that then it means it's been unpacked and PostQuitMessage is used to send a WM_QUIT message to the Windows messaging queue. This is the WM_QUIT message that is processed later on and shuts down the program. I don't remember this as a part of Aspack but I could be wrong, it's been a while. So it *could* be something Lazarus coded himself or it's part of a Delphi protection scheme he implemented. (You out there Laz?

Here's what I see happening. There is anti-SoftIce protection built in as part of Aspack which uses CreateFileA to check for the presence of \.\\SICE or \.\\NTICE. This is the MeltIce protection I mentioned. It's easy to bypass by setting a BP on CreateFileA and changing the JZ which monitors for it after the call. FrogsIce and Icedump take care of this little anti-SI trick automagically anyway.

Beyond this there's the check on the File Size here:

:00404A79 E83ED90300 call 004423BC ;Call GetFileSize
:00404A7E 59 pop ecx
:00404A7F 3DE0930400 cmp eax, 000493E0 ;compare size with 300000 bytes
:00404A84 7E0D jle 00404A93
:00404A86 8B0D801F4500 mov ecx, dword ptr [00451F80]
:00404A8C 8B01 mov eax, dword ptr [ecx]
:00404A8E E8B5980100 call 0041E348 ;if >300000 bytes it's unpacked therefore call PostQuitMessage


So I've changed my strategy of dealing with the unpacked "blink" by changing the JLE line instead of modifying the WM_QUIT message test. Now you can run the unpacked proggy and close it normally.

Kayaker

Lo all (kayaker

I just have encounter this kind of check in a ftp server ASprotected ... funny !
BTW exe is rebuild (import ok

Regards SV

Wow, Laz DID go all out, didn't he? ;-)

I can't get my dumped file to run AT ALL, but I suck at unpacking.

I can however disassemble the unpacked version & it looks ok for the most part. Rather than fall too far behind you guys here, I'll just dig around in the unpacked one, & Sice in the packed version hehe....I'm gonna use DeDe to make a .map file for IDA & see if I can use it to find a few interesting things DeDe turned up for me. ( It would be easier if I could get the unpacked version running...can you say Symbol loader? [.map -> .nms]) ;-)

oh btw....I finally got TRW2000 to work on my system (new Video Card) ......& yes, Laz put in stuff to crash that too LOL

Kayaker, If I am following you, you are saying that the unpacked file "blinks" not because of anti-sice protection but because of a file size check with the packed one. You are then saying to eliminate the blink, @ 00404a84, 7eod, change the jle. Now would that be to a jnle and what would the 7e0d be changed to or are you saying to nop this. Still learning! And ferret playing in DEDE, I have some questions there on some possible patch points.
Raven59

Raven,

Actually the window blinks for both those reasons. The *cause* of the blinking is the program receiving a standard Windows WM_QUIT notification message after the window is partially drawn. This "message" has been sitting on what is known as the message queue simply waiting to be processed. It is sent to the queue by the PostQuitMessage API which is called if you fail either the SoftIce or the File Size checks, and is processed later by the PeekMessageA et al calls.

In the meantime there's lots of other code called between the 2 checks and the time the program craps out on you. This is actually a good trick, by not closing the program immediately after the checks it makes it harder to figure out where they are actually coming from. You need to deal with both of these checks separately (unless you patch it as I first did, which I don't *really* recommend, it was kind of brute force). If you are using FrogsIce or Icedump to fool the SI check, then you only have to take care of the second one.

As for the 2nd part of your question I would encourage you to trace through that part of the code and figure out how you want to patch it. You could change the JLE statement but you could also change the number of bytes the true file size is compared to in the cmp statement above that. Or you might find some other patch point within the Call 4423BC above that. There are always other options, so you should explore the code thoroughly on your own, try to understand exactly what's happening and try to determine WHERE you want to code to jump to to bypass the PostQuitMessage being called. You might even want to LET the JLE part of the check go untouched and patch something later, just so you miss the call you don't want called. There is no "best" option, just the one that works for you.

That 7Exx JLE statement: 7E is the opcode for JLE, xx is the number of bytes to jump ahead. You could change it to a JGE but you might as well use an unconditional rather than a conditional jump. EB is the opcode for JMP. EBxx will jump xx bytes ahead, EB00 will jump to the next line only, same as if you nopped out the statement. Determine where you want the jump to go and use the appropriate EB statement. You can type in the code line you want as text with the SoftIce 'a' command.

Hope this helps,

Kayaker

There's no check for ollydbg ;p
Not my favorite stuff, but it can do a fuzzy analysis, telling you what API is called by the proggy, with wich parameters [CreateFileA with hell.key, for example...] and dump any section to a file. No bpx, but useful for a nearly-dead-listing approach (trace the 'You did it' to its point of origin, ...)

Regards,
Aleph

Herm..

I haven't cracked the crackme (abit 2 hard for me atm)

But I was the crackme and it have been solved by others

Check it out at
www.HForge.cjb.net <-- Hellforge
and at
http://members.nbci.com/_XMCM/faxanadurox/crackmes.htm <-- LaZaRuS Crackmes page

Good luck and hope that this was helpfull..
Acid_Cool_178

Acid Cool 178, I may be mistaken,but I don't believe that this crackme we are working on has been solved ,at least not at the sites you mentioned.

Heya Raven59,
I'm not surprise that Tiamath solved the serial coz he is leet on unpacking.
serial does not a problem for him either.
regards
stillnewbie

Kayaker, following your thread, increased the file size and with frogsice running, the unpacked version now runs. Looking in DEDE under timer1timer is a string reference "You did it". Looking up I saw two possible patch points,407232 and 407244. I tried changing and noping but have had no luck as yet. I also used sice on the unpacked file breaking on hmemcpy and began to look for a hard coded serial again with no luck as yet. With WDASM, there are no string references in either the packed/unpacked file. In DEDE, under form key down there is a reference to "didn't shadow mention that disassemblers suck". Wonder if its possible to get string references in WDASM. This newbie continues to learn with your assistance. Perhaps Ferret has Found something of help in DEDE other than what I mentioned.

Raven59

Yeah well don't count on me for guiding you through this one, this is as much challenge as I can handle. This is an excellent crackme. I don't know what we did to deserve such pure evil though ^_^. I've never seen so much labyrinthine, dead-end, confuse-a-cracker code before. Well worth trying this crackme just to study the implementations.

I'm still chuckling over the Timer1Timer event. If you go over the code carefully you see it's targetting W32Dasm and IDA, showing a very simple yet very effective way deter our beloved tools we count on so much. Just try to work with either disassembler while the crackme is running. As he's trying to tell us, disassemblers suck

The FormKeyDown event is curious. It seems to be concerned with the keystrokes Ctrl-D (familiar somehow), but nothing seems to happen one way or another.

At this point I am simply suspicious of EVERYTHING! Either implied or otherwise. The "Input serial here" edit box may be bogus. There's a "hidden" small edit box next to it which may be as well. The only text I see being read is the "UNREGISTERED" label. The "Invalid Keyfile" message box when you create a keyfile is bogus, it will come up in any case. The real, or at least the *more* real reading of the keyfile occurs later, and only if you get the relationship between the ini file and the keyfile correct. You can use an API monitor and GetPrivateProfileStringA to determine this relationship.

The only thing I'm fairly certain of at this point is that what's apparent - isn't. Throw out your old ideas of the way a program should determine if it's registered. I don't think this one will be solved by finding a s/n or patching a few jumps. There is one thing I found which *might* provide an avenue to explore. I was *really* questioning exactly WHAT will tell us if the proper solution is found. There is a "You did it" string in the Timer event, but I have a suspicion this is a red herring. There doesn't seem to be any Dialog boxes which will come up and tell you congratulations. The edit box(es) *might* be used to display some message if you crack it. But I thought the most likely would be a regular MessageBox. So I broke on the "Invalid Keyfile" message box and found that several Message boxes are called from the same location.

* Referenced by a CALL at Addresses:
|:00404B74 , :00406B8E , :00406BE3 , :00406C98 , :00406D20
|:00406D98 , :00406E10
|
:0044AF74 E97334FDFF jmp 0041E3EC

The jump goes to a MessageBoxA call. I traced the 7 addresses that lead here and found the "Invalid keyfile" message came from the 1st one at 404B74 and the second one at 406B8E has a "You did it" message. The text of the message is NOT from the same memory location as that from the Timer event but from here

:00406B71 833D30C3440000 cmp dword ptr [0044C330], 00000000
:00406B78 7408 je 00406B82
:00406B7A 8B1530C34400 mov edx, dword ptr [0044C330]
:00406B80 EB05 jmp 00406B87

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00406B78(C)
|
:00406B82 BAB5D34400 mov edx, 0044D3B5

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00406B80(U)
|
:00406B87 A1801F4500 mov eax, dword ptr [00451F80]
:00406B8C 8B00 mov eax, dword ptr [eax]
:00406B8E E8E1430400 call 0044AF74

The contents of [0044C330] contain "You did it". I was actually able to get a message box with this text to display after pressing the OK button. Of course I don't even know if this what the final indicator of success is supposed to be. As I said, I am very suspicious of Lazarus now

PS, to those who wrote that this crackme had a solution already written, I really don't think so, this is CrackMeg2.

The hunt continues...

Kayaker

* Possible StringData Ref from Data Obj ->"DIDN'T SHADOW MENTION THAT DISASSEMBLERS SUCK ???"

I got a kick out of this also. I am also running into alot of bogus crap.

I got my unpacked ver. to run now, but I said the heck w/ the .map route & just loaded the Delphi 4 FLIRT Sig into IDA while disassembling. I know this labels quite a few functions but I haven't had a chance to dig too far yet.

My PC overheats when I'm in Sice for more than 10 minutes or so, then I have to shut it down (after it crashes itself of course) and wait for it to cool b4 I can try again. Really annoying. Gonna have to check it out a bit further, suspect either Memory Module or Hard Drive. Both are fairly cheap, but if my HD goes out b4 I'm ready for it, I'll be pissed LOL.....anyway, that's my excuse for being so dang slow here ;-)

Hi

just throwing my 2 cents into that project (after AC_178 told me you ppl would work on it) and solving at least a bit of confusion - without spoiling the fun, of course.

The crackme has not yet been cracked as far as I know, and the "disassemblers suck" string reference is a reference to a crackme made by former Hellforge member Shadow where he had a sdr like this in it.

Thats all I remember 100% - I coded this crackme about 2 years ago and dont have the sources anymore.

Generally I can say that you are pretty much on the right track and you probably will have a solution, soon.

LaZ

Kayaker, qferret, this newbie is in way over his head, but struggling to learn. I do read and study a lot but am not up to this challenge. Kayaker, you once said,"if you have a ?, just ask" So here it is. Throughout the thread, there is mention of numerous API calls to various API functions. I gather that when you start the crackme, you are also running an API spy program. Once you learn the eip of the various API calls, you then use sice to break on the location and trace through the calls. Is that correct? If so, a brief explanation is requested. I have not located any tutorials on the use of this tool in conjunction with sice and if you know of any kindly advise. Well at least we got Laz here.

Raven59

Hi Raven59,

Yeah, I tend to consider an API monitor such as APISpy32 a mandatory reversing tool, a point which as some people know I've beaten to death before ;-) After a while you don't really "need" it to sniff out what's happening so much, but it's a great way to learn how Windows actually operates using API's and to get a sense of the general code flow of a program.

You can run APISpy32 on the program you're monitoring with any of the built-in .fnl libraries (Kernel32, User32, Advapi32) or choose just selected functions from any of them. You can also build your own personal library, or modify the existing ones (with Libedit.exe), to eliminate some of the calls that you're either not interested in or come up too often. You can also Pause API monitoring until you decide to start it, i.e. just before you press a registration OK button.

For example, running the API monitor with the Kernel32 library on the crackme scoped out this:

004381A3:FindFirstFileA(LPSTR:00DD6308:"Hell.key",LPDATA:0069FC58 )
004381A8:FindFirstFileA = FFFFFFFF (CRACKME.EXE)

The output is always in pairs when there's a return value and the parameters within the brackets are read in the same order as you see them in the Win32 Programmers Reference, i.e.

HANDLE FindFirstFile(

LPCTSTR lpFileName, // pointer to name of file to search for
LPWIN32_FIND_DATA lpFindFileData // pointer to returned information


While Filemon would also tell you that the program is looking for a file called "Hell.key", it doesn't tell you what API is being used or what address it's at. Try running APISpy on the crackme with the above API, as well as CreateFileA and GetPrivateProfileStringA as a start, and you'll find a wealth of info. When you've "created" what you think the program is looking for, rerun the API monitor and see if there's any new info. This should help you to reconstruct what the keyfile *should* look like.

An API monitor isn't a panacea of course, monitor too many API's at once and you just can't sort out what's important from the output. I didn't use it to find the GetFileSize/PostQuitMessage subversion for example, that was just from poking around in the code, but now that I know what to look for, the API monitor output makes it oh so crystal clear!

Try using an API monitor routinely and you'll probably find it helps a lot.

Regards,
Kayaker

Kayaker, I hope I understand this. In DEDE, under timer1timer you mentioned that the code there is targetting WDASM & IDA.Would you be willing to explain were and how that takes place? Isn't there a way to bypass (patch) a location so that we are able to use these tools? A bit of confusion on my part is this; since the formkeydown lead to the "disassemblers s**k" message and the time1timer lead to the "good boy message", I had thought any anti-disassembler code would be under the formkeydown and not the other way round as you suggest. Would you clarify this? Now I had used debug under WDASM on the unpacked crackme but while stepping through the code nothing moved in the disassembler window. Was that what you meant when you said "try using a disassembler"?

Thanks, Raven

Hi Raven,

I'll try to explain what I saw, but I haven't touched the crackme since my last post so this is just from memory/guesswork. Someone else may have a better interpretation of what's going on.

Under the Timer1Timer event are calls to GetForegroundWindow, which returns the handle of the foreground window (the window with which the user is currently working) and GetWindowTextA which gets the text of the specified window's title bar. After that you notice a bunch of compares:

00407198 cmp eax, +$57 ;W
004071B0 cmp eax, +$33 ;3
004071C8 cmp eax, +$32 ;2

004071EC cmp edx, +$49 ;I
00407204 cmp eax, +$44 ; D
0040721C cmp eax, +$41 ;A

and then a PostQuitMessage call within:

* Reference to: forms.TApplication.Terminate(TApplication);
|
00407229 E81A710100 call 0041E348


So you can use W32Dasm in debug mode, but if you actually allow the crackme to run free so the Timer event kicks in, then move the focus to the window who's title bar contains the text "W32", then the crackme closes itself. Same with IDA. You can *use* both of the disassemblers on the crackme, but not really while it's running. I'm sure you could patch any one of the compares to get around this annoyance, or even change the title bar text of the disassemblers so they don't contain the "bad words".

As for the 'You did it' message, well I could be wrong, but after forcing this part of the code to be executed and tracing it a couple of times, I never figured it to be anything more than a red herring, an enticing string reference to bite on. Also it just didn't make sense to me how or why the valid "good boy" check would be **within a Timer event**. How within 1000 msec or so you could go from not registered to registered, because I didn't see any checking of an ini or key file within the Timer event code, or the Registry, or of a section of code that might be checking if you've since inputted a valid s/n.

If you trace into the code just before what looks like it might trigger the "good boy" jump

0040723D E8CA100300 call 0043830C
00407242 3BC3 cmp eax, ebx
00407244 0F873CFFFFFF jnbe 00407186
0040724A 66C745E42000 mov word ptr [ebp-$1C], $0020

* Possible String Reference to: 'You did it'

all that seems to be happening in the call 43830C is a SCASB on the Title bar of the crackme which returns its length in eax (2F). This is compared with ebx which only seems to be a counter. When the counter reaches 2F then apparently "You've done it". Big Deal! The calls after that don't seem to do anything important like call a message box, change any text or do any further checking for a valid registration. Again, I could be wrong and there *is* something further going on here, I just thought it looked like confuse-a-cracker code to me and I focussed my attentions elsewhere rather than beat this area to death. Call it a hunch

As I mentioned, there is another "You did it" message in another address location that I thought had more potential of being the real one. And as it turned out at least this one *is* used in a MessageBox call.

Continued...

As for the FormKeyDown event, I'm still a little uncertain as to what it's trying to accomplish. The "Disassemblers Suck" message and the www site address again seem to be dangling carrot string references. I couldn't get them to display as messages at all. Another part of the code seems to be targetting the key combination "Ctrl-D"

004070D2 test byte ptr [ebp+$08], $04 ;Ctrl key pressed?
004070D6 setnz dl
004070D9 and edx, +$01
004070DC test dl, dl
004070DE jz 004070FC
004070E0 mov ax, word ptr [ebx]
004070E3 cmp ax, +$64 ;"d" pressed?
004070E7 jz 004070EF
004070E9 cmp ax, +$44 ;"D" pressed?

The hex value comparisons for d and D are obvious, but where the hell does that test with 04h, specifying the Ctrl key come from? Well, if you set a BMSG Hwnd WM_KEYDOWN for example on the Hwnd of the main window (this is the TPageControl window of the tab sheet, not the TForm1 title bar window) and get back into program code (I discuss how to get back into program code from "WM_" message breaks in my latest tut), and then fiddle around tracing the code for a while, you reach the following code:


0041851E push $10 ;virtual keycode for "Shift"

* Reference to: GetKeyState()
|
00418520 call 0044BB68
00418525 test ax, ax
00418528 jnl 0041852D
0041852A or bl, $01 ;identifier for state of Shift key

0041852D push $11 ;virtual keycode for "Ctrl"

* Reference to: GetKeyState()
|
0041852F call 0044BB68
00418534 test ax, ax
00418537 jnl 0041853C
00418539 or bl, $04 ;identifier for state of Ctrl key


So, what's happening here is GetKeyState is used to detect if you've pushed the Ctrl or Shift keys. If so, it flags that fact with the OR statements. This happens continually as part of Windows monitoring and is not part of the protection routine. You can see 04h is used for the Ctrl key. This is where the value comes from in the statement which IS part of the protection Lazarus designed:

004070D2 test byte ptr [ebp+$08], $04 ;Ctrl key pressed?

Now this routine *looks* really cool, but as I say I don't really know what it's supposed to accomplish. I tried changing my SoftIce key combination with the ALTKEY command to something other than Ctrl-D and didn't really find any difference. Nothing seems to happen one way or another. I didn't really spend ages going over this anyway because I found farting around with the WM_KEYDOWN message seemed to lock up my system (couldn't access my desktop icons etc.) I don't *think* this was due to the code, just my unstable system, happens at other times as well.

I could be totally wrong that this code doesn't do something nasty, it just didn't seem to for me. BTW, if you start playing around with this and monitor the contents of [ebp+08], you'll see that for Ctrl it's =4, Shift=1, and Alt=2, but if you use more than 1 they summate, so suddenly it may contain 5,6 or 7. Just a weird thing I've noticed before as well when working with keystroke stuff. You just need to restart the proggy and then [ebp+08] will be cleared.

Well, that just turned into a bloody mini tut. I hope some of it is understandable ;-)

Continued again #$&^!!

Maybe just one last thing. You said

"A bit of confusion on my part is this; since the formkeydown lead to the "disassemblers s**k" message and the time1timer lead to the "good boy message", I had thought any anti-disassembler code would be under the formkeydown and not the other way round as you suggest."

Just a thought on this. Please don't take it wrong or as criticism or anything but I think this illustrates a perfect point that we should always be wary of. The statement is pure assumption. It's guessing what the code *should* be doing logically perhaps, not what's it's really doing. There's absolutely nothing in the world says the programmer should set up the protection a certain way. Remember especially Lazarus is trying to trick us, to make this difficult, probably even more so than a shareware programmer might. So even in a "real" protection there may be curves, dead-ends, obfuscation and so on. Probably a much more effective protection than all the packers, CRC checks and encryption algorithms combined ;p

Cheers,
Kayaker

Kayaker, I wanted to take a moment and thank you for all your help and guidance with this crackme. Although it was not solved, I certainly learned a lot from you. I must say, that I was somewhat surprised that we could not motivate some of our other advanced reversers to assist on this. So qferret, goatass, janek, hz, mersenne, thrax, carpathia, raldnor where were you when we needed you? Thanks also to Lazarus who's crackmeg2 remains unsolved for now, " a splinter in my mind", that I hope to try again as I learn more.

Raven58

Hi Raven58,

I like to be listed among people like Kayaker, Goatass, Carpathia etc but unfortunatly I donīt belong there - I am a raw newbie for whom finding a serial or eliminating a nag is still a challenge (and fun).
Lazarus crackme was beyond my reach and that was the reason I did not participate.
I look forward for new projects (maybe bit easier). Hope there will be some

JaneK

hiya,
Yes you are right. All I can offer in defence is "I really hate" crackme's but its not a good enough reason. I have been bemoaning that the board doesn't appear to be thriving as it once was and then leaving it to people like Kayaker and Clandestiny to put the effort in. Apologies,
(most noteicable by his absence hz).

MINI PROJECT AREA
"A classroom run by newbies for newbies. Gain valuable reversing experience & skills as we explain the in's and out's of RCE"

mmm, big conundrum, who is what ? Like all more advanced;experienced;newbie;RCE I always feel a little guilty about poking my nose where it's not wanted. I don't want to get flamed , well not too much anyways

BIG Q :-

So is this 'mini projects' run by newbies for newbies literal or not ?

As hz says, "I HATE CRAKMES" Most are stupid entrance exams to some la..erm ..nice cracking groupies who want to rival UCF ! So the challenge for me was to pass the test and then refuse to join }>
Never joined a 'klan', never will. I do this stuff for me, myself and I.

With this one from Laz it all seems to be a big joke. Just full of dead ends & red herrings and nice coding tricks. As he said he lost the source

Kayaker , once again the hero, has performed serious scalpel injury
to this crackme and found some nice tricks for us all without actually killing it. It's entrails are all over the floor.... and I bet Laz is too, rollin around p*ssing himself laughing his f*ckin head off ......}>

Greetz

+SplAj

Hey, +SplAj

yeah, alright - I lied when I said that I lost my source, in fact I deleted all of my old sources when I closed my site and started full-time idling

Furthermore I dont roll around on my floor just because the project seems to have failed in the case of this crackme. Actually I am rather surprised about that fact and if I find some time in the next weeks I will try to crack it myself (I hope my memories about this crackme equalize the amount of skills I lost during the last 10 months being out of the bussiness )

So long and keep up the red-herring fishing

LaZ

Goldangit, now you're making me want to start poking around in the fish guts again. Cut that out! ^_^

Guess it's time for another fishing trip?

Kayaker

Greets to Laz & Kayaker

LOL...and this (uncracked }> grrr) crackme is now so old the rotting fishy smell is rather overpowering us all ..... Laz should offer a gas mask to the worthy fisherman who stays the length.......and it won't be me , prefer to shoot the bastards with a kalashnikov !

Kippers for breakfast anyone ?

SplAj

Guess what, I found my source again. It was still on my "ancient" P2-300 =)

It's about 4 pages in a really bad coding style on 800x600 screen resolution (9 KB), and if you wish to have it I can upload it somewhere

But I think you wish to crack it before, anyways

Regards
LaZ

Well found LaZ

.... lets keep the suspense up for a little longer ! if there is a solution then we (Kayaker ) should carry on the hunt :-)

Maybe I will get my Kalash out again ......

SplAj