by Z98 | September 9, 2013
Since the last newsletter Giannis Adamopoulos has completed his development contract and while a more formal report will be published later, a brief summary follows. The fruits of his labor are already visible in that explorer_new can actually start in ReactOS and allow a user to browse the directories. Much of this was achieved by completing work Andrew Hill started. Giannis also spent considerable amounts of time trying to understand how the various menus in the shell worked.
Shell menus are actually toolbars and they support not only the menus one sees in the file browser but also the entire start menu. Shell menus are remarkably flexible in that they can accept not only menu objects but also folder objects as input for populating menus. Also because they are toolbars, it is possible to drag and drop items in a shell menu. With some help, Giannis has managed to map out internally how shell menus are implemented in shell32 and developed some tests to for them. The next step will be to actually implement the shell menu classes.
It should be noted that there is still a lot of work to be done before ReactOS possesses a shell comparable to functionality and stability as that on Windows. There is so much missing that it is a downright miracle that the current shell provided as much functionality as it did and the responsible developer Martin Fuchs should be applauded. Giannis' immediate focus is on getting more GUI elements completed so that explorer_new will at least look passable. Beyond that, he has quite a few choices on what to tackle next.
Emergency Management Services
One of the lesser known features of Windows by regular users is the ability to connect and control Windows via a serial port using the Emergency Management Services. EMS was introduced in Windows Server 2003 and Alex Ionescu has been implementing it for ReactOS. EMS provides access to the Special Administrative Console, which is a kernel-provided command prompt that supports anything one might normally do using a command prompt in an interactive login and then some.
One of the key advantages of EMS and SAC is that they do not need a working set of video, keyboard, and mouse drivers in order to control a ReactOS install. This ability would be useful in a variety of ways. For example, currently the regression tests rely on a variety of virtual machine hooks in order to track progress. If everything needed could be reached over serial, then there would be no need to rely on these hooks. Another more intriguing possibility is making it easier to bootstrap ports to different platforms such as ARM. Serial is pretty much universal and the ability to use it to completely control a ReactOS install would alleviate the need to get fully working video and keyboard/mouse drivers just to test various basic functionality.
While the backend components and interface for EMS and SAC have been completed, a few other pieces still remain. The user mode service that SAC needs to provide the full functionality of the command prompt is still needed for example. Enough however is working that EMS can now be tested by selecting it as a boot option.
SVCHOST is an interesting little component. It provides the ability for multiple services to all run in the same process to reduce resource usage. ReactOS had a very primitive implementation that had no security, no thread safety, and even leaks the services it loads. Alex decided to rectify this situation and developed a proper implementation, with the following qualifier in his own words, "the best part: 20% more malware will run."
There are several aspects of SVCHOST that makes it useful to malware developers. As services run by SVCHOST are DLLs, a malicious DLL that is snuck into a system and then loaded by SVCHOST is much harder to detect. First and foremost, the registry keys that control loading of SVCHOST hosted services are more obscure than ones controlling things like startup at login. Next, because SVCHOST loads the services as DLLs, the only visible process is that of SVCHOST itself. Furthermore, once the DLL has been loaded, it no longer appears as in-use from the perspective of the operating system and can be deleted, thus eliminating another indication of the malicious code's presence. Some of the more advanced malware out there takes advantage of these characteristics via a pseudo-legitimate DLL in order to get loaded by SVCHOST, a vector of attack that ReactOS is now also vulnerable to. At the same time, there is nothing wrong in and of itself with SVCHOST's design. The problematic characteristics mentioned above are inherent to SVCHOST achieving its stated function, which is to allow for running multiple services in a single process to conserve resources. One cannot achieve that functionality without also presenting the vector of attack and not providing the functionality at all is not an option if ReactOS wishes to be a credible implementation of NT5.2. Having this vector would also be useful to security researchers as it allows them to use ReactOS to model more threats. At the very least, it would make putting together a malware aquarium cheaper considering the cost of Windows licenses.
Most native developers on Windows will be very familiar with the CreateProcess function as it is the means by which a new process is spawned by one's program. Compared to its Linux/Unix counterparts, CreateProcess offers a significant amount of control in the actual creation process, from setting the authority level to compatibility flags. The previous implementation of the CreateProcessInternalW function that actually did the work of processing and applying the supplied options was based on Windows 2000, which was fine when the project's goal was compatibility with NT5. As the current target is NT5.2, that implementation was no longer sufficient. To that end, Alex has produced a new implementation that respects considerably more of the flags and parameters that are passed in. In addition to proper support for things like compatibility flags, execute options such as page size and debugger keys, and security settings, Alex has also taken advantage of improvements to path handling in NTDLL and the runtime library in the new implementation. Not only is the new implementation more functionally correct, it also lays the foundation for further work in the various compatibility systems needed to support older applications such as NTVDM and SxS.
Windows DLL Loading
One of the more understated goals of ReactOS is the ability to use DLLs from Windows, a goal that Alex took major steps towards achieving recently. It is now possible to boot ReactOS using unmodified kernel32 and/or ntdll DLLs from Windows 2003 SP1. This achievement is the culmination of a fairly lengthy effort by Alex fixing a variety of issues in how the Client/Server Runtime Subsystem interacted with various system DLLs and the services these DLLs called upon. The importance of this achievement comes in many forms. Having the ability to use Windows DLLs in ReactOS will allow for much better understanding of why things fail or succeed in comparison to ReactOS' implementation. Differences that emerge can be directly tracked to the respective components based on what was replaced and what was left in place. Furthermore, Windows' DLLs all have public debugging symbols that can be used to examine their interactions with ReactOS' own components, allowing for better understanding of how the two pieces are supposed to work together. At the same time, the indirect implication is that any DLL on ReactOS that can be replaced by its Windows counterpart could in theory go the other way with the ReactOS version being dropped into a Windows 2003 SP1 installation. The same types of testing and examination can then be performed to see if ReactOS' DLLs are interacting with the other OS components properly.
To take advantage of this achievement, Pierre Schweitzer and Olaf Siejka have put together additional testbots that allow for using Windows 2003 SP1's ntdll when running regression tests. These will allow for comparisons between the baseline ReactOS and a version that theoretically will better mimic Windows 2003 SP1. Together, this should help developers discover subtle variations and bugs and help further increase ReactOS' compatibility.