As mentioned in my previous post, I have been working on incorporating some more features into WinVer.nsh. Every little change in this header file requires testing on all possible versions and configurations of Windows. Being the Poor Open Source Developer^TM that I am, I do not have sufficient resources to assemble a full-blown testing farm with every possible version of Windows on every possible hardware configuration. Instead, I have to settle for a bunch of virtual machines I have collected over the years. It is pretty decent, but has no standards and doesn’t cover every possible version. Still, it does its job well and has proven itself very effective.

Obviously, be it a farm or a mere collection of virtual machines, testing on so many different configurations carries with it a hefty fine. Testing a single line change could waste almost an hour. Imagine the time it would take to test, fix, retest, fix and retest again a complete rewrite of WinVer.nsh. As fascinating as that empirical scientific experiment would have been, I was reluctant to find out. Laziness, in this case, proved to be a very practical solution.

WinVer.nsh tests do not really need the entire operation system and its behavior as it relies on nothing but 4 parameters. All it requires is the return values of GetVersionEx for OSVERSIONINFO and OSVERSIONINFOEX. For nothing more than 312 bytes, I have to wait until Windows Vista decides it wants to execute my test, Windows NT4 gracefuly connects to my network, Windows ME wakes up on the right side of the bed and doesn’t crash, Windows Server 2008 installs again after its license has expired and Windows 95…. Actually, that one works pretty well. So why wait?

Instead, I’ve created a little harvester that collects those 312 bytes, ran it on all of my machines and mustered the results into one huge script that tests every aspect of WinVer.nsh using every possible configuration of Windows in a few seconds. It required adding a hooking option to WinVer.nsh, but with the new !ifmacrondef, that was easy enough.

Currently, the script tests:

• Windows 95 OSR B
• Windows 98
• Windows ME
• Windows NT4 (SP1, SP6)
• Windows 2000 (SP0, SP4)
• Windows XP (SP2, SP3)
• Windows XP x64 (SP1)
• Windows Vista (SP0)
• Windows Server 2008 (SP1)

If you have access to a configuration not listed here, please run the harvester and send me the results. More specifically, I could really use Windows 2003 and Windows Vista SP1. My Windows Vista installation simply refuses the upgrade to SP1. Again.

The test script also includes a hexdump of those 312 bytes for every configuration so anyone performing similar tests for another reason doesn’t have to parse the NSIS syntax. Feel free to use it for your testing.

Last week I’ve decided it’s time to apply a few long overdue patches some people have submitted. The main issue with patches is that the patch submitter and patch applier are never the same person, unless you’re on lithium in which case the code is bound to be intriguing any way you spin it. But the lack of clear coding guidelines or my code review process is a whole other topic.

One of the patches was Anders’ WinVer.nsh patch for Windows Server 2008 support along with some other nifty little features. You would think this would be a pretty simple patch, but Microsoft had a surprise for us in this case. I admire Microsoft for their dedication for backward compatibility and basic API coherence, but in this case of version detection, they got it a bit mixed up. There are three API functions to get the version, two of them work on all versions of Windows and one of them has two operation modes. To get special features information there’s another completely unrelated inconspicuous function. The format of the returned data depends on the version and on operation mode used. In short, it’s a bag full of fun and games and there’s never a dull moment testing every little change on every possible configuration of Windows.

For the original version of WinVer.nsh, I used the simplistic GetVersion API which requires about 3 lines of code. Later on a patch was submitted to support verification of service pack numbers which required the usage of GetVersionEx’s two modes of operation. This required quite a bit more code, but that code was only used when SP were specifically checked. With the latest patch for Windows Server 2008 support, the simplistic API was no longer enough and a full blown function using every possible API and doing a lot of math and bit shuffling was required. And therein lies the catch.

As we yet to have developed real code optimization mechanisms, code duplication makes the installer bigger and bigger is not better in this case. The code could go into a function which will be called by every usage of WinVer.nsh, but that would mean a warning will be generated in case the function is never called because it can’t be optimized. A requirement to declare the usage of WinVer.nsh could be added, but that would break the number one rule I’ve learned from Microsoft – backward compatibility. All three issues are on the top 10 frequently asked questions list and getting my costumers a reason to ask them even frequently-er is not in my wish list.

As the code size grew bigger WinVer.nsh, I started pondering of a way to solve this. The obvious solution would be adding code optimization and that’s already functioning neatly in my beloved nobjs branch that’s sadly not yet ready for prime time. And so I had to think of another idea that could work with the current branch and so Artificial Functions were conceived. Instead of letting the compiler create the function, I’ve used some of the lesser known features to create them on my own. A combination of runtime and compile-time black magia using both old and new features allowed me to get rid of the code duplication.

To make sure the code of the function isn’t inserted more than once, the good old !ifndef-!define-!endif combo is used. But the function can be called from more than one scope and so it must be globally locatable. Exactly for this purpose, global labels were added over six years ago. However, that’s not all as the function must somehow return control to the original code that called it. To do this Return is used at the end of the function’s code and Call is used to treat the global label as a function and build a stack frame for it. Last but not least, we have to do deal with uninstaller functions that can’t jump to code in the installer as they don’t share the same code. The new __UNINSTALL__ definition saves the day and helps differentiate installer’s and uninstaller’s code.

!macro CallArtificialFunction NAME
  !ifndef __UNINSTALL__
    !define CallArtificialFunction_TYPE inst
  !else
    !define CallArtificialFunction_TYPE uninst
  !endif
  Call :.${NAME}${CallArtificialFunction_TYPE}
  !ifndef ${NAME}${CallArtificialFunction_TYPE}_DEFINED
    Goto ${NAME}${CallArtificialFunction_TYPE}_DONE
    !define ${NAME}${CallArtificialFunction_TYPE}_DEFINED
    .${NAME}${CallArtificialFunction_TYPE}:
      !insertmacro ${NAME}
    Return
    ${NAME}${CallArtificialFunction_TYPE}_DONE:
  !endif
  !undef CallArtificialFunction_TYPE
!macroend

When combined all together, it not only solves the code size issue for WinVer.nsh, but also rids the world of two very frequently asked questions about our standard library. It took a few good hours, but after converting FileFunc.nsh, TextFunc.nsh and WordFunc.nsh to use the new Artificial Functions; there’s no longer a need to use forward decelerations for those commonly used functions and calling them in uninstaller code is no different than calling them in the installer.

!include "FileFunc.nsh"
!insertmacro GetFileExt
!insertmacro un.GetParent
Section Install
     ${GetFileExt} "C:\My Downloads\Index.html" $R0
SectionEnd
Section un.Install
     ${un.GetParent} "C:\My Downloads\Index.html" $R0
SectionEnd

Goes on a diet and elegantly transforms into:

!include "FileFunc.nsh"
Section Install
     ${GetFileExt} "C:\My Downloads\Index.html" $R0
SectionEnd
Section un.Install
     ${GetParent} "C:\My Downloads\Index.html" $R0
SectionEnd

I love it. This trick is so sinister. It reminds me of the days Don Selkirk and Dave Laundon worked on LogicLib. Coming to an installer near you this Christmas.

9 out of 10 open-source experts advocate frequent releases. We, the simple people, don’t know better and should listen to the experts. Sadly, we simpletons still don’t know how to read and so the fine print eludes us. While we all may be good and obedient developers, the users don’t care for our frequent releases squashing our colossus bugs and featuring our shiny new toys. As frequent our releases are as frequent the reports of bugs long ago fixed and features that shined and sparkled at ancient times but are now filled with rust.

Ghost versions of the past haunt us daily while users refuse to upgrade. Our innovative forefathers, suffering immensely from this plague, had uncovered the great potential of automatic updates. No longer is the user able to flee his ordained destiny. Fate shall pop-up and fulfill itself even with the absence of user interaction.

But even this sparsely applied method carries its own set of fine prints. Boiler plate implementation includes a web server containing the latest version number or even a server-side script that ever so nicely checks for the user whether his version is expectedly old. As with everything else, here too success brings failure. As faithful users gather their masses around our monthly-polished releases, the web server begins to break down. Most web servers, especially those that poor open-source developers can afford, do not offer load balancing and will easily succumb to the sheer amount of bandwidth generated by thousands of users performing even the simplest of GET requests.

Enter DNS. The Domain Name System is a distributed and globally cached system that basically maps domain names such as nsis.latest-version.org into numbers such as 2.36.0.0. And it gets even better — foreign sources report there are free DNS servers out there, waiting to be used. Services such as dyndns.org offer a simple HTTP based API that sets new IP to a free domain name. Creating a new version notification service is as simple as creating a new free domain, updating it every time a new version is released, calling inet_addr when the client-side loads and comparing the result to the current version.

This free and simple solution provides many advantages over conventional HTTP based version check.

• Automatic load balancing with servers all over the world.
• Simple code with no need for complex HTTP libraries.
• No need for relatively heavy HTTP operations for both client and server.
• HTTP proxies do not get in the way.
• Firewalls and the entire security fiasco usually overlook DNS.

And as always, there are disadvantages.

• Updates take time to propagate.
• Only 3 bytes of information.

Make sure you set the first byte to 127 to make sure the IP associated with your update domain is invalid. This way, whoever is at 2.36.0.0 won’t get any unwelcome traffic.

I am probably not the first to think of this, but it is a cool idea nonetheless. I’m so going to implement this for the next version of NSIS!

Over a year has passed since the NSIS Media menace. Mostly good things have happened since. I figured this could be a good time to recap and summarize.

• Download.com no longer contains NSIS Media infected downloads. I’ve received no response for my queries, so I assume I had nothing to do with it.
• NSIS Media malware update servers are no longer operational.
• I have received only one e-mail complaining about NSIS Media over the last year, compared to the dozens before I’ve released the remover.
• My remover was downloaded approximately 10,000 times from my website and probably a bit more from other websites as well.
• My lawsuit has failed miserably. I was trying to get back at Opensoft/Openwares and all of their Vanuatu-based friends with the help of the Software Freedom Law Foundation. We tried to track down someone we could sue, but failed. After a few unanswered queries and answers pointing at multiple directions from various related companies, the search was sadly brought to a halt.
• I was contacted by F-Secure for details of NSIS Media. I seem to recall there were more companies that asked for my help, but I can’t find the e-mails proving it.
• Most anti-virus or malware removal applications I’ve tested find only the most common infections of NSIS Media and skip the rarer DLL files.
• Opensoft is still up to no good.
• Openwares is still alive and kicking, spreading malware and using NSIS but no sane user will surf to that website.
• I have received no donations for my research or for creating the remover.
• I still don’t make 1000$ a day

So there you have it — the story of a deceased malware. I’d like to think I took at least a small part of its demise.

Ladies and gentlemen, we interrupt the silence schedule to bring you shocking news. Hatred has reared its ugly head on the forsaken grounds of our dear old friend — Windows 98. It appears the bigots have set a new target for their cynical and non-politically-correct persecution. Big-boned dialogs and initialization-limited rectangulars are shamelessly discriminated against and abused for no acceptable reason. Exceptions, overflow errors, division errors and antique dialogs were thrown at the victims, reports say. We were unable to get comments from the alleged bigots.

We were unable to get pictures from the event, but luckily, it can be easily reproduced.

BOOL CALLBACK proc(HWND h, UINT m, WPARAM w, LPARAM l)
{
  return FALSE;
}
int main(int argc, char* argv[])
{
  char dt[24] = {0,};
  RECT r = {32757,};
  HWND dlg = CreateDialogIndirect(
    GetModuleHandle(NULL),
    (LPDLGTEMPLATE) dt,
    0,
    proc);
  MapDialogRect(dlg, &r); // BOOM!
  return 0;
}

I had some fun today trying to figure out why Banner likes to hang around with .NET so much so it wouldn’t even leave. I found out that while being destroyed, something tries to send messages to the main dialog. But the main dialog is busy with destroying the banner. I added exactly two iterations of the famous win32 message loop and everything started working. I still don’t know why those messages are sent or why it’s so important they’ll be answered before the banner is destroyed or even why it happens just with the .NET installer. And don’t even ask about different synchronization methods that make it tick. So far, I’ve found only smoke signals and the fire extinguisher won’t last much longer.

Of all the signals, I liked the message loop the most. It actually points to something I’ve done wrong. I’ve starved the main dialog’s thread while creating a modeless dialog as its child. That’s why I dug in further into those two iterations of the loop and those two messages that it processes. It turns out both of them had the same identifier – 0xc0c3. Now that’s no regular WM_ message… That’s a message registered with RegisterWindowMessage. But which message is it? That’s where the fun starts. There’s no GetRegisteredWindowMessage API available and nothing on the topic comes out on Google.

So with no leads to follow I started digging. Normally, to give a certain string a specific value in Windows, an atom is created. And indeed, 0xc0c3 is in the range of named atoms. To make things even simpler, in WINE, RegisterWindowMessage simply calls GlobalAddAtom, casts ATOM to UINT and returns. Great, then GetAtomName or GlobalGetAtomName should do the trick. Only reality isn’t as bright as WINE would like us to think. It turns out RegisterWindowMessage uses a different atom table for its messages. But which atom table and how can you even specify a table with GetAtomName?

To specify a table, a low-level access to RtlLookupAtomInAtomTable is required. But that function is deep inside ntoskrnl.exe. So, up one level and you get NtUserGetAtomName which uses the same atom table as NtUserAddAtom which is the function RegisterWindowMessage calls. But that’s inside win32k.sys… Luckily, user32.dll already handles that. It has a stub that calls NtUserGetAtomName at 0x7E41FA8E. Some playing around with the second parameter which turns out to be UNICODE_STRING and the atomic table is in hands’ reach.

Engines off, coding fingers down, digging complete and the message name is MSUIM.Msg.Private. That too gets little to none results on Google, but who cares… Debugging is fun

For any of you who’d ever want to convert a registered message into a readable name, here’s the NSIS code. Replace 0xc0c3 with the message identifier and 0x7E41FA8E with user32!NtUserGetAtomName and you’re good to go.

# the atom
StrCpy $2 0xc0c3
;System::Call user32::RegisterWindowMessage(t'test_message')i.r2
# create UNICODE_STRING
System::Alloc 1008
Pop $R0
StrCpy $R1 0
StrCpy $R2 1000
IntOp $R3 $R0 + 8
System::Call *$R0(&i2R1,&i2R2,iR3)
# call NtUserGetAtomName
System::Call ::0x7E41FA8E(ir2,iR0)i.r1?e
# parse UNICODE_STRING
System::Call *$R0(&i2.r4,&i2.r3,w.r0)
# print details
DetailPrint "user atom's name is $0"
DetailPrint "length is $4 (???)"
DetailPrint "NtUserGetAtomName returned $1"
Pop $1
DetailPrint "GetLastError() = $1"
# done
System::Free $R0

I tried looking for a newer version of NSIS Media by visiting their latest update server. I came out empty handed, which was bad news for my research but great news for the rest of the world. Just to make sure I got it right, I visited the old update server once again. I was in for a surprise when it served me b10.bin for downloading. As you may recall from one of the earlier posts, I originally downloaded only [ab][1-9]. Seeing as it suddenly served b10.bin, I upgraded my download script and found some more evil files.

atixim.dll
avirpa.dll
javadsa.dll
kbdicp.dll
msabdx.dll
msrrwvb.dll
schuu52e.dll
xmlfef32.dll

I’ve updated my NSIS Media Remover to detect and remove those as well. I’ve also updated the samples archive, though it still doesn’t contain any of the old version DLL files.

I’ve assembled everything I’ve learned the past few weeks about NSIS Media into one simple and effortless application that should completely remove it. NSIS Media Remover removes installed files and registry keys.

• 93 101 known DLL files installed into the system folder
• C:\Program Files\Common Files\NSIS folder
• Firefox nsis.jar extension
• Many registry keys
  • CLSIDs
  • Shell extensions
  • txtfile context menu handler
  • Overlay icon handlers
  • Software\NSIS\Media
  • Software\IAN
  • Add/Remove entry

NSIS Media Remover is provided without any warranty. Its source code is available in the tool itself. Hit the View Source Code button to get it.

Download NSIS Media Remover

md5:  7778c19e9df725d20a30fe42f425589d
sha1: 9eb42afbf75fd97555cc5260b3d24f33a6dec622

While creating this tool, I’ve found more exciting new facts about this pest. One of which is that apparently, CNET were fooled into serving the downloads on download.com. The installers check to see if the computer belongs to download sites, anti-virus companies and even Cydoor prior to installing the pest.

Update: version 1.1 was released on January 13th, 2007 with 8 more files missed in the original research.

While searching for the complete list of registry keys used by NSIS Media, I found yet another update server for an even older version. Only this server seems a bit different, it’s for removal of NSIS Media. Its output contains a URL for an installer that removes a lot of files and registry keys I haven’t ever seen.

auole4.dll
aviprope.dll
brwe042.dll
cabext32.dll
cagt041.dll
cryptdbe.dll
direjmod.dll
dobj01e.dll
dspmode.dll
dsq052e.dll
edk052.dll
iccext.dll
icmmext.dll
mail052e.dll
msgetm.dll
msgsple.dll
msmsgre.dll
mssfdr.dll
ntext052.dll
ntfssetx.dll
prtmde3.dll
shllimgd.dll
slpube03.dll
splsrv4.dll
syncmte.dll
tragte.dll
vidcpl2.dll
vlcx052.dll
wint042e.dll

Expect a complete NSIS Media remover very soon…

I just found another list of DLL files used by NSIS Media. The script used in their updated installers first removes the old DLL files. It renames them to temporary names and deletes all of their registry keys. Along with the previous list, I believe this makes a complete list of all DLL files used by NSIS Media.

bsdeff32.dll
java52e.dll
krnsvr32.dll
mkdesk32.dll
mkdesk32.dll
mscron32.dll
msidext.dll
msrvdrv.dll
msscsi.dll
mssvide.dll
msxmlu.dll
mtxcdru.dll
netstrap42.dll
nvrssid.dll
odbcpc32.dll
oleac32.dll
olescope.dll
uuiedes.dll
windexserv.dll
winsdev.dll
winsdrv.dll
wmbmd.dll
wmddsb.dll
wmdmb32.dll
wmidext.dll
wmproxt.dll
wmsql32.dll
wmudrv.dll

~fdgar.tmp
~fdgdr.tmp
~fdger.tmp
~fdgfr.tmp
~fdgir.tmp
~fdgor.tmp
~fdgpr.tmp
~fdgqr.tmp
~fdgrr.tmp
~fdgsr.tmp
~fdgtr.tmp
~fdgur.tmp
~fdgwr.tmp
~fdgyr.tmp
~isdat.tmp
~isddt.tmp
~isdet.tmp
~isdft.tmp
~isdit.tmp
~isdot.tmp
~isdpt.tmp
~isdqt.tmp
~isdrt.tmp
~isdst.tmp
~isdtt.tmp
~isdut.tmp
~isdwt.tmp
~isdyt.tmp