Month: June 2007

Posted on

Secrets of the Application Compatilibity Database (SDB) – Part 4

My apologies for the long delay until this fourth part was published. I have been teaching in Seattle for the previous two weeks, and have just started to settle in Cupertino for my Apple internship, and I had very few spare moments in my hands.

In Part 3, we discussed how generic shims modify key parts of the system, usually through API hooking or undocumented flags, in order to provide compatibility with a variety of applications. We looked at shims such as the Windows 9x Heap Manager implementation in NT, and several re-direction and reflection APIs, as well as even some security bypassing shims. Today, we’ll take a look at how certain applications have specific shims implemented specifically just for them. We can find these with CDD easily, by noticing that the Shim name is usually a program name, as well as looking in the DLL which implements it. Finally, specific shims never have any descriptive text describing them. While looking through the Shim dump, I’ve chosen this one (arbitrarly):

Dumping Entry:

SHIMNAME="CorelSiteBuilder"
DLLFILE="AcSpecfc.DLL"

Any continued analysis on this shim must be done through reverse engineering, since we have no hint as to what this shim is attempting to do. By using IDA on the DLL specified, one can notice it is a series of C++ classes, each which represent a specific shim (there are of course other classes such as CString and the generic Shim Engine initialization classes). The prefix for the specific shims seems to be “NS”, so it was easy to locate our target of interest: NS_CorelSiteBuilder. Every shim class also has an initialization function that gets called, and is responsible for initializing the class and its hooks. This is usually called IniitalizeHooksMulti. In the disassembly of this function, pay special attention to loc_714F3691. This is where this class initializes the API hooks that make up this specific shim (other specific shims can also have other types of hooks, such as patches or COM hooks). The tagHOOKAPI structure contains the information required to patch an API, and one can clearly see that SetWindowTextA inside user32.dll is being hooked, and re-directed to NS_CorelSiteBuilder::APIHook_SetWindowTextA.

Now the actual hook can be looked at, and I’ve provided an analyzed and commented disassembly here. This is a pretty simple hook, and seems to check on whether the window handlw and window text that are being sent as arguments match the previous window handle and window text that the shim had saved durinng the last call. If they do match, it will simply return TRUE (success) without actually calling the original API, otherwise, the hook will save the window text that’s being set as the “old” window text (so that when the hook is called again, it will compare against this name now), and then perform a call to the original API (in tagAPIHOOK+0xC) with the unmodified arguments.

In other words, the whole point of this shim is to “absorb” SetWindowTextA calls to the Corel Site Builder window if the new text that’s being set matches the previous text, and simply return success. The reason on why such a shim would be necessary is left as an excercise to the reader.

In the next article, I will release the first version of the CDD utility which I’ve used when showing some of the Shims available, and document some of its uses.

Posted on

A New Direction

It is with great excitement (and a certain amount of nostalgia) that I would like to announce two important changes in my professional life and in the direction in which I will pursue my knowledge and work on Windows Internals. The first of these changes is my debut as an instructor for David Solomon’s Expert Seminars, and the second is my departure from ReactOS, effective immediately. These plans do not change in any way my internship at Apple which will take place during the summer.

Some time ago, I had the great privilege of being approached by David Solomon, a well-known and highly regarded computer expert, teacher, consultant and co-author of Windows Internals 4th Edition (and Inside Windows 2000, 3rd Edition). For the last couple of years, David had been working with Mark Russinovich, another respected figure in the world of Windows Internals, and co-founder of Winternals and Sysinternals as well as developer of some of the most useful Windows system tools available today. Apart from working on the two books (which Mark was a co-author of), they both provided trainings and seminars on Windows internals under the “David Solomon Expert Seminars” banner. As is widely known, Microsoft realized that Mark’s experience and amazing work on the NT platform through his articles and tools could provide a highly beneficial new addition to the company. The company bought Winternals last year, and hired Mark at the highest technical level in the company, Technical Fellow. 

All this is history of course, and back to the matter at hand, Mark’s recent new employment made him unavailable for teaching new classes, which made David Solomon start the search for a new instructor which could take on the responsibility of teaching new classes. I was highly honoured to have been chosen as this person, and accepted this unique opportunity to bring my knowledge out to many more people and to work with one of my most admired Windows experts

With this new job as an added task on top of my already busy life, as well as with the imminent Apple internship, I was already planning to cut back on my involvement with ReactOS. However, since it became clear that my level of contact with Microsoft employees and resources would be in conflict with my work at ReactOS, I made the difficult choice of amicably severing my ties with the project. This decision took some time for me to finalize, but the various motivations behind it had started cropping up since early this year

When I first joined ReactOS 3 years ago, the kernel was – in my opinion – highly disorganized and hodgepodge of Linux, NT 4, Wine and Windows 9x code which was very far from its actual goal of NT Driver compatibility. In fact, the development model seemed to focus on hacking NT drivers to work on ReactOS, and not vice-versa. Coincidentally, I joined the project just as the lead kernel developer, David Welch, had just burnt out and moved to other projects and goals. For the last three years, I rewrote key subsystems such as the thread scheduler, dispatcher, locking and IRQL mechanisms, HAL, executive support, object manager, process manager, I/O manager, basic VDM and 8086 support, and much more, as well as switched the project goals from NT4 to NT 5.2. 

My ability to do this came from my extensive reverse engineering of the kernel in the past, reading internals books, access to the DDK/IFS, as well as using WinDBG and .pdb type information. In return for all the code and guidance I provided, the project gave me a lot in return as well, including a unique perspective of working on such a project, the ability to work in large and distributed teams, and using open source tools for Windows NT kernel development. With millions of lines of code, ReactOS is the kind of project that an 18 year old could’ve only dreamt work ing on. I became adept in source control repositories, regression testing, unit testing, team management, IRC administration, as well as a much better coder in C. I also made friendships of all levels with various developers, testers and users, and had a chance to mentor two students during last year’s Google Summer of Code. I was able to attend and give talks on ReactOS, exhibit it, and make connections with other people in the industry, and in the open source world. Overall, it’s been an exhilarating adventure.

After three years however, and with the many new responsibilities that had kept growing, my free time grew short. Additionally, my work in the kernel had almost reached completion. The parts that still need major work, in my opinion, require extremely skilled developers in those areas to ever be as close to NT as needed. They are also some of the most critical: the memory manager, the cache manager, the Power/PnP Manager, the configuration manager and the file system runtime library. With the current differences that exist, most modern WDM drivers as well as IFS drivers can only dream of running properly. Unfortunately, my knowledge in those areas was limited. I had never reverse engineered them as extensively as parts of the executive, and documentation on their guts is limited.  In all honesty, they’re also not parts of the system that interest me much. I could, of course, have continued working on user-mode parts of the system where my help would still bring a lot of the system forward, such as ntdll, csrss, smss, winsock and kernel32, but my interest in teaching with David Solomon and getting in touch with the developers behind NT outweighed that desire.

After three years, I learned a tremendous amount of knowledge and skills while working on ReactOS, now the time has come for me to learn even more by expanding my horizons. In many ways, I had already outgrown the project, focusing more on security research, utilities and tools, articles and non-ReactOS related talks and conferences. It was time for me to step outside and take on a new opportunity with a larger audience and which would bring me many new experiences and teachings. I wish the ReactOS Project all the luck and I know that some significant new changes are on the horizon for them. I will keep watching from a distance, and I thank them for the most fun years of my life.

This blog will continue as usual, and I am currently working on the fourth part of the SDB series. Thank you for your continued readership and support!