Advanced Format HDD (HDD with 4KB Sectors)

Last week I migrated one of my machine to RAID 1 and for the first time using HDD supporting Advanced Format (4KB sectors). I wonder new BIOS/UEFIs implementation support these HDDs natively so that they can be used not in 512Byte sector emulation. Particularly, exposing the HDD capability to the operating system.

Well, of course, the support is very probably via new ATA Command in the ATA command set spec. So, BIOS/UEFI code emits ATA Command to the drive to get info on Advanced Format support and so on. I'm still digging into UEFI spec whether there are specific data structure exposed for that support.

Anyway, GNU parted have support to optimize sector aligning for Advanced Format HDDs. I have a write up on that at: https://sites.google.com/site/pinczakko/slackware-14-software-raid-installation-on-hdd-with-advanced-format-4kb-sectors.

Above and Below vs Greater and Less in x86/x64 Architecture

There are two different "families" of integer comparison in x86 assembly language. The first one revolves around the "above" and "below" moniker, and the other one revolves around the "greater" and "less" moniker. It's not very clear what the difference between both "families" of instruction until you take into account signed and unsigned integer comparison. The "above" and "below" family of integer comparison instructions deal with unsigned integer comparison. You could verify this by looking at Intel x86/x64 manual. In the manual, you would find that the "above" and "below" instruction family only check for carry flag (CF) but not the sign flag. Let's see a copy of the instructions explanation from Intel manual:

JA rel8  -- Jump short if above (CF=0 and ZF=0).
JAE rel8 -- Jump short if above or equal(CF=0).
JB rel8 -- Jump short if below (CF=1).
JBE rel8 -- Jump short if below or equal(CF=1 or ZF=1).

As you can see, there's no check for sign flag in the instructions above. Therefore, they are all unsigned comparison. Now, let's have a look to the other family, the "greater" and "less". Again, let's see a copy of the instructions explanation from Intel x86/x64 manual:

JG rel8 -- Jump short if greater (ZF=0 and SF=OF).
JGE rel8 -- Jump short if greater or equal (SF=OF).
JL rel8 -- Jump short if less (SF‚ OF).
JLE rel8 A -- Jump short if less or equal (ZF=1 or SF‚ OF).

As you can see, all of the "greater" and "less" comparison checks against the sign flag (SF). Therefore, they're all signed integer comparison. The difference between the two "families" of instruction could be easily overlooked by those new to x86/x64 assembly language. I hope this post clarify that.

Thoughts on Having Access to Official BIOS Source Code

I have access to official AMI BIOS Core8 source code for more than a year now,
due to one of my work. I think it's good to share the ups and downs of having access to such source code. 

It's nice to have BIOS source code at your hand because you can do a lot of things.
However, having access to the source code doesn't equal understanding the code any better. 
It's quite a steep learning curve to understand how to use the development tools and 
also some code requires you to understand various hardware protocol to have a sense on it. 


Of course, having reversed some BIOS binaries helped me. But, it also produces unwanted effects.
Sometimes, I tend to use "binary surgical" approach instead of trying to use the existing development tools, 
which in the end produces ugly kludge. It takes sometime for me to get used to the development tools.
Overall, though I can say that I learned a lot from the source code.

The Mebromi BIOS Rootkit Hype: An adapted version of Kris Kaspesky ISA ROM shell coders?

Is the Mebromi BIOS Rootkit hype is based on an adapted version of Kris Kaspesky ISA ROM shell coders?


Well, this is probably one of the most hillarious thing that ever happened if it's true. I need to investigate further. I cannot say for sure until further evidence confirm my suspicion. From quick glimpse, it looks like infecting the IVT of Windows XP (probably I'm wrong) . So, stay tuned!

Tweeting New Articles

I'm starting to tweet link to articles I'm writing. I've been too busy lately. Probably that should be enough for sometime. You could follow the update over at twitter @Pinczakko. Of course, this blog will still be more in-depth.

Implanting malicious hardware

After reading this and this over at Bunnie's blog, I came to think that how easy someone can "implant" malicious hardware anywhere in the supply chain before the hardware reaches it's destination. Ball Grid Array chips are complex beast to work with physically. But, with the BGA reballing tool, even a complex chip like that could be replaced with ease (quote from Bunnie's blog):

Before seeing this, I was under the impression that reballing was an involved process, but with this jig the operator could strip and reball a chip in under a few minutes, which translates to a labor cost of a couple dozen cents

This is insane. In PC motherboard, the chipset is mostly in BGA packaging. Flash ROM chips these days are back in the old "DIP" (Dual In-line Package), so it's quite easy to work with. But, to think that even BGA chips could be altered with ease is just mind boggling.

Malicious Code Execution in PCI Expansion ROM Article

The "Malicious Code Execution in PCI Expansion ROM" article is up. You could read it over at: http://resources.infosecinstitute.com/pci-expansion-rom/.

It's a mix of old and new things; from what we have known from the old PCI expansion ROM as mentioned in PCI specification and new "feature" added by the PCI firmware spec.

IDA Pro Support for EFI Byte Code (EBC)

IDA Pro already support disassembling EFI Byte Code (EBC) binary, as you can see at: http://www.hexblog.com/?p=116. This is a boon for those working with UEFI :-).
Anyway, EBC have been here for a while. So, that's expected.

Anyone have used it on serious reversing project?

Legacy BIOS Interrupt 13h Drive Numbering

I've been searching for drive numbering in legacy BIOS interrupt 13h for a couple of days when I finally stumbled on this Microsoft documentation: http://support.microsoft.com/kb/62571

This is the relevant excerpt:

The BIOS Interrupt 13H uses a zero-based number for floppy disk drives ("A"= 0, "B"= 1, and so on), and a zero-based number with the high bit (bit 7) set for hard disks ("C"= 80H, "D"= 81H, and so on).

Well, this info might have some use afterall ;-)

BIOS Disassembly Ninjutsu Uncovered (1st Edition) [Unedited] PDF released

Hi guys,

I have released the BIOS Disassembly Ninjutsu Uncovered (1st Edition) [Unedited] PDF in GitHub. You can clone it from this URL: https://github.com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered.git or download the zip https://github.com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered/archive/master.zip for free. Well, the (copy) rights have expired and I guess lot's of people look forward to it. I don't have enough bandwidth to host it. If somebody wants to host it, please do so but please notify me via email.

Anyway, mind you that this is the unedited version, not the shipping version. You might find it a little rough here and there, but the manuscript is complete. If you remember, the English version of the book is 450 pages, but the Russian version is more than 600 pages. I haven't had time to check what was missing in the English edition compared to the Russian edition.

There are two alternative places to download the book at present (but be advised to try downloading from GitHub first in order not to burden the other two sites):

• The Rebels Haven forum: http://www.lejabeach.com/sisubb/BIOS_Disassembly_Ninjutsu_Uncovered.pdf. Thanks goes to Polygon who have provided the bandwidth to host the book
• Teddy Rogers' tuts4you: http://tuts4you.com/download.php?view.3296. Thanks goes to Teddy Rogers who have provided the bandwidth to host the book

Happy reading :-)

PS: I have created a new group over at linkedin, i.e. "BIOS/UEFI Vulnerability and Reverse Engineering" if you want to discuss a thing or two.


BIOS Disassembly Ninjutsu Uncovered Errata:
-------------------------------------------------------

1. The address aliasing mentioned in Chapter 4 section 4.1.1 page 4 (the paging messed-up in the PDF) should cover both E-segment and F-Segment (E_0000h-F_FFFFh), not just the last 64-KB segment. Somebody used a sort of CPU logic analyzer to confirm this fact.
2. Chapter 9 section 9.2: The Flash_n_burn utility mentioned there is now named flashrom and become a quite independent part of the Coreboot (previously LinuxBIOS) project. See: http://flashrom.org/Flashrom

Anyway, if you found another errata please post it below. Thanks.

Passing Parameter(s) to BIOS/UEFI SMI Handlers

There are two ways to pass parameter(s) to SMI handler(s) in BIOS/UEFI:

1. Via the Global Non-Volatile Storage (GNVS). This is a region in the non-volatile storage area. I'm not 100% sure about the physical implementation of the GNVS, but it's part of RAM reserved for Non-Volatile Storage by ACPI BIOS subsystem on the motherboard. [Thanks to Kun-Yi Chen for pointing out].
2. Via General Puupose Registers (GPRs). In this technique physical address pointer is passed via GPR to the SMI handler code. I've been thinking about giving some IDA Pro disassembly for this one. Maybe later. 

There you have it. Next time you encounter a suspicous code with one of the attributes above, it might just be one of them :-).

PCI Expansion ROM Execution Environment Peculiarity

This post is related to the x86 Segment Descriptor Cache stuff I posted a while ago. In my previous book, this fact is not included. So, what's the weird thing about the PCI Expansion ROM execution environment? Well, it runs in "big-real mode"/unreal mode. It may not sound obvious but this is the excerpt from a related specification:

"When control is passed to an option ROM from a BIOS that supports PMM, the processor will be in big real mode, and Gate A20 will be disabled (segment wrap turned off). This allows access to extended memory blocks using real mode addressing."

 To put things in perspective, I plan to just combine it with the upcoming POST Memory Manager article on my website. I haven't had enough time to finish that one.

x86 Segment Descriptor Cache

BIOS-related code "abuse" the x86 segment descriptor cache for its own pusposes. Therefore, it pays to know the details of the x86 segment descriptor cache. Aside from information in section "3.4.3 Segment Registers" of the official Intel Software Developer Manual Volume 3A and 3B, this link: http://www.rcollins.org/ddj/Aug98/Aug98.html is also very useful and gives historical insight into this widely "abused" feature that Intel have to support due to its wide usage back to the i386 era.