Opinion needed - Windows Sandbox or VMware Workstation?

Hi all -

Been doing some software testing with nasty malware.
Which would be best? I want the TPM chip to be in play here.

Sandbox seems sluggish.

Thanks!

Compumind said:

Hi all -

Been doing some software testing with nasty malware.
Which would be best? I want the TPM chip to be in play here.

Sandbox seems sluggish.

Thanks!

Hi there
problem nr 1 for Windows Sandbox --- if you need to test software that needs a re-boot after install e,g configuration changes etc then Windows Sandbox isn't really much use.The Sandbox isn't persistent over re-boots. I don't think you can re-boot the sandbox itself (not the main Windows machine) without also losing persistence.

Problem nr 2 - can't move Windows sandbox data to your own choice of drives /directories.

problem nr 3 (possibly) I think you need Windows Pro as you will need to enable part of Windows HYPER-V -- might not be possible on HOME editions -- I don't know for sure but I think this is also a restriction.

Sandboxing is fine if you can test things properly and they are persistent until you want to get rid of them -- currently Windows Sandbox is not much use. (at least IMHO)

VM's take a lot more setting up but these days very efficient and are perfectly good for testing pretty well everything (unless you require real access to the underlying hardware --e.g writing fast video game drivers for specific graphic cards / GPU's etc).

Even then some of the latest hypervisors -- HYPER-V / QEMU/KVM etc allow hardware passthru so you can use the real OS drivers rather than the paravirtualised ones which make VM's have the possibility of running at near native speed and performance -- OK VMWare isn't in that league but all I'm saying here is that using a VM for all sorts of things today is absolutely OK -- even a few years ago running a video player like VLC on a VM was sluggish etc.

Another possibility is to use a cheap cloud server -- so many options today that never existed (certainly at affordable consumer prices) even 3 years ago.

I'd tend to forget using Sandbox -- even if you don't want to use a VM - HDD's are mega cheap these days --just fire up another Windows install for your test -- on the same hardware - activation won't be necessary.

Some sandboxing IMO is like a lot of these 3rd party Anti Virus solutions -- a C20 solution (e.g time of Win 7 etc) when we've got far better C21 systems available.

Cheers
jimbo

FreeBooter said:

Some malwares coded to not work when executed from within VM so you might have to use Sandbox time to time.

This is strange. Why wouldn't they work in a VM?
Do you have an example?

TIA

@Kari -

Let's get your input to my original post, thanks.

FreeBooter said:

No i don't have example but you can check out the article.

How Malware Detects Virtualized Environment (and its Countermeasures)

Thanks!

This is a question where each and every geek have a different opinion.

My approach: Test everything on a native boot VHD, except if the thing you test can affect other disks / drives on system. If yes, test it on a VM behind NAT (like Default Switch in Hyper-V).

Kari said:

New video: Dual Boot - The Easy Way



The easiest possible method to dual boot. No partitioning, no virtualization required. Deploy Windows 10 on a virtual hard disk VHD or VHDX file, add it to boot menu. When done, when you no longer want to dual boot, just delete the VHD file.

   Note

When creating VHD file to be used in native boot, always use MBR partitioning! To upgrade Windows on native boot VHD, it must be temporarily attached to a virtual machine. An MBR partitioned VHD is easy to attach to VM, it only needs Windows partition to be marked active, whereas a GPT partitioned VHD with only a single partition for Windows requires manually creating system partitions before it can be used on VM.

If you for any reason want to use a GPT partitioned VHD in native boot (can't think any valid reason!), it is better and recommended that you first create a Generation 2 VM in Hyper-V, installing Windows 10 on it. This takes care of the partitioning, doing it correctly. The VHD can then be used as native boot VHD, or on a VM.

See this tutorial for more information: Native boot Virtual Hard Disk - How to upgrade Windows

The DISKPART script and deployment batch from video:

DISKPART scripts are normal text files with extension .txt. To run a DISKPART script, enter following command:

diskpart /s DRIVE:\FOLDER\SCRIPT.TXT

Here's the script used in video:

Code:

create vdisk file=F:\W10PRO.vhdx maximum=51200 type=expandable
attach vdisk
create part primary
format quick label="Windows"
assign letter=W
exit

Save script as VHDConfig.txt

Above script creates a dynamically expanding MBR partitioned 50 GB (51,200 MB) VHDX file (you can use .vhd or .vhdx) named W10PRO.vhdx in root of drive F:, labels it Windows and assigns it a temporary drive letter W:. Edit script to meet your needs, be sure the drive you create VHD has double the free storage than the size of VHD; if you will create a 100 GB VHD file to be used in dual boot, the drive where it will be created needs 200 GB free.

Also, be sure to assign an unused drive letter! I always use W: which I have reserved for this purpose, never assigning it to anything else. In any case the drive letter will only be needed for deployment, it will be freed when VHD will be unmounted.

The deployment batch is really simple, too. It just runs DISKPART script to set up VHD, deploys Windows on it with DISM, adds it to host boot menu and finally changes the boot menu entry to something more descriptive:

Code:

start /wait diskpart /s E:\Users\Kari\Scripts\VHDConfig.txt
start /wait dism /apply-image /imagefile:I:\sources\install.wim /index:8 /applydir:W:\
start /wait bcdboot W:\Windows
start /wait bcdedit /set {default} description "W10 PRO EN-GB (VHD)"
cls
@echo off
echo. 
echo Windows deployed to VHD file
echo and added to host boot menu.
echo.
pause
exit

Save batch file as VHDBoot.bat

Again, edit the batch to meet your needs. Be sure path to DISKPART script is correct, and that path to install.wim (or in case of MCT ISO install.esd) is correct in DISM command. Select correct index value. Check that BCDBOOT will add Windows to boot menu from correct disk, the drive letter here must be the same DISKPART script assigned to VHD.

 Windows 10 ISO edition index values

Table 1: Official Windows 10 ISO images

Edition index values for ISO images downloaded from Download Windows 10 Disc Image (ISO File)

• ESD = ISO image created with Windows Media Creation Tool (install.esd file instead of install.wim)
• WIM = WIM based ISO image (requires browser user agent change)

Notice that values in WIM column also apply for official Insider ISO images downloaded from Download Windows 10 Insider Preview Advanced

Edition	ESD	WIM
Home	1	1
Home N	2	2
Home SL	3	3
Pro	6	6
Pro N	7	7
Pro Education	-	8
Pro Education N	-	9
Pro for Workstation	-	10
Pro for Workstation N	-	11
Education	4	4
Education N	5	5

Table 2: Visual Studio (former MSDN) subscriber ISO images

Edition index values for ISO images downloaded from Sign in to your account

• VSB= Business editions ISO image
• VSC= Consumer editions ISO image

Edition	VSB	VSC
Home	-	1
Home N	-	2
Home SL	-	3
Pro	5	6
Pro N	6	7
Pro Education	7	8
Pro Education N	8	9
Pro for Workstation	9	10
Pro for Workstation N	10	11
Education	1	4
Education N	2	5
Enterprise	3	-
Enterprise N	4	-
Enterprise for Virtual Desktops	11	-

All single edition ISO images have index value 1 for edition in question regardless of edition, for instance whatever edition you are running, its index = 1 if you made the ISO by yourself with UUPtoISO.


Kari

@Kari -

Great idea. Thanks for your insight and information!

Main reason for using native boot VHD for testing is that it's so easy. It runs using machine's real BIOS / UEFI settings, using real hardware drivers. When done testing, just delete the VHD.

Kari