torsdag 13. august 2015

Hide your ass: Hide by MAC address and internal routing

Scenario: if you have connected your piVPN\raspberry to a network it will be visible during the IT admins network scan.
So what if you want to hide the box for him and his sniffing ?
Of course there is a reason why it should not be on the network in the first place, and placing such a device unauthorized on any corporate network is probably illegal in all countries.
So please only use this method for training and authorized penetration testing at home
All software i mention in the text is preinstalled on my downloadable pivpn image  here (dropbox) or here (direct http).
It is just a raspbian wheezy dated 05.05.2015 with some extra software, and installation procedure is the same as in raspbian.
You will need minimum 4GB SD card and a RPi2 to install the image.
Username and password is root/toor
But you could install all the needed software on anything running linux really.

So on a office network we have installed a raspberry pi with SEVPNServer, xrdp and ssh.

The pivpn box is connected to the remote network with a network cable to eth0 getting an IP from the office networks DHCPd.
From home (using SEVPNClient we are able to connect to the office network; get an IP address from the office DHCPd and then access all information on the office subnet from our device as we where connected by a virtual ethernet cable

The auto generated name is

A quick nmap scan from from the IT admin's PC will show something like this:

Nmap scan report for pivpn.workgroup (
Host is up (0.0073s latency).
Not shown: 97 closed ports
22/tcp   open  ssh
443/tcp  open  https
3389/tcp open  ms-wbt-server

MAC Address: B8:27:EB:DA:87:FF (Raspberry Pi Foundation)

There is a few things here that the admin will react to:

1) what is an unauthorized Raspberry Pi doing in my environment ?
2) why are those ports open (22, 443, 3389) in the first place ?
3) how come a linux box running port 3389 (this would maybe be OK, and slipped by if it was a Windows machine, but not on a linux host).
4) why is it running https and ssh. It is a  web server of some kind ?

In general, at this point, all IT admins would start to trace down the box.

So here are some basic stuff that you could do to try to hide your box:

Change the MAC address

1) Run the macchanger application to change the mac address of your box.
Here you should be a little creative. The MAC address should reflect a device that  the network admin would expect to be on the network. It could be a DAB internet radio MAC or a Cisco address; if you are connected by wireless an iphone MAC would be good.
Your choice.
You could find a list of vendor MAC ranges on:

For this example, all other PC's in the current environment are HP's
A typical HP machine could have a MAC address of something like this(coffer):

Also if they got a naming convention for the device you are imitating, change the hostname of the device by changing the name in these files,:
vi /etc/hostname
vi /etc/hosts
to something that makes sense like (WSHQ156, myiphone5, SwitchHQ2floor3)

We can change our MAC address by running macchanger, Never use an address that is already used in the network.

Usage: macchanger [options] device

  -h,  --help                   Print this help
  -V,  --version                Print version and exit
  -s,  --show                   Print the MAC address and exit
  -e,  --ending                Don't change the vendor bytes
  -a,  --another                Set random vendor MAC of the same kind
  -A                            Set random vendor MAC of any kind
  -p,  --permanent              Reset to original, permanent hardware MAC
  -r,  --random                 Set fully random MAC
  -l,  --list[=keyword]         Print known vendors
  -m,  --mac=XX:XX:XX:XX:XX:XX
       --mac XX:XX:XX:XX:XX:XX  Set the MAC XX:XX:XX:XX:XX:XX

make sure the interface eth0 is down
/sbin/ifconfig eth0 down
macchanger --mac 00:22:64:B9:41:EB eth0

If you are online create a simple script:

#! /bin/bash
/sbin/ifconfig eth0 down
/usr/bin/macchanger --mac 00:22:64:B9:41:EB eth0
/sbin/ifconfig eth0 up

and run it.

Note that the interface will change the IP address if you are on a DHCP server and you will need to figure out that address to reconnect over LAN.

Now the IT admin wants to do a nmap quickscan plus to gain some information:

Nmap scan report for pivpn.workgroup (
Host is up (0.00052s latency).
Not shown: 97 closed ports
22/tcp   open  ssh           OpenSSH 6.0p1 Debian 4+deb7u2 (protocol 2.0)
443/tcp  open  ssl/http      SoftEther VPN httpd
3389/tcp open  ms-wbt-server xrdp
MAC Address: 00:22:64:B9:41:EB (Hewlett-Packard Company)
No exact OS matches for host (If you know what OS is running on it, see ).

TCP/IP fingerprint:

OS:Scan .. (truncated)....
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Note some changes here, IP change and the OS fingerprint is not exact anymore (this is probably due to a not updated nmap database, but he can still see it is a Debian installation)

Anyway, it is still a very suspicious host, we need to hide the OS, SSH, xrdp and SEVPN from the IT admin's nmap scan.

What we can do is this:
1) Create a virtual interface on the piVPN box with an IP address out of the IT admins address space, and give this virtual interface it own subnet
2) Create a route between eth0 and the virtual interface.
3) Bind SEVPNServer to the virtual interface.
4) Setup iptables to ALLOW all new, created and outgoing packages from eth0 and DROP all incoming packages. ICMP should be stopped too.

The reason this will work is that the SEVPNServer is installed to connect outbound with a default connection to a host in the azure cloud with a dynamic DNS name (
The client does the same. They will meet in the middle and the client will access the inside of the office network remotely.

SEVPNServer->virtualinterface ->route-> eth0-->corp.LAN -->Internet---><---Internet--SEVPNClient

From a hacking perspective this is not perfect, as you only have a layer 3 link into the remote network and not to a layer 2 connection, but as a minimum you will be able to scan all the hosts and ports and resources on the office network using layer 3.
Also, please note accessing through the default vpnazure cloud can be very slow.

SEVPNserver setup:

Setup ad a server (center server)
create a new tap device (I call the device vpn, SE is creating it with the name "tap_vpn" in ifconfig)
Setup the secure NAT (I actually disable that now) and virtual DHCP server.
the default setting is for the virtual hosts network, and a DHCP scope of for the clients.
I just disabled the SecureNat thing (but you can just use that too), as in the picture.

iptables time...

#Enable routing between eth0 and the tap device:
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o tap_vpn -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i tap_vpn -o eth0 -j ACCEPT
#Enable lo
iptables -A INPUT -i lo -j ACCEPT  
iptables -A OUTPUT -o lo -j ACCEPT 
#Enable vpn tun card
iptables -A INPUT -i tap-vpn -j ACCEPT
iptables -A OUTPUT -o tap-vpn -j ACCEPT
#Drop ICMP
iptables -A INPUT -p icmp --icmp-type 8 -j DROP
#Drop ALL other
iptables -P INPUT DROP

Now start a VPNclient against the machine
The machine will get an IP of 192.168.30.x and will be able to access the network over the linux router.

NOW when the IT admin scans the host with nmap:

The new scan shows:

Nmap scan report for
Host is up (0.010s latency).
All 1000 scanned ports on are filtered
MAC Address: 00:22:64:B9:41:EB (Hewlett-Packard Company)

A detailed scan is not helping him either.
Of course this could\will lead to an investigation as well :-)

fredag 7. august 2015

The new piVPN "distro"

This "distro" can be downloaded here: pivpn-2015-05-05-raspbian-wheezy.7z

Username is root
Password is toor
ssh and xrdp is running at start.

After struggling with some reinstalls I figured I needed  to create a basic SD image with the stuff I need without reinstalling from a scratch image all the time.
I normally need a lot of network tools, and sadly Kali turned out a bit too unstable for me (I had issues with hostapd and firmware).
Finally I figured out it would be better for me with a modified base system that could easily be reinstalled.

This image is just a raspbian image (2015-05-05)with some extra software preinstalled, and also (basically all the childish stuff) some removed.
As it is using the raspian repositories it should get all raspian updates and upgrades.

Added apps are:
libnl-3-dev libnl-genl-3-dev
softether VPN server Softether VPN bridge Softether Client

tirsdag 21. juli 2015

E.T. phone home - piVPN as a remote network access point for all your network resources

My  original homemade plexi casing for the RPi 2 made it look a little bit like E.T. ,with it's "long head" and USB ethernet cards "eyes".

piVPN's E.T. phone home

While E.T. himself made a "makeshift communicator" (among its parts was a Speak & Spell, an umbrella lined with tinfoil, and a coffee can filled with other electronics) to phone home, the piVPN RPi version of "phone home" can do a lot more than just to call home using audio.
E.T.'s makeshift communicator

The piVPN "phone home" box act as a an wired and wireless access point to bridge all network resources in a home or office to any networked device over a VPN line. Also you can connect several devices to the "phone home" box at the same time. As the VPN is bridged, all the devices will look like they are a part of the main network. 
For example they get their IP addresses by the main DHCP server in the office, and they are also able to log on to active directory as they where in the office.
The IT admins in the office does not need to know anything about the exact network configuration on the remote site where the piVPN connects from. 
The connection to the "phone home box" it self can be over a 3g/4g phone, a cable to a switch, a wifi guest network or whatever available on the site you are connecting it from.
Network traffic is encrypted between the "phone home box" and your main office, making this system safe over untrusted networks. 
Network devices that are used by other people on any remote open networks that you connect your "phone home box" to, will not be able to see or access your devices or network.
The piVPN is also able to run on a solar powered battery. 
This makes it a very portable mobile field solution too. 

Best of all... It is based on opensource software, small and cheap hardware, and it is very configurable :-)

First a quick drawing on how this is done:

In the main network (this can be your office, home or wherever you have your main network resources) we will need to install a SE VPN server, which can be downloaded from here:

You could install this VPN server on a RPi 2, a windows or a linux box.
In this case I will install it on a old windows 7 pizza box, as it is less fuzzy about routing. The linux installation tend to have some issues sometimes with how the kernel sets up the routing tables.
This is fixable, but requires some extra work recompiling the linux kernel for the VPN server.

So I just get my windows 7 pizza box, and install the SE VPN server software from here.

The SE VPN official how-to is found here

Make sure you also install the server manager software that comes with the package, as we will need that later to configure the bridge on the pivpn "phone home" box.

The VPN mode you install is VPN server (central) that accepts connections from other servers.

During the installation you will be asked if you want to use a dynamic DNS name and a azure DNS name (this makes it possible to connect to your office trough the microsoft cloud).
Security wise it is not recommended to use these settings, but  for this experiment (and ease) we will do it for now.
You can try to suggest a name that you will actually remember instead of the SE auto-generated one if you want to and write it down.

I would recommend to give your PC a static IP address and NAT' the port 443 through your router to that IP address. This will guarantee a TCP connection between the remote host and your office using https. If not the system may be running on UDP which is more unstable. 
Even though SE VPN support several ports, 443 is the most practical one, as this port is normally open on all remote networks that you are able to access internet from.

If you don't have access to open ports or do changes on your router, you can just use the azure cloud DNS name (the address given to you during the SE VPN server install).
This ensures a link from your VPN server to the cloud. A remote VPN client will then connect to the cloud server, and access your network through this (note that this may be a very slow link).

When the installation is done connect to the server with the "SE VPN manager" application which is installed during the SE VPN server setup.
When you connect to the localhost the first time it wants you to create a new admin password for the VPN server. Choose a long safe password. This password is for connecting to the server using the "SE VPN manager" application.
Now create a new "virtual hub", the system normally suggest the name "VPN" for this virtual hub.
Create a username and a password for the virtual hub.This is the username and password to be used for VPN clients (and bridges) that connects to the server
Create a "local bridge setting" for the virtual hub (this will be the  physical network card as this is not a multi homed PC). If you plan to have a lot of traffic, you should get one physical network card per virtual hub, but this is way out of scope for our simple setup.

Now the VPN server should look like somthing like this:
The virtual hub name is home and is online
It got two users
You will be able to see the DDNS and DNS names 
at the bottom of the window.

You should test that it is working by connecting with a SE VPN client from another machine.

When you know the server is working, we can go ahead with the "phone home" box.

To keep control of the device ID name, I just start with a clean RPi 2, connected to my network switch using the built in ethernet card eth0, a USB keyboard connected to a USB port and freshly installed raspbian OS (16 gb SD card formatted with SDFormatter and 2015-05-05-raspbian-wheezy.img added using win32imager).

On my main windows machine I start putty and ssh to the machine.

First thing to do is to install and run the vpn bridge script

chmod 777

If all the current RPi network settings are OK, there is nothing much to to do just now. Just wait for the RPi to finish the script and reboot (approx. ten minutes).

After the RPi reboot you should see a message on the console that the VPN bridge daemon has started (e.g. "The SoftEther VPN Bridge service has been started")

So now on to the hardware to be added to our RPi:
What we want to do

eth0 (the built in ethernet card) - This will be available to connect to remote switches using a network cable 

eth1 (aadded usb ethernet port) - Available as a cabled bridged port (A port to directly connect you remote PC by cable. When you are connected a virtual network cable between your device and the office network is created).

wlan0 (added USB wifi card #1) - This will be a wifi client connection that may be used to connect to a remote wireless access point

wlan1 (added USB wifi card #2)- Available as a wireless bridged port using hostapd (SID pivpn, WPA key Passw0rd, It will act as a wifi access point for any devices that has a wireless client. When you connect with any wireless device to this AP, you will get bridged to the SE VPN server and have a virtual network cable between your device and the office network)

The basic system is this:
eth0 and wlan0 is connecting and using the remote network, respectively by cable or wireless.

eth1 and wlan1 is bridging through either of the connections eth0 or wlan0 to provide access to your office network for any client that connects through those interfaces.

First to the two cabled interfaces eth0 and wlan0. For the moment we will just leave them as is.
They both got a DHCP setting by default, so they should recieve a dhcp IP address for whatever they connect to.
It may seem a bit strange but we don't have to setup DHCPD or a static IP address for any of them. The reason is that we will let eth0 just get what ever IP address that remote network provides.
When it gets an IP address, eth0 then will connect to the VPN server. When connected through the remote internet using the https port (443) to your VPN server it will assign both eth1 and wlan1 as the interface to provide the bridge.
For wlan0 we will need to manually connect to a remote wireless AP,. We will really need to do that on site, if we don't have the wlan info beforehand. 
So conclusion; these two ports will provide any host connecting with them with the network settings from the VPN server and they should connect with DHCP wich is the default network setting in RPi.

So first we connect one WiFI USB card to the RPi to make sure it gets the interface name wlan0.

Do a reboot
(sudo reboot)

If you want you are now able to connect to a wireless access point using 
the gui application 
logon with your user to your RPi
startx (if it is not in gui mode)
in the gui scan and connect to a wireless AP

Now, check the file /etc/wpa_supplicant/wpa_supplicant.conf

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

It should contain something like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev


So at this time we have eth0 and wlan 0 configured

For eth1 we do not have to do anything but connect it and reboot... Yes really, don't even ask. It will not need an IP address ever.

After a reboot and the command ifconfig, you should see something like this:

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:da:87:2e
          inet addr:  Bcast:  Mask:
          RX packets:350 errors:0 dropped:1 overruns:0 frame:0
          TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:31363 (30.6 KiB)  TX bytes:16842 (16.4 KiB)

eth1      Link encap:Ethernet  HWaddr 00:50:b6:12:84:d5
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:160 errors:0 dropped:0 overruns:0 frame:0
          TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13592 (13.2 KiB)  TX bytes:13592 (13.2 KiB)

wlan0     Link encap:Ethernet  HWaddr 34:21:09:1a:f2:95
          inet addr:  Bcast:  Mask:
          RX packets:336 errors:0 dropped:126 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44012 (42.9 KiB)  TX bytes:4334 (4.2 KiB)

pi@raspberrypi ~ $

So three of four is done :-)

So now to the last interface wlan1 which will be our wireless access point.
In principle this acts as the eth1 USB card. As long as the client is able to connect AND the internet connection is OK on either eth0 or wlan1 it will connect without any DHCPd setup.
What we need is to be able to connect a client. 
Do do that we will need to install the hostapd daemon, and the good thing is that the script has already done that, and the service is already started.
We will need to connect the USB wifi card and configure it, that is all :-)
Remember to run sudo reboot when you connect the new USB card wait until the reboot is finished

This may be the point where the RPi start to get a bit confused, you may notice that both wlan0 and wlan1 gets an address from the dhcp server - they both are clients to the same wireless access point now.

We need to make sure they get seperated by their device names.

The configuration file for hostapd is found here:

sudo nano /etc/hostapd/hostapd.conf

Paste something like this in to the file (dependent of the driver of wlan1):


There is a little thing with the hostapd service. Even if it is installed, it does lack a link to the config file so the daemon does not start.

So we will need to edit one more file to make the hostapd read  and run our config file:

sudo vi /etc/default/hostapd

add or edit the line to:


Now reboot

With some luck all should work now. While rebooting check the console output:

If the piVPN network is not appearing in the available wireless access point list on another PC in a few minutes, please check the command

sudo iw list

and see if the usb wifi card is recognised.

The final part; getting this all together.

Now you should have a fairly long list of devices if you run the command ifconfig:

On my PC:

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:da:87:2e
          inet addr:  Bcast:  Mask:
          RX packets:1015 errors:0 dropped:2 overruns:0 frame:0
          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:95467 (93.2 KiB)  TX bytes:35540 (34.7 KiB)

eth1      Link encap:Ethernet  HWaddr 00:50:b6:12:84:d5
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:152 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:12928 (12.6 KiB)  TX bytes:12928 (12.6 KiB)

mon.wlan1 Link encap:UNSPEC  HWaddr 34-21-09-1A-F2-83-00-00-00-00-00-00-00-00-00-00
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10737 (10.4 KiB)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 34:21:09:1a:f2:95
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:199 errors:0 dropped:89 overruns:0 frame:0
          TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24550 (23.9 KiB)  TX bytes:3896 (3.8 KiB)

wlan1     Link encap:Ethernet  HWaddr 34:21:09:1a:f2:83
          RX packets:8 errors:0 dropped:3 overruns:0 frame:0
          TX packets:494 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1157 (1.1 KiB)  TX bytes:203133 (198.3 KiB)

pi@raspberrypi ~ $

Time to configure the bridge VPN part.

Start the SE server manager and go to the eth0 ipaddress.

Set a password

Go with the default

Choose step 2

 Enter the info from the earlier VPN server setup at home, 
enter or DNS name, username and password

Make sure it connects

Step 3 Set local bridge
Do this twice for eth1 and wlan0

Done and reboot :-)

Now for the final setting change the wireless client card settings (sudo nano /etc/wpa_supplicant/wpa_supplicant.conf) to something that makes sense when you are offisite.
This can be your phones 4g setting when you tether it.

søndag 19. juli 2015

Making a generic Windows 10 Pro wim image for remote installations

One of the general big issues with deploying unattended installations with imaging is that MS wants you to create one image per PC model to make sure that the drivers are added OK.

In principle this means that you will need to create one golden image per machine model; add that image to your server, and then deploy the different images to the specific PC models that your company have.

This is a very time consuming job, and therefore I would normally do this deployment in a totally different way; using one central "brass image" with the possibility to apply any driver needed by any of the PC's.

Before you laugh about this attitude, note that I have used this method for a windows 7 rollout for 350 PC's, so it does work.
In this company it was a mixture of Dells (workstations and laptops), HP (workstations and laptops) and Acer (laptops). None of them was on a domain.
In the end we figured out that it was at least forty different models, and brand new unknown models popped up on every site. Just collecting drivers revealed a staggering 14 GB of drivers in total.

The way I got it to work was to make sure that I added any new drivers for a any newly found PC model to the original wim image (I will show how later), and figured out a way to apply the drivers to the central image, deploy the image to the PC and apply the drivers to the to the different models unattended..
After that it was just renaming by naming convention and then add to domain :-)

It did really work, and it is easier than you think :-)

For the moment there is still some kind of lack of windows 10 drivers and one attitude to solve thsi can be to add new drivers to the golden image as they becomes available. This can call for the method above.

Bugs in windows 10 unattended deployment

First of all there are two major bugs with making unattended installations with the latest preview of Windows 10
1) When you do the first installation on the technician PC (the source PC), turn off the "Apps Updates" at once. If not, you will not be able to to sysprep the machine, as it will try to update the apps on your profile automatically. As this is done for one user only, sysprep will not allow you to run a general sysprep. The "fix" is to delete the profile with another user.. or start over again. I really hope they stop doing these automatic updates of apps. At least they should give an option to turn it off during OOBE. The first thing you should do then, is to turn off Apps Update in  the Store App at once after first login.
2) You can not reuse the username you used on the machine you sysprepped. If you used the login name "admin" on the tech-computer (source computer) you will not be able to to use that username in your unattend.xml file. Fix is to use a username that you will never normally use, a swearing word works fine :-)

Create a "golden image" (or brass image in this case)

First install windows 10 on one computer, in any way you like (netboot, DVD, USB).
I used an old HP Elitebook 6930p for this and Serva32 for a PXE installation from  a preview iso.
On my Elitebook most of the HP specific drivers where missing after the installation, and I did not care much about finding them either.
What I want is that the image I get from this HP will do an unattended installation with all drivers for a much more usable Dell latitude E5540.

Make sure that you stop the "app update" by starting the windows store app, clicking on the "head icon" (I guess that means profile) on the top row and choose to disable updates.
Now install any application you want, I installed 7zip, putty, VLC and some other free stuff that I always need.
Make sure that you do all windows updates etc. too
Reboot the machine once in a while to make sure all settings and updates are applied.

Now to the interesting part -- how to get the dell drivers (or any other drivers) in to the image, without it a PC crash during setup.

1) First I put a file named setupcomplete.cmd in c:\windows\setup\scripts. What this file does is to call up a batch file in c:\temp that using a MS driver tool to check and add for drivers under the folder c:\temp\X64. The power config thing is to make sure the PC don't go to sleep if there is a lot of drivers to be scanned and installed. It is commented out for now, as I am not sure it works in Windows 10. SetupComplete runs automatically after setup, but before login.

2) Download the windows 10 drivers you need for your computers and put them in any subfolder(s) under c:\temp\X64. Since my Dell E5540 does not have any official windows 10 drivers from Dell yet I extracted the E5540-Win8 cab driver package and hoped the Windows 8 drivers might be kind of supporting the windows 10 drivers too ....

3) add these files to c:\temp

Now finish sysprep as normal by starting it from C:\windows\system32\sysprep

After shutdown, boot the PC on a winPE USB stick and run imagex.

My winPE is a bit special, so I am able to transfer my new install.wim directly to my Serva64 (the machine I do PXE against) machine, but without such luxury you can just transfer it a USB drive or something, it doesn't matter.

Now I add a new entry in Serva64 with this unattend.xml file. NB the production key is for a windows 10 preview
Notice that I have enabled the administrator account in this one. At least I can run commands without UAC errors (OK the real reason is number 2) in bugs over here)

So.. Just to connect the Dell to the network, press F12, do an unattended installation with the new image and see if it get it drivers.....

And yes... after 20 minutes, it automatically logs on as administrator with all its drivers already installed :-)
Since there is no feedback during the installation the easiest way of seeing that it works, is that it have a Dell touchpad driver installed. This driver is not to be found in the MS driver repository :-)
A good thing here is that all the drivers you add to c:\temp\x64 only takes space, but will not be added to the driver repository in windows if not the device ID is correct.
Of course the install will take longer time for each driver you add, as the system will need to scan through all drivers, but since most mass deployments are happening at nights and are unattended, it really does not matter if the installation takes 20 minutes or one hour.
Also note the Windows sometimes have device ID issues with mouses and storage devices, so it can be good to remove some of those drivers from c:\temp\X64 and add them later (I would never do that as my users is normally not using gestures on their touchpad or similar)


Of course, I don't think this is the ultimate drivers for my Dell, but this is the drivers that was available now. I hope Dell can put out some supported windows 10 drivers soon (and all the other companies too) :-)

A working Windows 10 Pro unattend.xml file

Only a few days to go until the new Windows 10 release, and finally time to get the latest preview (10240) to work with automatic installation methods.
In the earliest previews these methods had some issues, but the latest one is so close to RTM as it can be, so time to test :-)
I had some issues finding a working file for unattended windows 10 installations, so I figured I had to write one myself. Please note that this one is edited manually, so please check and double check before using...
Also note that keyboard and regional settings is set up to Norwegian.

Can be downloaded from here

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<TimeZone>W. Europe Standard Time</TimeZone>
<LocalAccount wcm:action="add">
<Description>Local Admin</Description>
<DisplayName>Local Admin</DisplayName>
<settings pass="specialize">
<component name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<RegisteredOwner>End User</RegisteredOwner>
<settings pass="windowsPE">
<component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
<Disk wcm:action="add">
<CreatePartition wcm:action="add">
<CreatePartition wcm:action="add">
<ModifyPartition wcm:action="add">
<Label>System Reserved</Label>
<ModifyPartition wcm:action="add">
<MetaData wcm:action="add">
<Value>Windows 10 Pro</Value>

lørdag 18. juli 2015

Installing Windows 10 IoT on RPi using windows 7/8

Annoyingly MS has decided that you need to have windows 10 preview installed on a PC to be able to transfer their "InternetOfThings" image in their proprietary ffu format to a Raspberry Pi.

First of all, it really is a unnecessary approach from a technical point of view.
What you need is a just updated DISM to handle the image (or they could have released it in another format in the first place)

For all us techs that have been around using Microsoft's imaging tools for a while, this is not a surprise, as they have changed a lot on their imaging tools on every release (including switches .. aaarghhh).

What you really just need to do is to create a folder with the new windows 10 DISM.exe and it's needed dll files, and run the needed command from that folder.

First, we will need some files from the windows 10 DVD (which is not available for the moment, as MS will realease that in the end of this month, of course :-( )

these are:


The total size of these files uncompressed is about 4 Mb, which with convenience could have been included in the msi file they provide in their setup file (most of them actually is included but with a bit cluttered names to ensure that you will not be able to run them from a older version of windows )

In addition you will need the flash.ffu image which is to be found in their IoT Core RPi.iso file approx 1,2 Gb.

You can collect all the files including the latest preview flash.ffu image from here: (400 mb)
Without flash.ffu here (3mb)

So what you do is the following:
Insert a SD card in your PC (16 gb should be OK)
Format it with SD formatter:
unpack the downloaded files (iot.7zip) to c:\iot

start a command prompt as administrator
Type the following commands:
list disk
you should now get a list of the disks on your pc:

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB      0 B
  Disk 1    Online           14 GB  7721 MB

Note the disk number of the SD card (in this case disk 1)


Then type :
cd c:\iot
 # to go to the folder containing the files
./dism.exe /Apply-Image /ImageFile:c:\iot\flash.ffu /ApplyDrive:\\.\PhysicalDriveN /SkipPlatformCheck

Where the N in PhysicalDriveN is the drive number from the previous step ( In my case 1).
Notice the ./ in front of the dism command, this is to ensure that it runs the dism.exe in the current folder.

The image will be transferred to the SD card

Insert the SD card into your RPi and wait a while (this will take several minutes)

If you have a monitor connected to the RPi, it will eventually show the IP address of your device.

Open putty and do a SSH against the RPi IP address (strangly this takes some time to, it could be a reverse DNS issue on my system).

Log in with:

Username: administrator
Password: p@ssw0rd

tirsdag 14. juli 2015

How to deploy a windows image with PXE over internet using bridged VPN

So this is the scenario:
You have a PC in a remote home office that you will need to reinstall with your enterprise windows image.
At the HQ office you normally just deploy the image using a windows WDS server or similar.
This means that you boot a new PC on the network (pressing F12) and then using WDS with a network broadcasted PXE package and a unattended.xml file, you apply the image and domain settings for a windows machine.

So what we want to do here is to extend your HQ office network settings so that the remote user  is able to do the WDS installation at his remote home office network over internet.
This is not possible to do with a "normal" routed point to point VPN. The installation method we have choosen is based on broadcasted network packages which is not routable.

This is where a bridged VPN is working perfectly. Seen from the network perspective, the remote home office and the HQ office is then at the "same" network, so all network broadcasts are forwarded over the VPN connection. We got a virtual layer two ethernet cable between the sites
This means
(1) when the remote machine is requesting a DHCP address, it gets it from the office DHCP server
(2) the WDS server broadcasted PXE and BINL packages will be received in the home office as well, so that the windows image installation will be able to run..

What is needed:

In the HQ office: 
DHCP server
Softher VPN server (or a piVPN in VPN server mode)
Some kind of PXE service able to deploy the windows image (I will use Serva 64 for this)
A fairly good internet connection

At the home office (where the image will be deployed) :
A piVPN  machine, or any other machine running softether VPN, in bridged mode.
The machine to be installed is connected to the same switch\router  as the piVPN machine.
A fairly good internet connection (approx 10 mbit should be OK).

The image of the scenario is then like this:

Now, there is one problem with the remote home office setup.
It have a router ( which probably already got a DHCP server and we may not be able turn that service off or modify it.
What we will have to do to make sure that the remote laptop is only seeing the office network. We will need to have two network cards on the piVPN running in bridged mode at the remote site.
Any supported USB ethernet card will do, in addition to the built in ethernet card on the raspberry pi.
The first network card (the built in eth0) is then connected to the remote router and the other network card (USB eth1) is connected to the laptop to be reinstalled. Both cards can just run as DHCP clients (as they will do by default, so no modifications of the network settings are needed, and either is any knowledge of the remote infrastructure)

Another clever way can be to connect a wireless card to the piVPN and connect that to a wireless access point at the remote site and then connect the PC to be reinstalled to the ethernet port. This opens up for installations over mobile access points (wifi and USB tethering) and guestWiFi's on hotels :-) Of course you can also put a switch in the USB ethernet port and connect several PC's to it for multiple PC deployments.

Experiment time in the mini lab:

First I will setup two separate networks with two different routers.

Network 1 (e.g the main HQ office network) is a network with IP range /24
accessing 75 Mbits/s internet with a ASUS  RT-AC66U (ip address: which is also a DHCP server for this range)
Also I connect a lenovo think pad hosting Serva64 (a cheap WDS clone) which is able to do a unattended deploy of an install image of Windows 7 Enterprise.
Also it got a tiny pre setupAcer Ubuntu SoftEther VPN server (192,168.50.2) which is nat'ed through the Asus router on port 443. Of course you could have used a piVPN, a Softether VPN server running on windows or whatever you want. The best reason to run on port 443 is that this port is close to always available on remote networks with internet access.

Network 2 (e.g the remote home office network) is a network with IP range /24 accessing a 4g (approx 30 Mbits/s) internet using a D-Link DIR 615 (with dd-wrt set in client mode towards a 4g phone with wifi tethering). All incoming ports are closed.
A very old HP laptop (to be reinstalled)
My piVPN box with an additional USB ethernet card (asix of some kind)

piVPN setup

First I have modified the script for VPN bridging instead of VPN server.
I have also commented out the original X application removal, added xrdp (to be able to log in using X and connect to a wireless network using gui)
The script can be found here.
On a freshly installed Raspian you can just install and run the script using:

chmod 777

When the script has finished the RPi will reboot and the VPN in bridgemode will be enabled.

You will see the IP address of the ethernet card (eth0) on the Raspberry which is connected to the remote router, in this case it gets by DHCP from the remote router. Eth1 (the USB NIC) is not connected yet.

I connect a windows PC  to a port on the remote router to be able to configure the VPN bridge using the SoftEther Server Manager (it gets from the DHCP on the remote router):

Choose "New Setting", and the IP address of the raspberry PI (eth0, as the host name you will connect to.

Click connect

Choose a password

Click OK

Go with default, and click next

Press yes (or "Ja" if you are Norwegian :-))

Click "Step 2" "Configure Connection settings". the host name here will be the softether VPN server that you connect to at the HQ office. When you install the VPN server in HQ you will get the option to use a address in the cloud provided by SoftEther (, or a dynamic DNS name (requires a NAT'ed open port on your router to the VPN server).
 I have set my own DNS address for the HQ VPN server, as I own a DNS server and a domain ( The user and password also have to be set at this VPN server prior to your connection from the bridge VPN (in my case the user is pi with password pi)

Connection is successful

For the local bridge I chose the network card that is not connected to the remote router (eth0), as I will connect my computer to the USB Ethernet card (eth1)

All done

I connect my windows PC to the USB card (eth1) on the raspberry, and now it gets an IP address from the "HQ office" router (

Make sure the serva64 is running on the network, and reboot the PC (in my case is the same machine as I have configured the VPN bridge with) connected to the raspberry USB card and remeber to press F12 for network boot :-)

It actually works :-)

Installation time is of course dependent on image size and internet connection speed.