How To

A family member of mine has a Dell Alienware Area 51 r2, which suddenly – stopped working. We tried all sorts of things to get it working again but nothing worked. We eventually came to the conclusion that the BIOS was corrupt. When the power button was pressed:

• The machine switched on and the fans spun up.
• The LED light strips on the front of the case illuminated

But nothing more. There were no post messages, nothing from the bios at all on screen. No beeps, nothing at all. I found some posts about possible BIOS corruption and by gathering all of that information together we were able to bring it back to life. Horray!

We also spoke to Dell, they offered no useful advice, but did offer a replacement motherboard for £280. We felt this was too much money to spend on an this machine.

To save you the hassle of having to find all of the required files, software and guidance I have written it up here and done a video for you:

How to Flash the BIOS of the Dell Alienware Area 51 r2

Because the machine was completely unbootable, it was not possible to flash the BIOS using the hardware itself. So I bought a cheap USB CH341A BIOS programming tool from Amazon. To see if I could reflash the chip using a working machine.

Software and Hardware Requirements

If your Alienware Area 51 r2 is suffering from the same problem and you want to try this out, you will need the following:

• Hardware
  • A separate working machine.
  • A CH341A Bios Programmer.
  • I used a Belkin USB Extension cable, but if your working machine is close, this is not required.
• Software
  • CH341SER.EXE – USB to serial driver.
  • CH341PAR.EXE – Multiprotocol interface driver.
  • AsProgrammer.
  • Dell Alienware Area 51 r2 BIOS image.

Once you have installed all of the software. you are ready to continue and setup the hardware.

Connecting the USB Programmer

To connect the my working computer to the the BIOS chip on the Alienware Area 51 r2, I did the following:

• Removed the covers from both sides of the case.
• Completely disconnected the mains power.
• Laid the machine on it’s side with the motherboard exposed.
• Plugged the CH341A USB Programmer into a USB3 port on my working machine.
  • Attached the chip clamp to the BIOS chip on the mother board.

I think this YouTube video is worth watching just to get an overview of the CH341 before continuing with the process.

Here is an image of the motherboard that shows the location of the BIOS chip. It is sitting between a heatsink and the printed image of the Alien head. In the image below pin one of the chip is on the bottom right hand side of the chip and it has a small circle to indicate that it is chip 1.

I didn’t change the setup of the USB Programmer out of the box, it looks like this:

Note the red cable on the ribbon, this also denotes pin one and should be connected to pin one on the BIOS chip. It is quite tricky to get the clamp on to the chip between the heatsink and the SPI1 connector just below it. It took me a number of attempts to get a positive connection. You will know if you have connected it correctly or not in the next step when you fire up the programming tool. ]

Here you can see the clamp connected and it is slightly bending the pins of the SPI1 connector, but I pushed them back after the process was complete:

Run AsProgrammer

With all the drivers installed and the hardware connected you can run AsProgrammer. The first thing to do is change the hardware settings to CH341a:

Next, you can ensure the chip is properly connected by clicking on the Read-ID Button:

If it brings up a possible list of ICs like the image above, then you are good to continue. I didn’t know what the correct option was, so I just clicked the first one.

If it cannot recognise the chip it will just show this:

When you are sure you have your chip properly connected, you can move on to the next step.

Backup the corrupt BIOS

There seemed to be little value in taking a backup of the current BIOS as it didn’t work anyway. But I took one just in case, and I would recommend you to do the same. It only takes a few minutes and it is only 16Mb.

Write the new BIOS

With the existing BIOS backup complete, you can write the downloaded BIOS Image to the chip. Click on the Open File button and then press the down arrow next to Program IC and choose Unprotect -> erase -> program -> verify.

It took about 3 minutes to write the BIOS back to the chip on this machine and AsProgrammer shows a nice progress bar to indicate progress. The USB Programmer itself has a small LED to indicate that it is reading/writing.

Disconnect Programmer and Clear the CMOS

Once the flashing process is complete, disconnected the clamp from the BIOS chip. Then, before trying to boot for the first time, I suggest that you clear the CMOS. Ensure there is no power connected to the machine and then:

• Locate the CMOS jumper (CLEAR_CMOS1) on the motherboard. It can be found just underneath the coin cell battery.
• Remove the jumper plug from pins 2 and 3 and fix it on pins 1 and 2.
• Wait for approximately five seconds to clear the CMOS setting.
• Remove the jumper plug from pins 1 and 2 and replace it on pins 2 and 3.

You are now ready to try booting the machine for the first time!

First Boot

The first time I booted the machine it had lost of all its previous settings and returned to defaults. So I setup the basic boot settings again and then the machine was able to boot normally.

PCIe NVMe Upgrade

To celebrate the machines renewed life I decided to reinstall Windows on to a Samsung 970 EVOPlus which I had spare, which gave the machine a decent performance boost. Any NVMe drive would provide a big boost in performance over a SATA SSD. These were the figures I got from CrystalDiskMark:

I used one of these cheap NVMe to PCIe adapters from Amazon to install the Samsung 970 EVO Plus SSD into one of the spare PCIe slots:

Additional Resources

During this process I gathered a number of additional resources which I am uploading here just in case you might find them useful:

• Dell Alienware Area 51 r2 Service Manual
• MSI MS-7862 Motherboard Schematic (Top)
• MSI MS-7862 Motherboard Schematic (Bottom)
• MSI MS-7862 Motherboard Technical Information

Conclusion

Overall, I think this is an amazing result. Being able to repair a corrupt BIOS with such a cheap bit of hardware from Amazon is brilliant. Given the number of machines that this has happened to I think Dell should be providing repair or replacement free of charge outside of the warranty period, but I can equally understand why they would choose not to.

After a conversation with a customer today, I needed to create an easy way to monitor RDP authentications. This turned out to be more difficult than I expected. We suspected that some accounts had been compromised.

I decided to combine a few things to enrich the data from the event log and make analysis simple:

• A custom event log trigger to execute a PowerShell Script.
• IPStack to enrich the client IP Information.
• A streaming PowerBI Dataset to record and visualise the data.
  This video on Streaming datasets from Patrick Leblanc was the inspiration.

It worked out pretty well, here is a screenshot of the Power BI Report:

Step one: Triggering an event when a user successfully authenticates an RDS Session

When a user logs on to a terminal server a number of events are recorded in the event log. I found event 4624 with a logon type of 10 is the easiest to attach to and provides a good source of data.

There is a good post on Technet which describes how to trigger a PowerShell script when a Windows Event is logged. Follow those instructions but make the following changes to the XML export routine.

Trigger the event to fire on Event ID 4624 and Logon Type 10

Because multiple 4624 events occur whenever an RDS session is logged on, you need to create a custom XML Filter in the event log to further narrow down the results to show only those that have Logon Type set to 10, as per the following:

<QueryList>
  <Query Id="0">
    <Select Path="Security">
		*[System[(EventID=4624)]]
		and
		*[EventData[Data[@Name='LogonType'] and (Data='10')]]
	</Select>
  </Query>
</QueryList>

Although this filter works fine in the event viewer, if you create a trigger from it, it will only filter on Event ID 4624, which causes the PowerShell script to execute too many times.

We also need to extract the Event Record ID from the trigger to be sent to the script. I’ve put the example XML on to pastebin:

Click here to see the XML Code changes required

Once you have modified the XML Scheduled Task file, recreate the task as per the technet article.

Step Two: Tweak the scheduled task

After you have created the trigger on event ID 4624 you need to modify it slightly to allow parallel execution. If multiple people logon at the same time, you still want the script to execute.

Here is my scheduled task setup:

Step Three: Powershell Script to Post Successful Terminal Server Authentications to PowerBI

Next up is the actual PowerShell Script that posts event log data to Power BI. The basic flow of the script is like this:

1. Receive the Event Record ID from the Scheduled Task and query the event log for full details of the event.
2. Check the Logon Type was “10”. This is the logon type associated with a Terminal Server session.
3. Extract the Information from the XML of the Event Log
4. Connect to IP Stack and query it for information regarding the IP Address
5. Create a JSON payload and send it to PowerBI for further analysis.

Here is the script:

param([string]$eventRecordID = "none")

$DebugPreference = "Continue"
#The PowerBI Streaming Data Set Endpoint and IP Stack API Key
$PBIendpoint = "Replace_With_PBI_Endpoint"
$IPStackAPIKey="Replace_With_IP_Stack_API_Key"

Write-Debug "Event Record ID is $eventRecordID"

if ($eventRecordID -ne "none") {
    #Get the event detail for event ID 4624 (Successful Logon)
    $evtPath = @"
        <QueryList>
          <Query Id='0' Path='Security'>
            <Select Path='Security'>
              *[System[(EventRecordID=$eventRecordID)]]
            </Select>
          </Query>
        </QueryList>
"@

    $event = get-winevent -LogName 'Security' -FilterXPath "$evtPath"
    $eventXML = [xml]$event.ToXML()
    $logonType = $eventXML.Event.EventData.Data[8].'#text'

    #Check the logon type is 10 (Remote Desktop)
    if ($logonType -eq "10")
    {
        Write-Debug "Logon Type is 10, sending data to Power BI"

	    $eventTime = $event.TimeCreated.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
	    $eventUser = $eventXML.Event.EventData.Data[5].'#text'.ToString() 
	    $eventClientIP = $eventXML.Event.EventData.Data[18].'#text'.ToString()

	    
	    $ipInfo = Invoke-WebRequest `
            "http://api.ipstack.com/$eventClientIP`?access_key=$IPStackAPIKey" -Method POST |
            ConvertFrom-JSON

	    $payload = @{
	        "Time" ="$eventTime"
	        "User" ="$eventUser"
	        "Client IP" = "$($eventClientIP)"
	        "Continent" = "$($ipInfo.continent_code)"
	        "Country" = "$($ipInfo.country_code)"
	        "Region" = "$($ipInfo.region_name)"
	        "Zip" = "$($ipInfo.zip)"
	        "latitude" ="$($ipInfo.latitude)"
	        "longitude" ="$($ipInfo.longitude)"
	    }
	    Invoke-RestMethod -Method Post -Uri "$PBIendpoint" -Body (ConvertTo-Json @($payload))
    }
    else
    {
        Write-Debug "Logon Type is $logonType, not logging"
    }
}
else
{
    Write-Debug "No event information passed to script"
}

Once the data is in PowerBI, it is simple to create a report to see the following information about the users of your terminal server environment:

• Who is logging on
• When they are logging on
• The country they are in
• The location within that country

IPStack also provide a threat level based on the reputation of the IP, but I was using a free account, so that information was not available to me.

Create your PowerBI Streaming Dataset

Follow the video Patrick Leblanc from Guy in a Cube did on creating a streaming dataset in Power BI:

This is how to configure the Streaming dataset for use with the PowerShell script above:

Step Four: Build the Power BI Report

Building the report is pretty simple, and once it was running I could immediately identify three separate accounts that had been compromised:

Out of interest I shadowed the compromised accounts on the terminal server before securing them, just to see what they were getting up to. It was mainly a lot of mass emailing via gmail and activity on “tagged.com” communicating with guys looking to buy a “pet”:

I’m pretty pleased with how it turned out, now it is dead easy to monitor terminal server sessions via PowerBI and so much more usable than the event log. The data comes through to PowerBI virtually instantly, so it’s a really good use case.

I look after quite a number of servers, many of which are different flavours of Unix and Linux. Checking disk usage is easy with the df command but I wanted to setup something automatic, where I could get a view of all the systems at once. I wanted the disk usage from every system, regardless of operating system to end up in an Excel spreadsheet for review, something like this:

Use awk to produce JSON from the df command

The df command has a “-P” option which will produce Posix style output. This ensures the output is the same regardless of the operating system generating the output. Also to ensure the size output was the same I used the -k option. So the df command I used is:

df -P -k | grep -v "/snap/core"

Which produces output like this:

Filesystem     1024-blocks     Used Available Capacity Mounted on
udev               1988700        0   1988700       0% /dev
tmpfs               403972     1092    402880       1% /run
/dev/sda2         32893712 17614104  13585656      57% /
tmpfs              2019852        0   2019852       0% /dev/shm
tmpfs                 5120        0      5120       0% /run/lock
tmpfs              2019852        0   2019852       0% /sys/fs/cgroup
/dev/sdb1        263174148    61536 249690892       1% /u
tmpfs               403968        0    403968       0% /run/user/1000

I wanted to remove some of the file systems from the report, so they were filtered out with grep.

Convert the output of df to JSON

Next I converted the output of the df command to JSON format using awk so that it be consumed with Microsoft Flow. I passed some variables into the awk script make it easy to identify the machine later and to generate a unique key (for Microsoft Flow):

BEGIN {
  printf "{"
  printf "\"Server\": \"" machine "\","
  printf "\"Location\": \"" location "\","
  printf "\"FileSystems\":["
}

{
  if ($1 != "Filesystem") {
    if (i) {
      printf ","
      }
      printf "{\"mount\":\"" $6 "\",\"size\":\"" $2 "\",\"used\":\"" $3 \
              "\",\"avail\":\"" $4 "\",\"use%\":\"" $5 "\",\"key\" :\"" (machine " " location " " $6) "\"}"
      i++
  }
}

END {
  print "]}"
}

This converts the df input into JSON:

{
	"Server": "Ubuntu 18.04 Test",
	"Location": "4D-DC",
	"FileSystems": [{
		"mount": "/dev",
		"size": "1988700",
		"used": "0",
		"avail": "1988700",
		"use%": "0%",
		"key": "Ubuntu 18.04 Test 4D-DC /dev"
	}, {
		"mount": "/run",
		"size": "403972",
		"used": "1092",
		"avail": "402880",
		"use%": "1%",
		"key": "Ubuntu 18.04 Test 4D-DC /run"
	}, {
		"mount": "/",
		"size": "32893712",
		"used": "17614104",
		"avail": "13585656",
		"use%": "57%",
		"key": "Ubuntu 18.04 Test 4D-DC /"
	}, {
		"mount": "/dev/shm",
		"size": "2019852",
		"used": "0",
		"avail": "2019852",
		"use%": "0%",
		"key": "Ubuntu 18.04 Test 4D-DC /dev/shm"
	}, {
		"mount": "/run/lock",
		"size": "5120",
		"used": "0",
		"avail": "5120",
		"use%": "0%",
		"key": "Ubuntu 18.04 Test 4D-DC /run/lock"
	}, {
		"mount": "/sys/fs/cgroup",
		"size": "2019852",
		"used": "0",
		"avail": "2019852",
		"use%": "0%",
		"key": "Ubuntu 18.04 Test 4D-DC /sys/fs/cgroup"
	}, {
		"mount": "/u",
		"size": "263174148",
		"used": "61536",
		"avail": "249690892",
		"use%": "1%",
		"key": "Ubuntu 18.04 Test 4D-DC /u"
	}, {
		"mount": "/run/user/1000",
		"size": "403968",
		"used": "0",
		"avail": "403968",
		"use%": "0%",
		"key": "Ubuntu 18.04 Test 4D-DC /run/user/1000"
	}]
}

Now that the format of the df output was in JSON format, I wanted to put it all the data into an Excel Spreadsheet, which I could easily keep up to date with a cron job.

Consume the JSON with a HTTP request in Microsoft Flow

The next step was to consume the data into Microsoft Flow. I created a simple four step flow:

1. Consume the JSON with a simple HTTP Post:
   
2. Update Existing Rows in the Spreadsheet:
   
3. If step two failed (i.e) no matching row existed, then add new rows:
   
4. Terminate the flow:
   

This all works really well, I tested it on IBM AIX, Sco Openserver 5 and various versions of Ubuntu, all worked without a problem.

Putting it all together

There is some detail missing from the above, so I am going to paste all of the code here so that if you want to replicate the functionality you can do so easily:

freeSpaceFlow.sh

This shell script it what puts everything together, run it like this:

./freeSpaceFlow.sh machineName Location

This is the code

#!/bin/sh
df -P -k | \
        grep -v "/snap/core" | \
        /usr/bin/awk -v machine="$1" -v location="$2" -f ./freespace.awk | \
        curl -X POST \
        "https://prod-82.westeurope.logic.azure.com:443/workflows/...." \
        -H "accept: application/json" \
        -H "Content-Type: application/json" \
        -d @-

It’s fairly simple to see what it does, but I will quickly explain:

• Runs the df command and pipes the output to grep.
• Uses grep to remove unwanted filesystems and pipes to awk.
• awk runs “freespace.awk” and creates json and pipes to curl.
• curl consumes stdin of the awk script for the payload to posts the data to Microsoft Flow.

Lets’ see the flow in action:

The Excel document is just a simple table with some formulas to convert the values to Gigabytes.

It feels great to bring data in from Unix with curl over to Excel via flow, it seems to be really reliable too.