MFC Programs seems to be the mainstream of Win32 GUI programming these days, other than QT applications that are rapidly gaining popularity recently. A few days ago, I suddenly got interested in embedded system reversing but was confronted by the task to reverse an application that uploads the firmware image to the embedded system. As expected, the application was MFC, and I was a bit taken back. I wasn't that confident in MFC reversing.
I've seen many people (including me) reverse MFC applications in the same way as reversing pure Win32 API applications. Put breakpoints on certain APIs, search for a target string, search for a certain constant, etc etc. There is no problem with that. The same principles used in non-MFC app reversing can also be applied to MFC apps except.
Except you can't find the Window Procedure within the application. Window Procedures are like the root function of where all the messages are processed, and when you know where it's located, you can always track down your target in a root to descendant kind of approach. It may take more time than the start from a certain function, string etc. approach, but when the later approach may sometimes make you get lost in a labyrinth of code and functions, the formal usually never goes wrong.
The problem is, all the WndProc code is managed by the MFC framework, and the framework gives a slight twist to it to make it work in a different process than what we already know about Window Procedures. The principles are the same, but the structure is a little bit different, and the Message dispatcher code is no longer handled by the programmer. The question is, where is that code and what does it look like? And how could we use it to our advantage?
That will be the main focus of this tutorial, and I will start with showing the usual approach, and point out the problems that may occur in certain situations.