Hi guys,

I've run into a problem with an MFC app I'm playing with. The app in question has an "export" menu function that is disabled in the demo version. Some digging around seems to show that the coders have simply changed the message map for the menu item to point to a function that calls AfxMessageBox with a "you're not allowed" message. The original function that does the export still seems to exist. So the task is to alter the map to point to the function I believe contains the export code.

The problem I have is breaking in and finding the message map. I've set a bmsg on WM_COMMAND which correctly breaks when the menu item is selected, and leaves me in the middle of mfc42/user32.dll stack calls. I've traced back manually and found what looks like the messageloop in mfc42.dll. I've found the call eax which jumps me to the target.exe code. However what I see in the code are stacks of jmp [address] calls, one after the other. No instructions between them, just loads of jmp's. At this point I'm not sure what I'm looking at, and I don't understand how I find the handler for my menu item.

Interestingly the advice in the other related threads here ( http://www.woodmann.net/forum/showthread.php?t=4207 etc) doesn't actually relate to what I'm seeing. For example I see no call to AfxFindMessageEntry...

All help appreciated.

Lotsa' MFC poking lately Silver, huh?

Anyway, I'm not sure if I understand this correctly, but if the "CALL EAX" is in the library code, and the bunch of JMP [ADDRESS] instructions are in the target exe itself, I would try to trace the EAX value in the library code back to where it is retrieved originally from the target itself, since this could give some really good clues.

And finally a stupid question, what do you see if you look at the places where all those JMP-instructions go? Bunches of jump instructions like this are normally jump tables or indexes of some kind, e.g. for case switches or similar (as in message handler case switches for example ), and you can normally get a much better grip on their meaning by tracing back to the code that initially references this table, e.g. the case switch code body, or a function call that takes a pointer to the beginning of the jump table as a parameter or similar (hence my suggestion above).

But then again, maybe I just completely misunderstood what you meant.

This dead-listing approach usually works for me. Its success depends on the id you choose in step one. In case of need, I've got another - scientific! - approach which always does the trick.

1) use a resource editor to pick the 16-bit id for some other menu item in the same menu.

2) look for this id in the executable image with a hexadecimal editor (you will land in the nID field of some entry in the AFX_MSGMAP_ENTRY array for the object the menu belongs to).

here is the definition of the structure:

struct AFX_MSGMAP_ENTRY
{
UINT nMessage; // windows message
UINT nCode; // control code or WM_NOTIFY code
UINT nID; // control ID (or 0 for windows messages)
UINT nLastID; // used for entries specifying a range of control id's
UINT nSig; // signature type (action) or pointer to message #
AFX_PMSG pfn; // routine to call (or special value)
};

3) scroll back till you find the beginning of the message map

Have you already found the true export function?

Bye
Peres

Regarding the array of jmp [xxxxxxxx] :

Most likely not a switch statement table, since switchtables are normally arrays of addresses (4 bytes in length) without the jump instructions in them. It seems to me an imports redirection table of some sort - normally an import is called like:

call [xxxxxxxx]

But in this case the xxxxxxxx is in eax and the call eax has the effect. At [xxxxxxxx] normally points to Imported function itself, but it is redirected to the array of jumps and the jmp [xxxxxxxx] calls the real function. Searching for a table of addresses that are 6 bytes apart and pointing to the jmp array should ascertain this.

call eax --> jmp [xxxxxxxx] --> @xxxxxxxx: { real function } ret (to mfc42.dll after the call)

Excuse the delay, I got some input from dELTA on this then got sidetracked on another project. Anyway I'm now thinking along the lines that this prog has been specifically altered in some way - I cracked an MFC app last night that didn't behave in any way similar to this. I'll get back to it shortly, thanks for everyone's suggestions.