Back in August of 2007, NeoSmart Technologies released iReboot 1.0 – a tiny application that sits quietly and unobtrusively in the taskbar and is used to select which OS you’d like to reboot into.
iReboot isn’t by any means a major application, but it’s gathered a pretty strong following over the months, mostly by people interested in boosting productivity (or increasing laziness) to the max. But there was one flaw in iReboot that made all the hard work we put into making it as unobtrusive and minimalistic as possible almost meaningless: if you had UAC enabled, iReboot will not run automatically at startup, no matter what you do.
This behavior comes as a result of the architecture that Microsoft used to secure Windows Vista, which doesn’t allow for applications requiring admin approval to run at startup. It doesn’t matter what your application does or if you absolutely trust it beyond the shadow of the doubt, Windows Vista simply won’t let an application that runs in elevated privileges mode to launch at startup – end of story.
Users of iReboot were quick to point out that this is a major drawback that made it almost useless – after all, it’s far less productive to have to manually run an application when you want to reboot than it is to wait for that startup screen to appear and select the OS you want. So we set about finding a solution.
We’ve just released iReboot 1.1, a UAC-free implementation that doesn’t require admin approval, elevation, etc. past the initial installation. And, yes, it does run automatically at startup too!
The Gory Details (feel free to skip below to the download links!)
In order for iReboot to be of any use, we had to get around Microsoft’s UAC limitations. For iReboot, it was of the absolute importance that it run at startup, and that it be allowed system access from normal user accounts. On Windows XP – where everyone runs as an Administrator and there are no annoying UAC prompts – it was a non-issue. But on Windows Vista, the new architectural requirements for running applications in elevated privilege modes made it near impossible.
While digging around for possible solutions, it became clear that the only possible fix would be to split iReboot into two parts. One would run in the background as a service, running under the SYSTEM or LOCAL SERVICE accounts and having privileged access to the OS without requiring admin approval or UAC elevation, and with the second half running as an unprivileged userspace client program which interacts with the service backend to get stuff done.
The resulting application has an installer – which requires admin privileges, of course – which installs and launches the background service. The background service has full permission to do what we need to get operating system XXXX to be the default option for the next boot, but – in line with the Windows Service Model – cannot be interacted with by end users.
The installer also adds a normal UI application which sits in the taskbar (from where end-users may interact with and use iReboot) and communicates with the backend service via a custom API which must not require the execution of any privileged code. The service can do whatever it wants (well, whatever we want it to do, but lets not get picky here!), but the client program must only perform actions which normal, unprivileged users have permission to execute.
By using a standard inter-process communication API we avoided the need for any special actions on behalf of the client application, effectively separating logic (residing and executing on the backend service, free from the many limitations of UAC) and presentation/design (the client application, bound to obey UAC’s every wish).
The Bottom Line
Anyone running Windows XP or Windows Vista – with or without UAC and/or admin approval mode enabled – can now run iReboot at startup and use it to boot into whatever OS they like (in conjunction with EasyBCD, of course!).
But getting this far wasn’t easy. With Windows Vista, what should have been 100 lines of code maximum ended up being a dozen times longer, split across two different processes, and requiring way too much man-hours to write the most minimalist and to-the-point piece of software we’ve released to date.
Perhaps most importantly though, is the fact that Windows Vista’s newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security. Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relative) ease. The "architectural redesign" of Vista’s security framework isn’t so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.
With the current Windows Vista security models, Microsoft can claim that Vista blocks system-modification tools from running at startup; but the truth is, there are still many ways to get them to run. At the end of day, our experience with iReboot and Vista’s security implementations brings us to the sad conclusion that with Windows Vista, Microsoft has made ISVs’ jobs more complicated without actually providing any any further protection for end users from malware authors – which certainly isn’t the best way of going about this task.
Anyway, the fruits of our efforts:
Download iReboot 1.1 (248 KiB)