Kernel Mustard

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.

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!

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.

A friend is digging around trying to find out when function prologue hooking was invented, and who did it. Does anyone out there know of any old-time uses of function prologue hooking?

I’m NOT talking about:

• Interrupt hooking
• system call hooking
• window hooks
• VxD service hooking
• hot patching
• any “architected” hook

I’m interested only in programs that disassemble a C (or similar) function prologue and replace it with some sort of jump or call or something.

Anyone have any old examples?

UPDATE: One commenter pointed out Detours. Their paper was published in 1999. I was hoping for something before that, as I can’t bring myself to believe that they invented the technique of function prologue hooks that recently.

…or are LookupAccountName and LookupAccountSid named backwards?

Annoying.