As per Kayaker, I have edited this post instead of replying. I hope this gives a better picture.

Edit:

First, let me state that my question is purely informational, I am not looking for someone to crack this program for me. This program does come as a free trial, but I have already bought it. This is so I can learn.

Second, I am not an advanced reverser, but this program seems to fall in the category of advanced reversing. Thus why Iīve posted here.

While trying to learn more about this art, I have been reversing programs I have. This one has definitely thrown me for a loop with its elusive nature.

1) It doesnīt appear to be packed, studpe and peid both say Microsoft C+

2) Its simply an "enter serial number" proggy. However, I canīt find anything to breakpoint on:
a) i load it up in ollydbg and run it
b) once it is loaded, I go to "search for intermodular calls" and place a breakpoint on EVERY item
c) then i switch back to the proggy. nothing happens. I click on the button to "Enter license". nothing happens. I then
enter a license and press ok. still nothing.

3) Not only does the program not give you an indication if your serial is wrong, but i can't find anything to breakpoint on. If I go to "windows" in ollydbg, press acutalize.. all the items's clsproc have a value similiar to "FFFF0181". So when i try to put a message breakpoint on anything, it gives the error: "you want to place a breakpoint outside the code section". This tells me that its pointing to another process or slot of memory used by another process. Yet, this program installs with no other files.. no dll's. The program itself doesn't create any other processes when started.

4) I've tried running a trace from the entry point to full loading of the program, but it takes too long. I think there may be some infinite loop trap or something, but i don't think there's a debugger detection routine in the program?

I would love any information. Even just a clue as to what Iīm not thinking of, or a place to start looking.

Thanks.

Hi

I edited your post, deleted the link and target name. Not because it goes against our rules or that it's a crack request, I could just as easily shove the "rules" down peoples' throats or simply delete it as we often do with posts to linked shareware.

Instead I'm hoping to test the theory that such RCE problems can be solved *without* a target being specified. I'm hoping that a methodical reversing strategy can be developed, with give and take, to demonstrate how to come up with a generic solution to the problem with this unknown target. Rather than what you were aiming for, someone downloading the software, finding the solution (or a 'hint' if you wish), and then telling you.

i.e., this goes along the lines of that wise old RCE saying, "teach a man to fish v.s. give a man a fish".


So, let's go back to the problem and start at the beginning:

"I canīt find anything to breakpoint on.. and all handles for windows appear to be outside the programīs memory block."

OK, that's intriguing. Why do you say this about the handles being outside the program's memory block? What led you to that conclusion, what tools or techniques indicated that to you?

What breakpoints *have* you tried? What extent of tracing and disassembling have you done? Have you run an API monitor on the target? Have you looked at the listing of exports to see what other variations of window handling/text reading/etc. functions might be being used, other than the ones you expected?

I could go on making guesses as to what you've tried or should try. Now you need to tell US what you've tried and give US enough *useful* information that we can help you or you can help yourself. Often simply breaking down the problem and thinking about what you've done and what you should do is enough to get you to the next step in solving the problem.

Does this approach make sense?

Cheers,
Kayaker

First, thanks for setting me straight. This truly is NOT a crack request. I do want to learn to fish.. not just eat. The reason I didnīt give more details is because I am in ecuador right now in a small beach town at a cyber cafe. When I get back to my īputer in Qutio, I will post more info... because I really am trying nothing more than to learn. I bought this program a while ago and have no need to crack it.

I will reply again when I return to my computer. Thanks alot. -b

Hi

Ah, lazing in a small beach town in Ecuador.. that's sounds pretty rough

Now that you're back and have added further information to the original post..

There are several other things you could try. The app may be creating another process but you just can't tell. Viewing the command window in Softice after starting it, or even better, using a process monitoring driver with the PsSetCreateProcessNotifyRoutine callback should prove it. A secondary process, even with the same name, can be started with services.exe for example. This probably doesn't matter that much anyway for this case.

You should view the complete memory of the process to see if there is a memory-mapped executable section. My favorite tool for this is TopToBottomNT by SmidgeonSoft. Check out the Memory tab as well as the Threads tab to see what other threads are running and their Win32StartAddress (ones in the user mem range are important). This too probably doesn't matter that much but can be very useful.

Lastly, since you've got a dialog box and edit control to play with you might as well just take the bull by the horns and concentrate on breaking on the message handler for that. The simplest approach is to set bp's on GetDlgItemText and the like, the usual culprits, even if you don't see them as exports in the disassembly. Failing that you can set a message breakpoint on WM_GETTEXT or WM_COMMAND. In Softice this is done with the BMSG command, someone else can tell you how it can be done with Olly.


My preferred method though is to directly find the message queue handler for the dialog box and trace it in its entirety, sorting out the different WM_ handlers as I go along and refining where to break as the handler is activated. Once you've done this a few times or written your own handlers this becomes much easier to trace and is almost foolproof.

How to find the message handler though? Sometimes just setting a BMSG type breakpoint and getting lucky is enough to clue you in but if not, a window spy such as MSVC Spy++ is invaluable. In Spy++, if you double click on the target dialog box and check under the Class tab you should find the address of the default Window Proc. For a dialog box this would be DefDlgProcA (or W), for a window, DefWindowProcA (or W). Now that you know the address of that you can set a conditional breakpoint on it.

DefDlgProcA (as example) will be called many times, for such useless things like
WM_MOUSEMOVE equ 200h
so you can set a conditional bp such as
BPX DefDlgProcA IF *(esp+8)!=200 DO "dd esp" // don't break on WM_MOUSEMOVE
BPX DefDlgProcA IF *(esp+8)==0D DO "dd esp" // break on WM_GETTEXT
BPX DefDlgProcA IF *(esp+8)==111 DO "dd esp" // break on WM_COMMAND

Once you've done this (which should work in Olly), you need to trace a bit further to find the *real* message queue handler. The Yellow Brick Road winds down DefDlgProcA -> DefDlgProcWorker -> UserCallWinProc. The parameter pushed (EAX) just before calling UserCallWinProc is the address you're looking for. Skip lightly to the first indirect call, tap your red shoes twice, and you've found the Wizard, the likely dialog box handler.

Start looking

Cheers,
Kayaker