Seems the new CFF Explorer will be compiled with GCC. More than one reason for that. Visual Studio 2008 doesn’t support anymore Windows 98 and NT4 without giving an explanation. The incompatibility is due to a major operating system version inside the Optional Header of the PE and to the fact that the C runtime library makes some unsupported calls. I could of course patch the whole thing and manage to make it run on those operating systems, but why should I? This is not my job. It should be Microsoft’s job to offer an alternative compiling method which provides backward compatibility. What angers me is that Microsoft not only doesn’t care about backward compatibility, they don’t even bother explaining why they had to remove the support for those operating system. The GCC (Mingw) runtime makes it possible to even compile Qt programs for Windows 98 (which is possible with VC++ 2005 too, but it forces me to use an older compiler). And, as I might not be interested so much in Windows 98, I really am interested in providing compatibility with NT4. Or, at least, if it doesn’t offer backward compatibility I want it to be for a better reason than the C runtime. I’m sick and tired of these decisions Microsoft imposes. Just like the XP support which soon will end (actually I haven’t understood if it ends this month or in April 2009). As I understood for OEMs it ends this month. Anyway, I managed to compile the CFF’s kernel with GCC and also fixed lots of errors signalled by that compiler. Another good reason to use GCC is that it’s cross platform, meaning that a port would be much easier. The only drawback of Mingw is that it has a very small (and not up-to-date) Windows SDK, but I’m not interested in that, especially for the CFF Explorer which should become 100% platform independent. At the moment I reached 97% platform independency. My only complaint is directed to the ansi C library. My goodness, you can’t do anything with the IO functions it provides. I’m grateful that they were so kind to provide 64bit support for files: fseek64, ftello64 etc. But there are lots of things missing. For instance, I am unable to truncate a file… In a normal world that would be: FILE *f = fopen(..); ftruncate(f, len);. No, that’s not possible at all in ansi C. That really bothers me, because it forces me to write platform dependent code for my basic programming interface.
EDIT: Seems the new QFile of Qt 4.4 implements the resize method for files and that would do just fine.
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.
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.
– Fixed a lot of bugs
– Fixed a minor bug in the MetaData tables
– Fixed minor resizing bug on Vista
– General improvements
– Significantly improved the interface
– Improved Resource Editor
– Improved Rebuilder (added checksum update and strip debug directory)
– Improved Data Directories viewer
– Improved Hex Editor
– Improved Sections Dialog (added section’s hex view)
– Improved MetaData Tables
– Extended the SDK
– Added powerful very scripting language
– Added documentation for the scripting language
– Added security features for the scripting language
– Added support for generic files
– Added Name Unmangler
– Added Debug Directory
– Added Dependency Walker
– Added Quick Disassembler (x86, x64)
Hope you like it.
After months of work I finally have a release.