Physically Hacking Windows Computers via FireWire

This is impressive:

With Winlockpwn, the attacker connects a Linux machine to the Firewire port on the victim’s machine. The attacker then gets full read-and-write memory access and the tool deactivates Windows’s password protection that resides in local memory. Then he or she has carte blanche to steal passwords or drop rootkits and keyloggers onto the machine.

Full disk encryption seems like the only defense here.

Posted on March 13, 2008 at 11:54 AM58 Comments


Ian Eiloart March 13, 2008 12:12 PM

… with superglue.

“Full disk encryption”? Didn’t we discover recently that the RAM contains the key for encrypted disks?

LeoNerd March 13, 2008 12:24 PM

Surely the disk key is stored in RAM somewhere, and thus even a full disk encryption is pointless against this attack?

mfheadcase March 13, 2008 12:34 PM

Disk encryption should still help if the attacker is starting on a cold machine… fully powered down not in hibernation or sleep mode. Personally i am glad i went cheap on my laptop, no firewire, no pcmcia slot…

Hands off March 13, 2008 12:36 PM

“Full disk encryption seems like the only defense here.”

The only defense? How about saying “no thanks” when the attacker asks, “Hey, can I connect this cable from my computer to yours?” ?

Jason March 13, 2008 12:44 PM


What intern put this on your blog! This is not the Bruce I know …..

If the machine is running disk encryption is not helping you here. Encrypted files maybe if the user is not saving the password in memory.

cheers m8

Schmurtz March 13, 2008 12:45 PM

The only solution is to disable DMA from firewire external devices.

Full disk encryption is only a solution to protect shutdown/sleeping computers.

(this vulnerability is know since 2004, and identified by CVE code CAN-2004-1038)

Jeff Craig March 13, 2008 12:53 PM

As has been pointed out, Full Disk Encryption is of absolutely no help in this situation.

Princeton’s recent ColdBoot ( paper showed that Full Disk encryption keys can be pulled from memory. Therefore, using this attack, an attacker can easily gain the encryption keys using the same mechanisms discussed in the above paper. This is nothing more than a different method to get a full memory dump, and it would probably be more reliable.

Todd Knarr March 13, 2008 1:01 PM

Full-disk encryption will help. Remember that the situation isn’t an attacker attaching a Firewire device to a powered-up machine, it’s an attacker stealing the machine and using a Firewire device to try and attack it. If the machine was fully powered-down (not in sleep or hibernate mode), then when it powers up the password will not be in memory. It’ll have to be entered by the attacker into the appropriate dialog during boot. But the attacker doesn’t know the password, so he can’t enter it. The disk remains encrypted, and not all the DMA access in the world can decrypt it without the password (assuming the encryption is strong).

If the machine is in sleep or hibernate mode with the contents of memory preserved, of course, all bets are off. In that case the attacker doesn’t need to extract the password, since the system will decrypt the disk for him once the password prompt at wake-up has been bypassed.

Walter March 13, 2008 1:21 PM

Surely it shouldn’t be too difficult for the OS to disable the FireWire port when the screen saver is active?

SnappyCrunch March 13, 2008 1:23 PM

If they already have physical access to the computer, then it’s all over anyway.

Guillaume March 13, 2008 1:28 PM

This is memory patching we are talking about. The cross platform question you have to ask yourself is this :

Can you boot without authentication up to a point were the security subsystem is loaded in memory ?

If the answer is yes, you are vulnerable to hardware based attacks.

Full disk encryption is a way of requiring authentication to boot. FDE like BitLocker in TPM only mode will not prevent hardware attacks.

Chris Adams March 13, 2008 2:16 PM

I find it interesting to see the time delay between the Mac and Windows security worlds – the first Firewire DMA-based hack I remember was the 2002 FireStarter attack. Apple modified their drivers to disable device DMA by the time 10.3 came out.

This was very widely discussed in various Mac news forums, blogs, etc. and a few security conferences. At some point the Linux crowd started making the same fixes and yet, somehow, it took half a decade before this finally got the Windows security community?

kamper March 13, 2008 2:24 PM


That can’t really be done. What if you’ve got an external drive connected and something is using it while you’re away from the monitor? You don’t want that to shut down.

What if people are logged into the machine remotely via ssh or vnc or rdp or whathaveyou? Is it easy to tell when the ‘screensaver’ is on then? Sure, this could be configurable for the end user, but that’s a pain.

Jacob Appelbaum March 13, 2008 2:47 PM

Re: Todd Knar

Some modes of full disk encryption, such as bitlocker basic, will not protect you against this. The password may not be in memory but in basic bitlocker mode, the disk crypto keys. Once you have those, you can extract the SAM file and start cracking.

Skorj March 13, 2008 2:58 PM

If you can attach a kernel-mode debugger to any Windows box (requires a firewire or serial-port connection), you completely “own” it in every way that is possible to own a machine.

Full disk encryption prevents changing the boot.ini file, which defeats this easy way of attacking a machine that you have physial access to.

It wouldn’t seem to prevent the attack described in TFA, however. I knew there was a reason that I uninstalled my firewire driver and physically disconnected the port.

Harry Johnston March 13, 2008 2:59 PM

This is a serious problem for computers in public places, such as teaching labs, libraries, or computer shops. The only realistic way to protect such computers from this sort of attack is to disable the firewire ports (and of course other ports like PCMCIA which provide access to the internal bus).

It could also be a problem for people with access to very valuable data or systems who use laptops in public places, e.g., while traveling. In principle at least the attacking device could be made small enough that it could be attached to a laptop without being noticed.

Harry Johnston March 13, 2008 3:12 PM

Todd Knarr: the attack isn’t necessarily against a machine that’s switched off, or even in hibernation. It’s so easy and quick that there are plenty of situations it could be used against machines that are running.

Gotta love the “security experts” who say this shouldn’t be surprising and that’s it’s a “feature”. Somehow the phrase “defective by design” springs to mind!

Michael Ash March 13, 2008 3:40 PM

@Harry Johnston

It certainly isn’t surprising to anyone who knows how firewire works. Unauthentcated DMA is an integral part of the system and the ability to do this kind of thing has been pretty obvious since it was introduced. The only surprising thing is that people are still surprised that you can break computer security with it.

As for “defective by design”, I would prefer to characterize it as “consciously trading security for performance”. The ability to do DMA adds a great deal of performance. I’m sure that the designers knew it could be used to defeat security, but it’s also fairly well known that you’re doomed against an attacker with physical access anyway. Most OSes probably have vulnerabilities in their USB stacks which could be used to similar effect, and most computer allow rebooting from a CD or memory stick with arbitrary contents.

Jeremy H March 13, 2008 3:43 PM

This was demonstrated a long time ago. USB or FireWire devices can use DMA to bypass the OS and all of its protection mechanisms. It just goes in and reads your memory directly.

It’s one of those ‘doh’ moments when you realize how it works, and it demonstrates how security is a hard problem because you have to prove a negative (something can’t happen) rather than a positive (like the rest of the requirements).

From 2005:

Todd Knarr March 13, 2008 3:46 PM

Harry: I tend to notice people trying to plug things into a machine I’m using. 🙂 And my rule of thumb is that if I’m not in physical control of the machine (eg. I’ve gotten up to go do something away from the machine) it’s the same as it being in the physical possession of an attacker and should be secured appropriately.

And yes, bus-mastering DMA is a feature. It’s heavily used by almost all the hardware in your computer, from the disk drives to the video card. It’s also applicable to eSATA interfaces, BTW.

alan March 13, 2008 4:03 PM

I have seen gaffed mice that contain a usb drive for that instant malware installation experience.

Autorun is as much of a danger as these DMA hacks.

It surprises me that any workplace allows Windows to be used. (He says posting from work on a Windows machine.)

Harry Johnston March 13, 2008 4:35 PM


The point is most people don’t know that they’re trading away their security by having a firewire port active. At least the silly things should come with a health warning!

Physical access to a machine by an attacker should not, and, if the designers did their job properly, would not, mean that you are “doomed”. Of course you have to make sure the attacker can’t open the case, but that can be satisfactorily addressed.

For example, in our teaching labs, the computer cases are wired to the alarm system.


If a pickpocket can remove your wallet without you noticing, it doesn’t seem much of a stretch to plug something into your computer.


I’m told autorun has secure defaults in Vista. And even in Windows XP it can be turned off. Unfortunately as yet no version of Windows allows you to disable DMA on external devices.

Else March 13, 2008 5:13 PM

I saw metlstorm (aka Adam Boileau) demonstrate this at Ruxcon 2 years ago. I don’t see how full disk encryption resolves anything. You’re writing to memory, and full disk encryption necessitates transparent access to the filesystem – once the filesystem has been unlocked all the standard file operations will work.

He also demonstrated pulling the encrypted disk password out of memory on a linux box he plugged into via firewire. It was truncated after (i think) about 16 characters, but many people may not have passwords longer than that anyway.

This may be defense after the fact, but having configurable memory areas on the firewire chip will mitigate this. If the OS (or perhaps even the bios) can configure the chip to allow access to only certain memory areas then it’s just another shared memory space, albeit one accessed without the OS’s knowledge. But the OS remains in control insofar as letting the chip know which areas of memory it is permitted to make visible over the firewire port, and anything else is unavailable.

Todd Knarr March 13, 2008 5:19 PM

Harry: a pickpocket gets at my wallet by approaching from where I can’t see him, or by distracting me for the moment it takes to get my wallet from my pocket. By contrast, my laptop’s in front of me and I’m looking at it, and he’s going to need to have the Firewire cable plugged in for considerably more than a second to do anything. Even the best pickpocket won’t be able to lift my wallet if doing so requires him to stand in front of me rummaging through the 6 inner pockets of my coat to find the wallet.

Mark March 13, 2008 5:20 PM

Probably being very ignorant here, but is it not possible to store the key on a removable usb stick rather than in memory? (removable so you could take the stick with you if you leave the machine unattended and/or asleep/hibernated.)

If it’s not possible for the key that handles sleep/hibernation/wakeup of an FDE-ed OS to be on a removable stick, is it possible to have all encryption/decryption requests immediately beyond waking the machine up use a separate key that could be on a removable stick?

Finally, what about plausible deniability whereby if you do use a separate stick, you’d have two passwords for use on wakeup, one of which would be a duress’ one to awake to a deniable OS and wipe memory?

Jeff Craig March 13, 2008 5:22 PM

@Todd Knarr:

I will concede, that in the event that the system is completely shutdown, than Full-Disk Encryption will mitigate this attack.

However, there have long been means to bypass the Windows log-on prompt if you have physical access to the machine. From that perspective, while the ability to bypass Windows logon is interesting, it is not a particularly new or frightening attack vector.

What can be gained from looking at the memory of a running machine via this exploit is more interesting, and more frightening. At least partially because full-disk encryption and other security technologies have little effectiveness under these circumstances.

Harry Johnston March 13, 2008 6:28 PM

Todd: I don’t see why an automated attack (inserting a rootkit, for example) couldn’t take place in a second or less once the cable/device was attached. And you aren’t likely to be looking at your laptop every second, even when you’re using it.

However, I’d guess neither of us know all that much about the art of picking pockets, so the debate is probably pointless. (I’m sure James Bond would be able to do it, though!)

Mr Bond March 13, 2008 6:56 PM

Without physical security, there are any number of ways to compromise the system.

To mitigate this attack, have a false firewire port that triggers a thermite reaction if used. 😉

Brian Carnell March 13, 2008 9:08 PM

A lot of silly comments here about the value (or lack thereof) of Full Disk Encryption. I run PGP Whole Disk Encryption on my laptop. Lets face it, if someone has physical access to my machine while it is running, then it is possible to recover the password in RAM (I don’t have a Firewire port, but someone could do the cold boot).

But that’s not the risk I’m concerned about with Whole Disk Encryption. Rather I’m concerned about the situation, which is common, where my laptop is turned off and being transported while I travel. If it is stolen, I don’t want to end up in the papers as one of those idiots who lost all his company’s SSNs, etc.

For ameliorating this risk, whole disk encryption works great. Someone who steals my laptop bag has to guess my long-assed secure passphrase to get at the data. Good luck.

Similarly, I occasionally transfer highly sensitive data on external hard drives from one machine to another. Yes, if you have physical access to either machine you could gank the password that I’m using on the Truecrypt volume of the external hard drive. But again my main concern is keeping the data safe should the hard drive be stolen in transit.

Just because its not magic pixie dust doesn’t mean disk encryption isn’t useful.

Harry Johnston March 13, 2008 10:11 PM


Did anybody say disk encryption wasn’t useful? All I can see is people saying that it isn’t useful against this particular attack, which is true (depending on the particular scenario you’re imagining and on the details of the disk encryption technology).

Anonymous Coward March 13, 2008 10:20 PM

Surely it shouldn’t be too difficult for the OS to
disable the FireWire port when the screen saver is active?

Great… So when I’m downloading a video of my kids from my camera, I’ll need to put the mouse into the automatic-rocking crib? (Or perhaps just remember to disable the screensaver…)

Guys, if I’ve got access to your computer, and it’s running, I’ve got access to everything. Not much is going to change that.

Even if it’s not running and the drive is encrypted… Most of the people out there will choose passwords like SECRET and LOVE. Half of the world has a sub-100 IQ.

Oh, and I seem to remember reading somewhere about how “good” IEEE1394 implementations route DMA through to Virtual-Memory Pages, limiting access appropriately at a slight performance cost.

Hmm. Then again, on the other hand, this has some real potential for cheating at World-of-Warcraft….

Harry Johnston March 13, 2008 10:33 PM

“Guys, if I’ve got access to your computer, and it’s running, I’ve got access to everything. Not much is going to change that.”

People keep saying this, and it just isn’t true; if the BIOS password is set and the case is alarmed, or if you’re being watched, I don’t see what you think you’re going to do – unless some idiot goes and designs an external port which provides direct access to memory, that is.

Filias Cupio March 14, 2008 12:10 AM

Notice the attacker doesn’t have to wander up to your computer and connect it to their computer, then sit there typing away and cackling evily. All they need to do is get you to plug some trojaned device into your firewire or USB port.

Anyone for a Trojan Mouse? Or a USB flash drive given away by a tech vendor at a conference – beware of geeks bearing gifts.

AngusSF March 14, 2008 1:10 AM

Here’s an interesting possibility for locking your laptop when you leave it: Blue Lock (currently Windows-only). The config file allows you to run programs when locking, these could include dismounting any TrueCrypt partitions, which would remove the key from RAM. So if you had a WDE-laptop AND also a separately encrypted partition on which all your critical data were stored, you could walk away knowing even the FireWire and RAM-freezing hacks wouldn’t get you.

Blue Lock is an application that locks your Windows PC if a particular Bluetooth device is not detected. For example, if you register your Bluetooth mobile phone with the program but then move away from your desk, the program will detect your phone is out of range and automatically lock your system, requiring the password to be entered to reactivate the system. Full Delphi source code is provided. Download Blue Lock and source here.

Configuration: It is possible to reconfigure the default settings by editing bluelock.conf, see the comments in the file for details.

Blue Lock can also be configured to launch an external program when it locks your system, e.g. to delete those incriminating files 😉 … simply edit the property launchOnLock in bluelock.conf.

Details here:

Phillip March 14, 2008 6:44 AM

Chris Adams:
I believe various IP attacks (ex: Ping of Death, Teardrop, etc.) were all discovered in various UNIX OSs LONG before MS Addressed them. I’m not sure, but perhaps even before MS even thought of Windows.

Ms lagging behind on known security exploits is nothing new. Nothing new to see here, move along. 😉

bobo March 14, 2008 7:00 AM

full disk encryption is good, even better when you have a yard full of geese and llama to alert you of trespassers, a crocodile in the moat, ankle biting dogs in the house to delay the intruders, a properly sealed cpu room, a security system which shuts down the cpus upon detection of the physical environment its housed in being intruded upon, and on and on.. by the time the intruders get through layer after layer of security, i bet those encryption keys are gone from memory.

The real lesson here is to set up as many roadblocks as possible before the intruder can even get to the cpus.

Garrett G March 14, 2008 10:19 AM

Disabling the firewire port (if you don’t need it) seems like a reasonable suggestion to defeat this particular attack vector.

That’s in addition to the other good security practices like FDE (for offline attacks), NX/XD+AV+limited user accounts+disabling unneeded services+firewalls+… for online attacks.

I agree with Brian C that FDE isn’t “magic pixie dust,” so an attack vector (in this case, an “online attack” vector) that “defeats FDE” doesn’t mean FDE isn’t useful. Just means that the attacker is forced to resort to another method of attack that, potentially, requires greater skill or luck.

BW March 14, 2008 10:50 AM

I don’t see why this should be contained to FireWire exclusively. Both USB and ESATA support DMA.

What I think would be interesting if someone created a fake ATA (or SATA) device that acquired DMA access then generated a virtual file system that gave the user access to the memory as if they were flat files. There are lots of ATA (and SATA) to USB and FireWire bridge devices out there. If you did it with ATA (IDE) then the production costs should be pretty cheap considering the general availability of IDE parts. Then if you integrated into it a flash drive, you could copy the systems memory to it.

Anonymous Coward too March 14, 2008 11:07 AM

As an information security professional, I’m more worried about the security of other people’s data than my own. I take measures similar to those that Bruce has described in previous blogs. However, when I heard about the Princeton study on defeating WDE, I disabled the hibernate function on my laptop and make sure to shut it down when its unattended. This being said, I also have a long complex password protecting the encrypted system.

The point that I’m trying to make is that vulnerabilities like this and the WDE attack highlight the importance of constantly reevaluating the assumptions upon which we base our thinking about security. As new attack vectors appear, old assumptions are invalidated and practices need to be adjusted to remain effective. How many people still think an 8 character complex password is still secure on a windows box? Who thinks its safe to travel with a WDE laptop in hibernate mode? These practices were previously thought to be reasonably safe but I think its safe to assume that they are still required or allowed by the vast majority of corporate security standards.

moo March 14, 2008 2:37 PM


Generally you can’t remove the key from the running machine because the key is used every time you access your encrypted disk (i.e. every time a sector is read or written, the key is used to encrypt or decrypt it).

If you stand up from the machine to go grab a beer from the fridge, you can’t temporarily “remove” the encryption key without also preventing ALL disk access to the encrypted partition until the key is restored. Also, it has to be in RAM to be fast enough for use, anyway.

I don’t think there’s really any solution to this problem other than to not have any Firewire ports in the machine and not ever allow the machine to be physically accessed by an attacker. (good luck.)

Skorj March 14, 2008 3:00 PM

If this attack works on USB as well as Firewire – wouldn’t it work on wireless USB? Wow, that’s some excitement waiting to happen!

bobdole March 14, 2008 10:08 PM

painful…it’s just sometimes painful to see how little bruce knows about the real world. “Whuzza?! D.M.A. attacks you say?! Well yer darn tootin’ I’ma gonna blog dat!”

I’m starting to think you are just posting stuff you don’t know anything about, saying it’s good or bad (doesn’t matter which), and then sifting through the replies to find out if you were right or not.

t3chnomanc3r March 15, 2008 9:02 AM

Removable smart cards, hardware encrypted USB flash drives, and built-in finger print readers all provide two important things: Removable secure “key” storage AND the ability to be unlocked independent of a host PC’s software.

So even if someone had your hibernating laptop & your “token” they would have to break the weakest link: the protection on the token. If the token simply stores a certificate or key data in the clear, having it is enough to get in so you’d have to separate the two; Further, with token secured using strong passphrase and/or biometrics, even if laptop & token were stolen together you’re damn well protected at the front door asuming no exploit.

Bottom line is what’s need is support from the OS. Ultimately to defeat RAM sniffing attacks you’re talking hardware FDE (think IronKey but for HDD/SSD) combined with it’s keys securely stored on removable drive. 100% Hardware solution = no keys in memory.

Anonymous March 15, 2008 9:02 AM

Removable smart cards, hardware encrypted USB flash drives, and built-in finger print readers all provide two important things: Removable secure “key” storage AND the ability to be unlocked independent of a host PC’s software.

So even if someone had your hibernating laptop & your “token” they would have to break the weakest link: the protection on the token. If the token simply stores a certificate or key data in the clear, having it is enough to get in so you’d have to separate the two; Further, with token secured using strong passphrase and/or biometrics, even if laptop & token were stolen together you’re damn well protected at the front door asuming no exploit.

Bottom line is what’s need is support from the OS. Ultimately to defeat RAM sniffing attacks you’re talking hardware FDE (think IronKey but for HDD/SSD) combined with it’s keys securely stored on removable drive. 100% Hardware solution = no keys in memory.

Peter N Biddle March 18, 2008 12:25 PM

BitLocker in advanced modes, with hibernate, will protect against this attack, as well as against RAM freezing attacks.

However if they have access to your machine when it’s up and running, then this should work.

It won’t, however, work across re-boots, as reading RAM won’t get you the second factor needed.

Blain Hamon March 18, 2008 2:28 PM

@Todd Knarr and Harry Johnston

Perhaps it’d be helpful to watch a pickpocket, then? Bob Arno is a white hat pickpocket.

It’s very possible to have unnoticed physical access if you’re in public. Perhaps the attacker accidentally spills a drink on you, and while he’s helping clean up the mess and drawing attention to drenched trousers and lifting up the laptop to make sure there’s no liquid underneath, your eyes won’t be on that USB port for a good half a minute.

Anonymous March 31, 2008 2:31 AM

And then they’re asking me ‘Why have you disabled firewire port on my PC?’ Oh, boy… There are situations when you can’t say ‘no, thanks’ to a potential attacker as you can’t foresee if he will try to connect a firewire HDD to the laptop right now, the day after tomorrow or next month. You either put a control on it or you don’t do anything and live with the fear that sometimes a serious data loss may happen in your company. It may sound strange in my practice that administrators don’t worry about port security because they think it’s impossible to implement such a protection without having a special knowledge in that. Of course all of us do some special security audits on occasion. But the question is – should you do a device security audit trail on a regular basis or not? I used to think that’s impossible to lockdown devices in Windows. I thought I had to have linux to manage devices that easy. Sure, every PC has a BIOS and disabling device – no more than selecting “Disabled” next to device control options. But then you have to password your BIOS to prevent users from changing the device settings back. However having a password set on user computer BIOS just adds pressure on your support team and nothing more. Remember the old trick with resetting BIOS some of us used back in the day. It has no real use except for problems with HID devices when you need to have users work with a USB mouse or a USB “whatever” and it doesn’t work because USB ports were disabled on a low level. So what do you do then? Go figure! I liked that Vista is much improved with its device management policies and special administrative templates for playing around with device security with removable storage protection. And still that wasn’t the best-fit solution for me (though it obviously holds some value). That’s mostly because of the poor management facilities that did not allow me to configure flexible rules to filter out all but some very concrete types of devices from use. Secondly, this solution doesn’t provide reliable tracing and reporting which makes it impossible to maintain within changing environments. I am not saying that it’s an easy task to do that in Windows. But despite all my fears and delusions I’ve finally found an elegant solution that allowed me to fine-tune device security throughout my domain. The answer was a desktop management solution. In my case, I found that was Scriptlogic’s Desktop Authority. I loved it for its broad device type support , ease of device access permission management and powerful reporting. The good thing about it was that I could specify a needed level of access depending on the user, some Active Directory properties associated with the user (such as user membership) and hardware class. The last thing really helps with managing laptops. You know that’s so hard to manage laptops nowadays – they are so feature-packed so you often get stuck when it turns that you can’t turn the Firewire off forever. When this is a general Firewire fault intrinsic to any Firewire bus version I believe that it also affects Vista machines too, right? Often it’s hard to implement device access permissions even though those are deemed easy. In Vista and the new Server you have one set of administrative templates. For Windows XP you don’t even have a factory made template so you have either create your own administrative template to stop device drivers or you live with that well-known KB allowing to import the scant ADM file targeting to disable access for USB/CD/Floppy. No-no…There is no doubt in my mind thaqt I was absolutely right that I insisted on purchasing Desktop Authority. The thing that I love in Desktop Authority is the extensive reporting. Its far beyond my home-made reporting scripts that I used to create myself in my ‘former administrative life’. Talking about USB security, I really like the report that collects the information for who was logged in when and which USB device he or she tried to plug in to which computer. That’s more than that log parsing that I did before. I think when you deal with Active Directory environments or any other complex environments you have to take control on the situation for every computer and every user registered within the directory services you can’t manage the whole thing with a per-machine handling. I am glad that I am not alone here and there are companies that make tools like Desktop Authority allowing me as administrator perform a complicated real-time control with SQL reporting without needing to rack my brains on how to solve the problem for each particular user. Why do I need to learn commands for devcon play with device classes, edit ACL for INF files when I can just configure it easier then it takes me configure password security policy in GPMC? So the adage ‘The more security you have the more work there will be’ doesn’t apply here. The thing is ‘ease of use’. Why do I care about complexity of rules when it’s easy for me to lockdown device access?
You guys here are security-pros and would really love to hear from you. What’s your practice in implementing device security in your Windows networks?

Martin Wiener March 31, 2008 2:35 AM

For some reason – keyboard lockdown I wonder – the Name/Address fields were cleaned out in the upper post. So just to get others less confused in case they’d decide to continue this conversation.
Thanks guys for this great talk!

amongymouse May 19, 2011 5:56 AM

some years later …

i stumble across this thread, and many like it, intrigued and somewhat panicked … until finally I read enough of the distorted and poorly mastered ‘information’ put about parrot-fashion … shame on you bruce, for blogging without good understanding (or good explanation, if you did understand).

the firewire bus allows arbitrary dma writes to be allowed … but it also allows them to be disallowed … thus this issue was a driver bug and implementation bug, and education deficite … but seems to have been widely misunderstood and perhaps lead in large part to the dwindling of firewire …

in fact this feature itself is very useful if understood … mac systems allow ‘slave’ mode called ‘target’ mode i guess, via the firewire bus … and it could be a good debug port for system developers …

the driver can mask off which addresses are valid, or disable the ‘physical dma’ protocol completely … allowing complete hardware data transfers safely, and those which deviate are shunted to the driver for software handling …

i wonder what machinations or politics lead to this widespread panic and parroting of rubbish-talk by people who should have been competent to read the spec? and broken implementations on every platform? how interesting … now we see USB3 and eSATA taking the field which firewire really had the technology to master … 5 years … a decade? ago …

glue up your firewire ports, my arse. full disk encryption? no more or less useful because of 1394 ohci … what a load of bollocks. are you embarrassed? had me going! i thought for a while i had the holy grail: a way to debug memory as BIOS loads the OS without needing to shell out $$$ or make my own hardware … alas, it was all FUD.

So … why is it … among so much ‘security’ discussion, there is so little real information (and even fewer consumer-market tools) on how to actually see what is in these little black boxes which we feed all our intellectual creations to, nowadays?

amongymouse May 19, 2011 6:06 AM

oh .. i guess the mac target mode, facilitated because apple firmware loads a ieee1394 driver, may allow the bootloader debugging …

but on other hardware, there is no bios initialisation of the firewire bus …

my curiosity over that was not to understand the OS but to try to audit the BIOS … assuming that even a hacked BIOS would pobably not be sophisticated enough to provide a phony firewire target mode that conceals its own memory-resident code, and sends back fake answers … at the very least, if it did, it should be so much slower that it would be obvious something was awry …

but anyway, the hardware i want to audit is not (all?) apple … funny how little curiosity people have about certain things … while paranoia sends them here-and-there trying to secure data on a device the nature of which they have not yet ascertained … are they led, misdirected, or just genuinely a case of mass stupidity? i see lots of ‘security experts’ leading them into panic over so many ‘problems’ none of which matter one iota if the fundamental problem of ‘what the f*ck is this hardware’ has not yet been answered. is the hardware what it says it is? if not, there is no point using PKI, symmetric full disk encryption, backups, what-have-you … at least unless you also validate the outcomes of those technologies on a vast range of randomly selected destination devices for every message you send/store … because you won’t know for sure if what you have secured is authentic, and properly represented.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.