Dissecting the //build/ Badge (Part 2)

A little under a month ago, I dissolved Paul Thurrott's //build/ badge to reveal an embedded NFC integrated circuit (IC). But I had to stop short of actually reading its data due to the lack of a proper NFC reader. (Windows Phone 8 doesn't give you raw NFC access.) I purchased an ACS ACR122T and after weeks of waiting and experimenting I can now complete the story. So, let's start off with a correction. In Part 1, I incorrectly guessed that the IC was a MIFARE Ultralight. Turns out, it's an older MIFARE Classic 1K complete with key-based security. But before I wrote the IC off as encrypted and inaccessible, I learned that these ICs were compromised back in 2008 -- with a card-only attack following in early 2009.

Let's take a brief moment to talk about these keys.

Without getting too technical, these NFC ICs have chunks of data. Each chunk of data can be secured via a pair of keys -- A and B. Each of these keys can be used separately to access the data it protects. (For example, you may give a read-only key A to conference vendors, while maintaining the read-write key B for administrative purposes.)

Back to the badge.

Without access to an authorized //build/ badge reader, I had to use a software implementation (mfcuk) of the card-only attack I mentioned earlier to recover keys A and B. After weeks of painfully fiddling with the timings of the attack, I successfully recovered key B on one chunk of data. (I then made quick work of the rest of the keys/chunks using another attack [mfoc].)

Key A was recovered but isn't worth sharing because it appears to be unique per badge. (Tested with two badges.) Key A is usually programmed as a read-only key -- presumably for vendors on the conference floor. But given its uniqueness I'm confused as to how vendors would obtain a valid key at scan time. Perhaps the readers were networked to a key management system? Or maybe Key A is computed at runtime using a mash of the badge unique ID and a shared secret? Or maybe there's a handful of keys per attendee group (e.g. media, student, presenter). What do you think?

Key B is static, thankfully. On two badges I examined, Key B was given write permissions card-wide. So I named it The //build/ Badge Administrative Key. That key is f4a9ef2afc6d.

Using the Badge Administrative Key, I dumped out the entire //build/ badge. Surprisingly, it's not empty! It contains the following information:

  • Two sets of identifiers(?) (6 digit, 4 digit) (e.g. 756552, 1269)
  • Badge Full Name
  • Badge Title
  • Full address
  • Phone number
  • Email address
  • Affiliation label, if applicable (e.g. Media)

So if you're planning to toss the badge into the trash, you may want first wipe the IC. An alternate solution involves hammering the shit out of the badge. But if you're a developer looking to dip into NFC, you may want to salvage the tag and format it to NDEF specs so you have something Windows Phone compatible to play with.

Regardless, case closed. Oh, and Paul -- Sorry about your badge, bro.

My Crazy Adventures with RemoteFX, Part Two

[This is part two of the "My Crazy Adventures with RemoteFX" series] Back in Part 1, I left off just before describing what was needed to set up RemoteFX (in a VDI scenario). Let's dive into that now.

Software requirements

It shouldn't come as a shock that Windows Server is required for RemoteFX. Specifically, you'll need to install:

  • Windows Server 2008 R2 SP1 or higher (I am specifically covering Windows Server 2012)
  • Remote Desktop Services (see licensing below)
  • Hyper-V

Hardware requirements

While RemoteFX inherits its hardware compatibility from Windows itself, you will need two key pieces of hardware:

  • A processor capable of Second Level Address Translation (SLAT)*. Intel calls their implementation of this technology Extended Page Table (EPT). AMD instead chose Rapid Virtualization Indexing (RVI). Newer processors today have this technology; if you want to check if your processor is supported, use Sysinternals Coreinfo.
  • A DirectX 11* capable GPU (with WDDM 1.2 drivers). Previous versions of RemoteFX required a DirectX 10.0 card. But with RemoteFX's ability to now handle DirectX 11-class graphics, this requirement has been bumped up. If you're looking to color within the lines, you'll need to drop some serious cash for an officially supported video card (e.g. AMD FirePro). But in reality and in my testing, a consumer card -- like the Radeon 5970 HD -- will work slightly slower but otherwise operate just fine.

But wait, what do the little *s mean? Those stars mean these requirements can be bypassed, using some trickery. Using a non-SLAT processor, however, incurs a huge performance penalty and isn't worth the trouble. Bypassing the DirectX 11 requirement -- for say a DirectX 10 card -- isn't as crazy and could make sense in scenarios where DirectX 11 acceleration isn't needed. But that's a very dark cave to be wandering in. Get a newer card.

That said, Hyper-V on Windows Server 8 supports a software-emulated GPU that provides DirectX 11-class support without RemoteFX. I could not, however, convince my 3D applications it existed so won't be exploring that option further.

Licensing requirements

RemoteFX has no ties to the host OS's licensing status. But Because RemoteFX is ultimately a Remote Desktop Services (RDS) technology, RDS licensing applies. That means you need to obtain a license per client accessing the server and have a license server installed on your network somewhere. Per client in this case can mean either a device or user, depending on what makes sense. But don't let this scare you. RDS provides an ample 180-day (6 month) grace period before a license server needs to be installed. (After setting that up, you're afforded another 90 days in way of temporary access licenses.)

If you run out of time, you can of course purchase a retail copy of Windows Server and some RDS CALs. But for testing purposes, I would instead recommend looking into acquiring a MSDN subscription. With any level of subscription, you'll gain access to Windows Server and RDS CALs. (Just make sure you read the MSDN Terms of Use to ensure you're eligible.)

Looking forward

In the next post, I'll cover actual installation and configuration. Stay tuned!

Dissecting the //build/ Badge (Part 1)

If you were at //build/ this year, you probably remember tapping your badge on a reader before picking up your free Surface and Nokia Lumia 920 devices. It turns out, the badge hides NFC tech as opposed to that boring ol' RFID stuff. Tear down photos follow.


But what secrets does it store within? Sadly, the tag doesn't appear to have been NDEF formatted so reading it with Windows Phone is out. (It is detected just fine, though.) I ordered an ACR122T reader/writer to lend a hand so check back in a week or so for the big reveal.

A closer look at the Windows 8 post-RTM update process

So, last week, Steven Sinofsky announced the availability of a cumulative update for Windows 8. Bundled with that announcement was some insight into what happens with fixes made after the OS goes gold (or RTM). Specifically, Sinofsky explained that certain fixes get delivered to OEMs prior to the public:

We would often create dozens of changes for each OEM for these new PCs. Those changes would be deployed during manufacturing of those PCs and thus would be invisible to customers. While those changes could potentially apply to a broader range of PCs, we did not have in place the testing and certification to broadly distribute these updates. As a result, customers would have to wait until the first service pack to see these enhancements.

He continued, indicating that with Windows 8 some internal processes changed, allowing Microsoft to deliver these updates sooner than general availability (GA):

During the final months of Windows 8 we challenged ourselves to create the tools and processes to be able to deliver these “post-RTM” updates sooner than a service pack. By developing better test automation and test coverage tools we are happy to say that Windows 8 will be totally up to date for all customers starting at General Availability. If you are an MSDN or enterprise customer, these updates will be available for your Windows 8 PCs via Windows Update as of today (October 9), following our standard cadence for Windows Updates on the second Tuesday of each month at about 10:00am.

Sounds good to me.

But let’s not fool ourselves into thinking this process is new. Gregg Keizer (Computerworld) fell into that trap, writing:

In Microsoft's terminology, RTM designates the point at which it considers the code completed, and ready to ship to computer makers for installing on new PCs. Microsoft has never updated a version of Windows between RTM and when the OS hits retail and PCs powered by it reach stores.

Matthew Siegler did too, mumbling:

Probably not the best sign in the world that Microsoft has to release service packs [sic] to the RTM version of Windows 8 before it has even launched. I mean, why declare RTM then? Well one possibility is that you’re working to meet a deadline rather than releasing when a product is fully baked.

Look, guys. Microsoft has been updating Windows in this manner for ages – at least since Windows Vista. That was so 6 years ago. To be more specific, Windows Vista saw a heap of updates, including the infamous Ultimate Extras pack, January 29, 2007 (a day before GA). Windows 7 received similar reliability updates on October 12, 2009 (10 days before GA).

Here's what the timelines look like, with the pre-GA/post-RTM release cadences in red:

What’s really new here is the delivery of updates previously reserved for OEM first use. (Ever wondered why OEMs had those atrocious software download pages with a weird assortment of Windows hotfixes?) It is the inclusion of these specific updates as part of the old patch delivery cycle that likely required the tooling and engineering improvements Sinofsky mentioned -- something definitely worth lauding.