How Microsoft Windows Vista’s Sidebar was hacked for Windows XP Educational purposes -- My answer to people when they ask why we‟re doing what we‟re doing. Through reverse engineering, we have learned a tremendous amount about the target and the platform of which it sits upon. I could go on and on regarding the subject, it‟s that exciting, but I won‟t. Here‟s how we hacked the Windows Vista Sidebar and what we‟ve learned from doing so.

Revision History November 25, 2005 – Initial release

Tools Freeware LordPE Deluxe - http://scifi.pages.at/yoda9k/LordPE/info.htm OllyDbg - http://www.ollydbg.de/ XVI32 - http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm Bsdiff/bspatch - http://www.daemonology.net/bsdiff/ IDA Freeware - http://www.google.com/search?q=IDA+4.3+Freeware Shareware / Commercial Microsoft Visual Studio .Net 2003 - http://www.microsoft.com/vstudio SiComponents Resource Builder - http://www.sicomponents.com

Log ZoRoNaX and I (we henceforth), did what everyone did – Double-clicked the Sidebar executable and prayed for forgiveness. Whoa, let’s rewind a tad. Sidebar executable you ask? You may recall that some “enthusiasts” at PDC ’05 nabbed the Sidebar executable (and its related parts) off of public Vista terminal and shot it into the whirling vortex we like to call the Internet. It’s out there, I’m sure you’ll find it. Back on topic, we were presented with this horrible error:

Figure 1 - The evil "Entry Point Not Found" error Seeing this error was not good. From this error alone, we came to the conclusion that the msvcrt.dll library had changed in Vista, toting new functions not on any other platform. Damn. After some Google-ing, it appeared this CxxFrameHandler stuff is related to internal exception handling routines. Pfft. Whatever. With our hands over our eyes, only peeking to dismiss trial windows and generic warnings, we fired up the freeware version of IDA Disassembler and opened the bastard library and located this exported function. NOTE: In IDA Freeware, there is no “Exports” tab, so just use the “Names” tab. It‟ll do just fine.

After finding our function and double-clicking on it, we found a sign of hope!

Figure 2 - CxxFrameHandler Function Disassembly (msvcrt.dll on Vista)

As you can see above, the __CxxFrameHandler3 exported function seems to share the same code as __CxxFrameHandler2 and __CxxFrameHandler. Opening up the library on a non-Vista machine (Windows Server 2003 x64), we noticed it didn‟t have an export of __CxxFrameHandler3.

Figure 3 – CxxFrameHandler Function Disassembly (msvcrt.dll on non-Vista)

It appeared to be safe to just change the imported __CxxFrameHandler3 to __CxxFrameHandler, so we did just that with LordPE.

Figure 4 – Editing of __CxxFrameHandler3 import in LordPE

After making the necessary changes, we saved our changes and closed LordPE. We then repeated the ritual of closing our eyes and double-clicking the new executable…

Figure 5 – One of the evil “Procedure Entry Point” errors We knew that was too easy, unfortunately this new error confirmed our suspicions from the beginning – New code was being accessed. As shell32.dll is not something you can just overwrite on the older non-Vista platform without worry, we figured the only way we could make this work is to create our own SHGetFolderPathEx() function. Pasting the name of the function in Google, we found some lovely preliminary documentation on the beta (at the time) msdn2.microsoft.com site (http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/ShellCC/platform/shell/reference/functions/shgetfolderpathex.asp). We had enough information to build a stub dynamic link library, but we had to dig deeper to figure out what GUIDs we should be expecting. After a few nights of pounding our heads into the hotel provided desk, we built a shiny new stub dll that took in the correct parameters and dumped them to fi le (Sidebar was not happy with this). After analyzing the data, we came to the conclusion that we would only have to write code to process two specific GUIDs: {A75D362E-50FC-4FB7-AC2C-A8BEAA314493} Sidebar Parts Directory {7B396E54-9EC5-4300-BE0A-2482EBAE1A26} Sidebar Default Parts Directory If you‟re wondering how we figured out the meaning of the GUIDs, don‟t. We merely searched the registry.

With the new GUIDs in hand, we were ready to write the rest of the code! The code we wrote required a lot of troubleshooting and debugging; we‟re not ready to release it yet, sorry, besides it‟s beyond the scope of this document. Here‟s a tip if you decide to try and write your own library – Keep the stack in mind, in terms of cleanup! Ok, we cranked out a new dll using Microsoft Visual Studio (although anything that compiled would‟ve worked) containing code to emulate this function. Now what? We tied it into Sidebar, of course. That‟s easier said than done, however. You can‟t just rip out the imported function and replace it with our own, so we had to hack it a bit. We renamed the SHGetFolderPathEx() import to SHGetFolderPathA(), injected our dll and import, opened the Sidebar executable in OllyDbg, and changed the call to the renamed SHGetFolderPathA() function to point to our shiny new SHGetFolderPathEx(). Sounds confusing, I admit, hence why pictures were provided.

Figure 6 – Renaming of SHGetFolderPathEx import to SHGetFolderPathA (seen within LordPE)

Figure 7 – Adding of new SHGetFolderPathEx import from new library (seen within LordPE)

Figure 8 – New injected import (seen within OllyDbg)

Figure 9 - Old import (renamed) (seen within OllyDbg)

Figure 10 - Before: Jump to renamed import (seen within OllyDbg)

Figure 11 - After: Jump to new import (seen within OllyDbg)

After all that work, we saved our changes and closed OllyDbg, LordPE, and all the other windows to prepare for our finale. We double-clicked the executable and… nothing happened. What the hell? (note to reader – on some machines, we received a nasty heap error). Fiercely throwing the executable into OllyDbg and executing line by line, we noticed last_err (right-hand side) was being set to ERROR_RESOURCE_NOT_FOUND. Opening the executable in Resource Hacker, we noticed a lot was missing, to include the background image! After monitoring the execution of Sidebar on a Vista machine with Sysinternal‟s File Monitor, we found the missing resources in the MUI fi le for Sidebar. Doh! Anyone that has used Resource Hacker extensively knows how much of an annoying piece of crap it is, especially when it comes to extracting resources. After searching the internet for a bit, we came across an interesting program: SiComponent‟s Resource Builder.

We dragged the MUI into the program and were greeted by a resource import feature.

Figure 12 - Import Resources (seen from Resource Builder)

Neat. Seeing as the executable already had ICON, VERSION INFO, and MUI resources, we omitted them in the import. After importing the selected resources, we dragged the executable into the program and were again greeted by the same dialog. We selected everything, this time. After clicking the OK button, all the resources were nicely meshed together. Let‟s link this to the executable by clicking Tools > Link to EXE…

Damn. As we weren‟t sure this entire project would even work out in the end, we sought a free workaround. We saved the blob of resources into a neat .res file, ready for import into our executable. Well, I‟ll be damned; Resource Hacker saves the day, after all. Reading the help files, we found a command line method to update the resources.

Figure 13 - Resource Hacker Help File Blatantly stealing that line and just changing the fi le names to meet our criteria worked out. After executing that line (in a nifty batch file with a pause to make sure no errors were displayed), we opened up the executable again in Resource Hacker and saw our beautiful resources. Drum roll please… Getting hungry for success, we double-clicked our executable and received a nasty error; too nasty to include in this document. Fortunately, we planned for this to happen. Due to the crap nature of LordPE, our injected code was inserted into a new section after the resource section (see PE file structure). After manipulating the resource section with Resource Hacker, it‟s sized changed and appeared to have corrupted our code. How did we fix it? We started over, importing the resources first, then inserting our code and making the necessary changes. I purposely laid out our steps in the incorrect order for you to feel our pain. You‟ll live. After redoing everything, in a much faster pace the next go around, we executed Sidebar and lo‟ and behold it loaded.

Cleanup Having a working Sidebar on a non-Vista platform felt awesome, but we wanted to share our work with the public, and do so without receive „cease and desist‟ letters from Microsoft Corporation. We utilized bsdiff/bspatch, both GNU licensed, to generate simple diff-like patches based on the original executable and to apply them. The other Microsoft binaries (e.g. xmlrw.dll) were stripped and documented in the README as required files.

Afterthoughts Now knowing that the project was a success, I went ahead and purchased a license for SiComponents Resource Editor for a mere $99. I am now eligible for unlimited free updates for life (probably until they go to v3). Using the link to executable feature worked brilliantly and cut down the amount of work needed! I strongly recommend it.