DynLogger logs all dynamically retrieved functions by reporting the module name and the requested function. It can come very handy when one wants to know a “hidden” function used by an application.
I recycled the code of a bigger project to write this little application. It’s a very small utility, but it might be of use after all. It was tested on XP and Vista, both x86 and x64. It works for .NET application as well. Just start the logging process, the log will be saved after you quit the monitored application.
Fixed a significant bug in the mini hook engine on x64. The functions’ syntax hasn’t changed, so you can just update your dll.
Big news: Microsoft is developing MFC again!
Seems that the huge managed code campain didn’t stop developers from writing MFC applications. So, for the first time in years huge updates have been made to the MFC. The new MFC will soon be available (they’re still in beta) as an update.
I quote from Somasegar’s MSDN blog:
The team is looking at the feedback and finalizing plans for where we should be focusing to move Visual C++ forward. One of the first areas you will see us invest is in native libraries. The team is working on a significant update to the Microsoft Foundation Classes (MFC). We will be delivering this as an update to Visual Studio 2008 in the first half of 2008. We will have a preview of the same sometime around the early part of the new year.
Using this update to MFC, developers will be able to create applications with the “look and feel” of Microsoft’s Office, Internet Explorer and Visual Studio. Some of the specific features include Office 2007 Ribbon bar look, Internet Explorer look with rebars and task panes, Visual Studio look with sophisticated docking functionality, auto hide windows, property grids and the like. You can also enable your users to customize your application through live drag and drop of menu items and toolbar buttons.
In the last days I’ve been quite sick, so I decided that as long as I had to stay in bed I might at least use the time to do something useful (or quite so). What happened is that someone asked what the Rich Signature was. It might seems strange but in all these years I didn’t even notice it, I just overlooked it as part of the dos stub (incredible but true). Unable to answer, I noticed together with this person that the subject was completely undocumented. It might not even be much important, but you might find it an interesting reading after all.
Since information about this topic is non-existent, the reader might not know what I’m talking about:
00000070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode….$…….
00000080 E7 B3 9D E7 A3 D2 F3 B4 A3 D2 F3 B4 A3 D2 F3 B4 ç³ç£Òó´£Òó´£Òó´
00000090 60 DD AC B4 A8 D2 F3 B4 60 DD AE B4 BE D2 F3 B4
000000A0 A3 D2 F2 B4 F8 D0 F3 B4 84 14 8E B4 BA D2 F3 B4 £Òò´øÐó´„Ž´ºÒó´
000000B0 84 14 9E B4 3A D2 F3 B4 84 14 9D B4 3F D2 F3 B4 „ž´:Òó´„´?Òó´
000000C0 84 14 81 B4 B3 D2 F3 B4 84 14 8F B4 A2 D2 F3 B4 „´³Òó´„´¢Òó´
000000D0 84 14 8B B4 A2 D2 F3 B4 52 69 63 68 A3 D2 F3 B4 „‹´¢Òó´Rich£Òó´
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
000000F0 00 00 00 00 00 00 00 00 50 45 00 00 4C 01 04 00 ……..PE..L.
The data between the dos stub and the PE Header. It ends with the word Rich. It is produced by microsoft VC++ compilers only and it is encrypted.
Checking the validity of a PE file is a very difficult task, but checking a .NET assembly is even more complicated, since you have to check the tables integrity, the code integrity, the stack integrity etc. Ok, there’s already a tool that does that provided by the .NET framework. However, that tool isn’t perfect either and doesn’t check some other problems. When I wrote my .NET compiler I spent literally days figuring out what was wrong one time or another time in the format I produced, and the MS tools didn’t help. But let’s not go OT, I just wanted to say that this a topic on the woodmann forum triggered my interest because it was a good opportunity to test the CFF Explorer’s scripting capabilities. So, yesterday I took two hours and wrote a little script (called PE Validator Script) which checks for some of the most common problems in a PE. Since it’s a script (thus opensource) it can be expanded easily.
You can find it in the extensions repository:
Here are the current checks:
— check CRC32 (useful for drivers)
— check number of rva and sizes
— check image size
— check sections
— check that EP is valid
— check that EP is in code
— check that the EP section is executable
— check data directories RVAs
— check whether the API IsDebuggerPresent is imported
Don’t be too serious about it, it’s just a thing I did for fun.