How Microsoft Windows Vista’

sSidebar was hacked for Windows XP

Educational purposes -- Myans wertopeoplewhent heyas kwhywe‟ r
edoi ngwhatwe‟ redoi ng.Thr oughr ever s
eengi neeri
ng,
we have learned a tremendous amount about the target and the platform of which it sits upon. I could go on and on regarding
thes ubject
,i t‟
st hatexc i
ting,butIwon‟t
.Her e‟show wehac kedt heWi ndowsVi staSi debarandwhatwe‟ velearnedf r
om
doing so.

Revision History
November 25, 2005 –Initial release

Tools
Freeware

LordPE Deluxe - http://scifi.pages.at/yoda9k/LordPE/inf o.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,l et’sr ewindat ad.S idebarexec utableyouas k?Youmayr ecallthats ome“ent hus iasts”atPDC’ 05nabbedt heS idebar
executable (and its related parts) off of public Vista terminal and shot it into the whirling vortex we like to call the Internet.
It
’soutt her e,I’
ms urey ou’llfi
ndi t.

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 Goog le-ing, it appeared this CxxFrameHandler stuff is
related to internal ex ception 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 I
DAFr
eewar
e,t
her
eisno“Expor
ts”t
ab,s
ojus
tus
ethe“Names
”tab.I
t‟l
ldoj
ustf
ine.
After finding our function and double-clicking on it, we found a sign of hope!

Figure 2 - CxxFrameHandler Func tion Disassembly (msvcrt.dll on V ista)

As you can see above, the __CxxFrameHandler3 ex ported function seems to share the same code as __CxxFrameHandler2 and
__CxxFrameHandler. Opening up the library on a non-Vist
amachi ne( WindowsSer ver2003x64) ,wenot i
cedi tdi
dn‟thavean
export of __CxxFrameHandler3.

Figure 3 –CxxFrameHandler Func tion Disassembly (msvcrt.dll on non-V ista)

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-clicki
ngt henewexec utable…

Figure 5 –Oneoft
heevi
l“Pr
ocedur
eEnt
ryPoi
nt”er
ror
s

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 SHG etFolderPathEx() 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 f ew 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-2482EBA E1A26}
Sidebar Default Parts Directory

I
fyou‟
rewonder
inghowwef
igur
edoutt
hemeani
ngoft
heGUI
Ds,don‟
t.Wemer
elys
ear
chedt
her
egi
str
y.
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 debuggi ng;we‟ renotr eadyt or eleaseityet ,sorry,bes idesit‟sbey ondt hes copeoft
hisdocument .Her e‟sat ipifyou
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 VisualSt udio( al

thoughany thingt hatc ompiledwould‟ veworked)containing code
to emulate this function. Now what? We tied it into Sidebar, of course. That ‟
seas iers ai
dt handone,however .Youc an‟tjus t
rip out the imported function a nd 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 chang ed 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 w ithin LordPE)

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

Figure 8 –New injec ted import (seen w ithin Olly Dbg)

Figure 9 - Old import (renamed) (seen within Olly Dbg)

Figure 10 - Before: Jump to renamed import (seen w ithin Olly Dbg)

Figure 11 - After: Jump to new import (seen w ithin Olly Dbg)

After all that work, we saved our changes and closed O llyDbg, LordPE, and all the other windows to prepare for our finale. We
double-cl ickedt heexec ut
ableand… 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
backgr oundi mage!Af termoni toringt heexec uti
onofSi
debaronaVi s tamac hinewi thSy s
internal ‟
sFi l
eMonitor, we found the
missing resources in the MUI file 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 forabi
t,wec
ameac rossani nterestingpr ogr am:Si Component ‟sRes our
ce
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 ICO N, 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,t histi
me.Af terclicki
ngt heOKbut ton,allther esourceswer eni celymes hedt ogether .Let‟sli
nkt histo
theexec utablebycl ickingTools>Li nktoEXE…

Damn.Aswewer en‟ts uret hisent ir

epr ojec twouldevenwor kouti ntheend,wes oughtaf r
eeworkaround. We saved the blob
ofr esour cesintoaneat. resf ile,readyf orimpor ti
ntoourexec ut
abl e.Wel l
,I‟llbedamned;Res ourceHac kersavest heday ,
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.

Dr
um r
ollpl
eas
e…

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 t
her esources ection( seePEfi l
estruc ture).Aftermani pulati
ngt her es ourcesec t
ionwi thRes ourceHac ker
,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‟
llli
ve.After redoing everything, in a much
fasterpacet henextgoar ound,weexec utedSi debarandl o‟andbehol di tloaded.

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 „ceas eanddes ist‟lett
ersf rom Mi crosof tCorporation.Weut il
izedbs diff
/bs pat
ch,bot hGNUl i
cens ed,t o
generate simple diff-like patches based on the original executable and to apply them. The other Microsoft binari es (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 strong ly recommend it.