Last week, I drafted a wishlist and posted it here. Lets do an update:
- Minolta Maxxum 50mm F/1.7 obj.
In the mail, slowly getting here.
- Opensource, Microsoft Windows based, AoE initiator
Tracy Reed (of XenAoE.org) pointed me toward http://winaoe.org which seem to be a valid Microsoft Windows based initiatior licensed under the GPLv3. I will be testing it in my lab this week-end.
- Another SAN deployement project
I never discuss my contractual engagment, but… ;-)
Because most people does not care about my camera / lens, i’ll be giving you a melting-pot post I’ve been working on:
1)
This might be one of the worst bug affecting Microsoft Windows for years. I’d expect to see this news in a couple of week, on april 1th.
The description of the bug goes as follow:
A bug has been discovered in the way that Windows Home Server manages file transfer and balancing across multiple hard drives. In certain cases, depending on application use patterns, timing, and the workload that is placed on the Windows Home Server-based computer, certain files may become corrupted.
source: Microsoft Knowledge base KB946676.
And the fix:
Until a software fix for Windows Home Server is available, users may choose to act to help limit the possibility of being affected by this issue. As a precautionary measure, users should use Windows Explorer or a command-line tool to copy files to and from the Windows Home Server-based computer. Do not use applications to directly edit or change files that are stored on the Windows Home Server-based computer.
Emphasis is mine,
source: Microsoft Knowledge base KB946676.
Following the link, you will see a list of application you should NOT use on this operating system. Notable one include Microsoft Excel, Mozilla Thunderbird, Adobe Lightroom and Adobe Photoshop….
2)
Speaking of bad bugs, here is another one concerning device encryption.
A paper from the Center for Information technology policies, Princeton university describe the risk of cold boot attacks against data remanence in RAM. The paper is kinda technical and doesn’t disclose the exact tools used to retreive informations. To do a very blunt summary : Your ram isn’t as volatile as your might think. This is a disastrous news for all device encryption scheme, and kind of a very good one for all forensic analyst.
Weasley Mcgrew, from McGrew Security, has made available a tool that can be pushed on a removable media and be used to rip a copy of the ram fingerprint. I wouldn’t bid anything on the fingerprint size of the tool, but it does seem kinda small.
I’ve tried "msramdmp" on my Asus-EEE from the SD-card reader. Took me about 10 minutes to create the ripping device (make, sysconfig and libtool were not installed), but it simply work. Does take a long time to rip RAM though, but again, I was writting to SD Card interfaced through USB… around 1.4MB/s. But time isn’t an issue in labs and off-line preparation can be quite as long as you want if you get some R-134A (to cool your memory, only needed if you want to leave the computer closed while you prepare).
Leaving you on a quote from the Princton paper FAQ, have nice nightmare:
We have demonstrated practical attacks against several popular disk encryption systems: BitLocker (a feature of Windows Vista), FileVault (a feature of Mac OS X), dm-crypt (a feature of Linux), and TrueCrypt (a third-party application for Windows, Linux, and Mac OS X). Since these problems result from common design limitations of these systems rather than specific bugs, most similar disk encryption applications, including many running on servers, are probably also vulnerable.