[archived] Previous, now Deprecated Whonix Windows Installer Testing

[Ego]

Comment: The following is a previously private discussion which was made public after the initial release of the Whonix-Installer and UI.

Good day,

So as some of you may recall, about half a year ago, I tried to create a custom installer which was supposed to make starting out with Whonix easier for newcomers. Now, since then original thread for this project ([archived] Previous, now Deprecated Whonix Windows Installer) hasn’t really been updated that much to be honest. The reasons for this were plentiful, as well as (partially) not really in my control. Some where based in the initial choice of programing language, some where actually created by Oracle/VirtualBox, who without telling the community, quietly changed some aspects of their installer, making anything based on there software rather unpredictable, some actually on part of Microsoft and there incapability of fixing bugs in regards to msiexec, instead recommending some rather obscure ways arround the issues (Waiting for msiexec.exe to Finish - Visual Studio Setup) which sadly didn’t work for me, some where rooted in the fact that Whonix sadly isn’t the smallest thing in the world and thus a lot of tinkering was necessary as every free and open setup solution only supports up to 2GB in filesize, some where rooted in the fact that I really did want to minimize the input required by a user and also insisted on delivering the whole thing as one singular .exe which limited me in quite a few ways, some where rooted in the fact that making this project possible for users who already had VBox installed in some way create some massive issues, some in certain details regarding Whonix and VBox (the EULA for example made using VBoxManage for the import almost impossible, which lead me to thinking about actually creating and maintaining seperate images for this project…), some where rooted in the fact that a lot of private things happend in the background and one was rooted in the fact that I don’t really have the most efficient work moral…

Long story short, it took quite a massive amount of experimentation (far more than I would have imagined for simply bundling a few installers, drivers, certificates, after-install-scripts and files together) but I’ve finally been able to create the promised installer including all the features I intially proposed and then some.

You may find it once fully published here: GitHub - EgoBits1/Whonix-Windows-Installer-deprecated: The intial version of a simple, Installer for Whonix, Whonix-UI and accompanying software. Based on NSIS and 7-Zip, not maintained.

Github sadly timed out just before reaching the 3,5GB mark. Thus uploaded it to mega: MEGA

It would be great if one or two of you could perhaps test it before it gets deployed. The Github project also contains a signature and my public key for verification.

Now, here a list of what my solution is capable of:

• Let’s user set install folder for everything in one go (including VBox, etc)
• Requires just three clicks to install everything (including importing and setting up WS and GW in VBox)
• Bundled into one single file
• Asks only once for UAC
• Very heavily compressed
• Comes with an easy to use uninstaller
• Bypass Oracles limitations in regards to where and how VBox may be installed
• Uninstaller removes everything (including VBox, the Whonix images created and imported by the installer and anything stored by the user) as good as is possible on Windows without overwriting hard drive multiple times
• Will be bundled with simple user interface allowing easy launch of GW and WS (to be finished (Placeholder is included as “whonix.exe” to test start menu inclusion)
• Works on both x64 and x86 and selects correct version of VBox, etc without needing user input
• Is easily “adaptable” for when Whonix 14 is finished
• Bypasses 2GB size limit imposed by “nullsoft scriptable install system”
• Includes a very basic “bin file checksum verifier”
• Based soly on free software (NSIS is under zlib/libpng and 7zip uses GPL)
• Existing installations of VirtualBox are automatically upgraded to the version included and existing images/virtual hard drives are in no way compromissed/modified/removed even when the user changes the install folder for VBox

Now, like mentioned before, it would be great if one of you (or more) could perhaps test this installer before we deploy it so any more problematic bugs can be found.

Furthermore, there are two “features” I’m still thinking about including.

First of all, though this isn’t really a feature, I’m thinking about changing/improving the design of the installer. This is what currently is being used:

While it is functional, it is also very basic.

Something like this might improve matters a bit:

Secondly, I had the idea of maybe creating an automated verification process which would make manually verifing the images not necessary anymore. However the question would be how such a thing could be implemented properly. If an attacker has the ability to modify the images, than modifying the keys would also be possible. They’d have to be delivered seperatley from a server, though how can one prevent an attacker from rerouting the query to said server? Anyways, as mentioned before there is a basic integrity check already though I wouldn’t trust it to much.

Also, I’m still attempting to automate the import of the necessary certificates by Oracle. Sadly the only way I could find requires additional software by Microsoft which due to licensing I am unable to bundle with this installer.

Adding to that, the command prompts while extracting and importing the gateway and workstation files are just temporary, mainly so I am able to monitor whether something actually happens during that time. I had spent so long looking for an error when in reality certain commands weren’t even executed that I found that to be a necessity. Whether these should actually be removed remains to be decided as an argument could be made that users should be able to observe the installation process as detailed as possible.

Anyways, I hope that what I’ve created works properly and if you have any suggestions on what could be added/changed/improved, just let me know. I didn’t want to post this publicly as any obvious issues should probably be found before deploying this…

Have a nice day,

Ego

P.S.: On certain systems, it takes a bit of time to start. Not sure whether my hard drive is at fault or whether my SFX is simply compressed with an ineffizient format.

---

Dev/Windows Installer

[Patrick]

Great developments! I can imagine how frustration tolerant someone has to be for development on the Windows platform.

The installer downloads Whonix images from whonix.org during installation or are them built into the installer?

@Ego

Secondly, I had the idea of maybe creating an automated verification process which would make manually verifing the images not necessary anymore. However the question would be how such a thing could be implemented properly. If an attacker has the ability to modify the images, than modifying the keys would also be possible. They’d have to be delivered seperatley from a server, though how can one prevent an attacker from rerouting the query to said server?

I am not sure, it depends on the answer of my above question. Let’s see.

I assume downloaded images:
For automated verification, you’d have to bundle my key within the installer. Users would trust you, verify your key, verify your installer and then your installer takes over (comes with my key) and verifies the downloaded Whonix images. However… Automated gpg verification is hard to get right:
( GitHub - Kicksecure/gpg-bash-lib: gpg file verification bash library, addresses comprehensive threat model, that covers file name tampering, indefinite freeze, rollback, endless data attacks, etc. )

And you would require gpg installed.

To simplify this, may I recommend the following?

• gpg verify Whonix images when you, the developer downloads it for installer maintenance purposes
• create sha256 or sha512 checksums of the images, include them into the installer, verify them using the installer
• (also, signed sha256 and sha512 checksum files are available on download.whonix.org)

If images are integrated into Windows installer:
Then users only have to verify your installer. No need for the installer to automatically verify the integrated Whonix images.

@Ego

Adding to that, the command prompts while extracting and importing the gateway and workstation files are just temporary, mainly so I am able to monitor whether something actually happens during that time. I had spent so long looking for an error when in reality certain commands weren’t even executed that I found that to be a necessity. Whether these should actually be removed remains to be decided as an argument could be made that users should be able to observe the installation process as detailed as possible.

I’d say for the initial release, keep it a bit more verbose. Once all issues are ironed out, hide it (if there can be a command line switch or even a small checkbox or so to re-enable them in case should debugging be required).

[Ego]

Good day,

@Patrick

The installer downloads Whonix images from whonix.org during installation or are them built into the installer?

Are already delivered with it to make deployment in unsafe/uncontrolled enviroments easier.

@Patrick

Automated gpg verification is hard to get right:

I see.

@Patrick

Then users only have to verify your installer. No need for the installer to automatically verify the integrated Whonix images.

Ok. My initial concept was actually meant to automate that step to (i.e. bundle GPG with the signature for the installer, run it in the background and hand over to the installer once it received the go-ahead) since most “Windows-users” aren’t really used to doing things like it. That’s why I am slightly anxious about whether an attacker might have the capabilities of changing this “verification-part” on the fly…

Maybe a good idea would be to, rather than bundle the verification and the installer together, thus making manipluation of both easier, delivering the two seperatley, while still being smpler than doing it yourself. What I mean by this is the following: The user first downloads the installer as usual. He then downloads a second, seperate .exe. This .exe would have to be put in the same folder as the “Install Whonix.exe” and once executed would run a portable version of GPG with the signed and verificated keys already bundled. It then outputs “OK!” or “File corrupted! Download again” giving the user a tangible and simple way to verify the installer.

For now however, I feel like I should finish designing the “UI/Launcher/whatever”. Will technically likely still use this old, functional code as a base though with a (slightly) better appearance: Creating a custom UI for VBox the fast way - Whonix Windows GUI - #3 by Ego

@Patrick

I’d say for the initial release, keep it a bit more verbose. Once all issues are ironed out, hide it (if there can be a command line switch or even a small checkbox or so to re-enable them in case should debugging be required).

Sure.

Can no be downloaded from here: MEGA Sadly, like mentioned above, Github decided to time out.

Have a nice day,

Ego

[Patrick]

@Ego

Ok. My initial concept was actually meant to automate that step to (i.e. bundle GPG with the signature for the installer, run it in the background and hand over to the installer once it received the go-ahead) since most “Windows-users” aren’t really used to doing things like it. That’s why I am slightly anxious about whether an attacker might have the capabilities of changing this “verification-part” on the fly…

The hard part remains. Users would have to gpg verify your installer. There is nothing you can do to improve that situation on the Whonix installer level. [[Improvements are possible on operating system / browser level. For browser, metalink would help. Etc. off-topic]]

Maybe a good idea would be to, rather than bundle the verification and the installer together, thus making manipluation of both easier, delivering the two seperatley, while still being smpler than doing it yourself. What I mean by this is the following: The user first downloads the installer as usual. He then downloads a second, seperate .exe. This .exe would have to be put in the same folder as the “Install Whonix.exe” and once executed would run a portable version of GPG with the signed and verificated keys already bundled. It then outputs “OK!” or “File corrupted! Download again” giving the user a tangible and simple way to verify the installer.

That makes things more complicated. Defeats the purpose of the easy installer. And adds no security. Users who download the windows installer could receive a compromised version to begin with. So they have to verify that one. From there, there is no more need for Whonix image verifications that are integrated in the installer. If users received a compromised copy of the installer, that compromised installer could also fool the integrated verification.

Where the automated verification could make sense is within the Windows installer build process. But even then, perhaps have it verified automatically, but continue manually after reading gpg’s output. I’d say that is low priority if things work for you as they currently are.

For now however, I feel like I should finish designing the “UI/Launcher/whatever”. Will technically likely still use this old, functional code as a base though with a (slightly) better appearance: Creating a custom UI for VBox the fast way - Whonix Windows GUI - #3 by Ego

Looks good to me. We can use that as initial release to get the foot into the door. It’s a HUGE improvement so or so. And it can still be improved after initial testing and feedback.

[Ego]

Good day,

Ok, I can see and understand where you are comming from in regards to the verification. Leaving it up to the user is likely the best solution, espcially when keeping the fact in mind that Windows isn’t the best enviroment for critical communication in the first place.

@Patrick

Looks good to me. We can use that as initial release to get the foot into the door. It’s a HUGE improvement so or so. And it can still be improved after initial testing and feedback.

Ok, great. Will tomorrow (hopefully) be able to upload a new build which should include this basic version.

For a more presentable version I was thinking about something like this:

This would give users easy access to the WS and GW and tell them what’s currently running.

Have a nice day,

Ego

[Patrick]

That looks good!. What would emergency stop do? What’s under advanced?

[Ego]

Good day,

“Emergency stop” would have a similar functionality to the “FDE emergency feature” proposed by @HulaHoop here: Full Disk Encryption (FDE) Emergency Shutdown Feature - Testing Requested shutting down both machines instantaneously.

By clicking “advanced” the standard VirtualBox User Interface would be opened giving an user more control.

Have a nice day,

Ego

[Patrick]

Ego:

“Emergency stop” would have a similar functionality to the “FDE emergency feature” proposed by @HulaHoop here: Full Disk Encryption (FDE) Emergency Shutdown Feature - Testing Requested shutting down both machines instantaneously.

Sounds useful. Perhaps rename that and make an emergency shutdown of the
whole system?

By clicking “advanced” the standard VirtualBox User Interface would be opened giving an user more controll.

Ok.

[Ego]

Good day,

@Patrick

Perhaps rename that and make an emergency shutdown of the
whole system?

Sure, how about perhaps naming it “Shut down host”? Though something I didn’t account for would be accidentally clicking it and losing progress. Maybe having some kind of “safety switch” might help…

Have a nice day,

Ego

[Patrick]

Or we do it unix style. Do one thing and do it well. Leave that feature out?

And combine it with apple style. Leave out all buttons and have just one start button that starts both VMs and one stop button, that stops both VMs.

Plus the a smaller advanced button to open the usual virtualbox interface. I guess we’ll not be able to avoid exposing the virtualbox interface anytime soon since it still is required for many actions.

---

This thread moved to the staff section? Why?

---

As for finding testers of the installer, I suggest creating a Whonix blog post?

[Ego]

Good day,

@Patrick

And combine it with apple style. Leave out all buttons and have just one start button that starts both VMs and one stop button, that stops both VMs.

Sure, would be possible as well. This would be how it currently looks though a more simple style would also have advantages:

@Patrick

Plus the a smaller advanced button to open the usual virtualbox interface. I guess we’ll not be able to avoid exposing the virtualbox interface anytime soon since it still is required for many actions.

Sure, can do that as well.

@Patrick

This thread moved to the staff section? Why?

Explained in the first post:

@Ego

I didn’t want to post this publicly as any obvious issues should probably be found before deploying this…

This is just so some testing can be done before we’d publish this officially. To catch any obvious bugs.

Once this “launcher” has been finalized, I’d like to be able to deploy this “installer” immediately which is why finding bugs now is rather advantageous.

Have a nice day,

Ego

[Ego]

Good day,

So something like this perhaps as a new base design:

Have a nice day,

Ego

[Patrick]

Yes, that looks as simple as possible!

[Ego]

Good day,

Ok, great, am currently sitting on it.

Have a nice day,

Ego

[Ego]

Good day,

Since I didn’t change “that much” between the version currently uploaded and the newest build (other than adding the now “finished” launcher and fixing a bug which lead to the uninstaller not being able to remove the virtualbox.msi files) I have uploaded the three files necessary to run the “launcher” seperatley to save time: MEGA

Simply drop these three files in the same folder in which “Whonix for Windows” has been installed and everything, including start menu and search integration should work.

I will of course upload the complete and corrected version including source to Github (hopefully without crashing this time) as well.

Have a nice day,

Ego

P.S.: Just saw I forgot to mention but .NET Framework 4 is needed to run Whonix.exe. According to Microsoft, it is currently installed on over 70% of all PC’s, though I’m of course still looking into ways of getting it to run with .NET Framework 2.0 which has been included with every Windows since XP.

[Ego]

Good day,

I seem to reach a “presentable build” quite rapidly actually. Since I currently only have access to my Surface, I created dozens of different VMs in order to simulate as many systems and configurations as possible and I feel confident in saying that there shouldn’t be any too glaring bugs in the current build. I even managed to shave about 300MB of the file size by improving the compression employed. Verbose/Showing the command line while running certain external processes has also been “turned off”.

That being said, I’m currently in a bit of legal jungle in regards to whether including certain parts of the .NET Framework is actually compliant with GPL because, despite .NET actually being MIT for the most part, this does still seem to be something of a minefield in terms of copyright law, etc. Sadly excluding those aforementioned parts is hardly an option at the current time. The same reason is also why I still can’t “skip/automate” the “Oracle Certificate Import Process” which thus needs to be manually accepted by the user. Hopefully I’ll get a concrete answer on that as soon as possible.

After that is sorted out I’ll do a final compile and upload everything to Github.

Have a nice day,

Ego

[Patrick]

I am currently struggling to get Windows to work since I doubt anyone else in the staff forum has Windows.

[Ego]

Good day,

No problem, I am confident in saying that I’ve been able to simulate enough configurations (different read/write speed, RAM, GPU, assigned processors, versions of Windows, …) to say that there shouldn’t be anything do problematic in the newest build, other than the whole .NET quandary and one bug/problem in regards to the UI. Specifically, that the most recent version employs a simple “IF/ELSE” approach, rather than being based on a process based one. That could lead to problems if a user decides to either close the VMs on its own or start them via the VirtualBox-UI, as then “my UI” displays the wrong button.

Have a nice day,

Ego

[Patrick]

That’s good. I got a lot on my plate currently. I am happy if we can move to public testing, skipping me. Do you have Whonix blog account already?

[Ego]

Good day,

I currently don’t to be honest. I’d have to get the entire “thing” on Github first anyways. Sadly takes quite a long time due to the fact that the internet I currently have access isn’t really that fast.

Have a nice day,

Ego