PhoneFactor video
It’s been a long time since I’ve posted anything, but I promise this is going to be worth it:
http://www.youtube.com/phonefactor
Thanks to Dan Leafblad for doing all the hard work to pull this together. And Shame on Evan Conway for making me wear a conehead hat. It looks… well… just watch the video…
Interesting peek at Win7
I’ve been hearing little anecdotes about Win7 for months now, but Ars has one of the better articles I’ve seen so far. Interesting:
Traut runs a team of about 200 software engineers at Microsoft that is responsible for the core kernel scheduling, memory management, boot sequence, and virtualization technology such as Virtual PC and Virtual Server. The latter technologies are becoming more and more important as servers get more powerful and gain more and more CPU cores, and it was clear from the demonstration that Microsoft is placing significant effort into integrating virtual machine technology into everything that they do.
As I’ve written before, I think a focus on (high-scale) multi-core will be a key to the OS’s success going forward. Anyway, check out the video linked from the article.
No more single-core chips
Intel is phasing out single-core desktop processors. The end of the end of an era!
UPDATE: Ken covered this a while ago regarding a similar decision by AMD.
I guess it depends on what you’re hex editing
Ken and Rich Johnson from MSRC were both extolling the virtues of hiew as a hex editor a few weeks ago. I recently needed to do some hex editing of a pcap file (needed to manually munge some network packets for IM driver testing), and my new laptop didn’t have a hex editor yet, so I decided to go grab hiew and give it a shot.
Once you get over the character-mode interface, it actually has a ton of neat features, including a nice disassembler, and basically everyone I’ve asked in the hex-editing community (?) concurs that it’s the only thing they’d ever use to modify a binary.
So, I loaded up my pcap file and searched around for the bytes to modify. I found the (long) block of hex that I wanted in another capture file and went to copy the bytes. Then I tried to open another file and past them in. Hmm, nope, not supported!
Then I tried re-arranging bytes within the same file. Nope! Not (obviously?) supported, at least without overwriting things.
So, in a bit of a huff, I fired up Visual Studio 2005 and instantly copied and pasted the bytes I needed and achieved a state of happiness in mere seconds.
I’m sure there are a lot of people that will be able to tell me how to get hiew to do this, and I’m sure I could have written a script or something, but… life is to short to learn Yet Another Non-Obvious Editor.
So, I’m sure hiew is great, and if I ever need to hex edit a PE image, I’ll certainly keep it in mind. But for network packets - back to VS!
UPDATE: I am a dumbass. I cannot believe I left the title "your hex editing" instead of "you’re" - the shame! 
Metasploit as the security Mendoza line
If you are in (or near) data security and you haven’t heard of Metasploit, you owe it to yourself to check it out. The RiskAnalys.is blog observes today that Metasploit is the security Mendoza line. I’ll let them explain the analogy for the non-baseball fans in the crowd.
I think I forgot to mention the release of the 8th volume of Uninformed a couple of weeks ago as well. Lots of good stuff there. Some of the same (bright) people are involved in both Metasploit and Uninformed.
The return of err.exe
I’ve been working with Karin Meier-Magruder from the SDK team at Microsoft to get everyone’s favorite tool, err.exe, [re-]added to the PSDK. She’s working on getting it done, but meanwhile, as a special treat for Kernel Mustard readers, I have a newly updated err.exe ready for download. There’s a EULA inside the .zip that governs the tool’s use.
For those that haven’t used it before, the current err.exe indexes 22,851 error codes from 171 sources. Pass it a magic number from somewhere and it’ll make sense out of it!
Enjoy!
Security lessons from MULTICS
Interesting stuff for OS and security-minded people: Thirty Years Later: Lessons from the Multics Security Evaluation. MULTICS was B2-certified and was considered for re-development into an A1 system.
BlueHat
If getting a new product ready for market is time-consuming, it’s 10x worse to try to do a major revision of that product while supporting users! I’ve been down this road many times in the past, but it never fails to impress me as to how much harder it is to make forward progress when you simultaneously have to support users. I wonder how long it would have taken the NT team to deliver 3.1 if they had had users out there, since it took 4 years as it was!
Anyway, I’ve managed to find two days to escape to BlueHat in Redmond, which I’m really looking forward to. I’m a little concerned, though, since I’m here with my Mac, on Wi-Fi, and David Maynor is here…
Opera, anyone?
In a totally off-topic post, I wanted to send congrats to my brother Scott Dispensa, who has been selected to join the New York Metropolitan Opera chorus.
In his honor, I’m currently playing La bohème louder than anyone around me would like.
New Niagra debuts
Sun has announced the latest rev in its Niagra line, the line of highly multi-threaded CPUs that were designed from the ground up with total chip throughput being the most important variable (followed perhaps by power consumption). It’s a really cool design, but at 64 threads per chip, there’s no chance that most current (non-server) software can effectively leverage its power.
There was a discussion on NTDEV some time ago about factoring out fine-grained locks for the sake of design simplicity. I’m a big supporter of that line of thinking, but 64-thread chips may just make that kind of optimization untenable.
Related: Ken just wrote about this issue a couple of weeks ago.
I can’t wait to see what happens in the app world. This topic has been heavily debated around Positive Networks for a couple of years, with some people asserting that most user apps just don’t need any more single-thread perf than they currently get, and others (myself included) that point out that people will find uses for the additional power, 90% of which will come from additional threads/cores/etc, rather than from improvements in straight-line per-thread perf.