Reverse engineering the Intel FSP: A Primer

The flowchart view is extremely useful, and from my experience of having taught an Asm class before, in which students were required to do both compilation and decompilation, creating such a graphical representation of the program flow really helps to clarify when going from C to Asm and vice-versa. Lacking software to do it automatically, printing out the code and drawing lines works reasonably well.

That "challenge" function should puzzle anyone who knows even the slightest bit of Asm --- not because of its purpose, but because of how it does it. Subtracting one number and then adding another, is entirely equivalent to adding their sum; so that could be simplified to:

    call $+5
    pop eax
    sub eax, 5
    sub eax, [eax-15]
    ret

http://www.intel.com/FSP

Apparently it's their (closed) cpu initialization code that you are free to take and reuse if you're creating a new device using Intel cpus.

https://ghostbin.com/paste/jpeh5

Not as readable or semantically meaningful as the author's manually decompiled version, but pretty decent.

So if you think x86 assembly sounds really arcane, you should know that you're not strictly required to learn it to start experimenting with reverse engineering: you can start with a decompiler, which is all you need in most cases, and gradually learn how its output corresponds to assembly (which is still necessary to deal with in harder cases). Hex-Rays is the only decompiler I know that doesn't suck, and you are required to fork out high sums to get a legitimate copy of it… but it's easy enough to find a non-legitimate copy to start out with.

Personally, even though I have a fair amount of experience with reverse engineering at the assembly level, I find that using the decompiler lets me understand the "big picture" of a function's purpose much more quickly. Maybe I just need even more experience, and I'd be able to work just as fast from assembly… but I don't think so. I'd rather write my own decompiler to handle the stuff that Hex-Rays doesn't.

This should be 0xF bytes before the current function, shouldn't it? I liked it.