Live data from Hacker News

Reverse engineering the Intel FSP: A Primer

puri.sm

1–10 of 16 posts

Re: Reverse engineering the Intel FSP: A Primer

#2
Nice but come on, pages and pages about what is a stack but not even a word about what this "Intel FSP" is supposed to be?

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.

Re: Reverse engineering the Intel FSP: A Primer

#3

Nice but come on, pages and pages about what is a stack but not even a word about what this "Intel FSP" is supposed to be? 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.

Yes that is weird for a technical write up not to mention what FSP stands for. I was expecting it on the first sentence.

Re: Reverse engineering the Intel FSP: A Primer

#4

Nice but come on, pages and pages about what is a stack but not even a word about what this "Intel FSP" is supposed to be? 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.

And it features "Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum". I've been looking for that for years!

Re: Reverse engineering the Intel FSP: A Primer

#6

Nice but come on, pages and pages about what is a stack but not even a word about what this "Intel FSP" is supposed to be? 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.

Yes that is weird for a technical write up not to mention what FSP stands for. I was expecting it on the first sentence.

FSP is a TLA for an API using Intel ISA code implemented on CPU with support for BIOS used in some RTOS systems.

Re: Reverse engineering the Intel FSP: A Primer

#7

Earlier quoted context omitted.

Yes that is weird for a technical write up not to mention what FSP stands for. I was expecting it on the first sentence.

FSP is a TLA for an API using Intel ISA code implemented on CPU with support for BIOS used in some RTOS systems.

Eh. 2/5. Your sentence is quite comprehensible and doesn't answer the question for reasons completely unrelated to acronyms. ("an interface" and vague ideas about what it runs on don't tell you what something is)

Re: Reverse engineering the Intel FSP: A Primer

#8
post #4

Nice but come on, pages and pages about what is a stack but not even a word about what this "Intel FSP" is supposed to be? 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.

And it features "Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum Lorem ipsum". I've been looking for that for years!

And a Broadwr roadmap!

Re: Reverse engineering the Intel FSP: A Primer

#9

Earlier quoted context omitted.

FSP is a TLA for an API using Intel ISA code implemented on CPU with support for BIOS used in some RTOS systems.

Eh. 2/5. Your sentence is quite comprehensible and doesn't answer the question for reasons completely unrelated to acronyms. ("an interface" and vague ideas about what it runs on don't tell you what something is)

Admittedly weak. As other commenters — I have strong distaste for writing that doesn’t define widely unknown acronymns on first use.

Re: Reverse engineering the Intel FSP: A Primer

#10
Just for reference, here is what the Hex-Rays decompiler produces for the function in question:

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.

Post reply on HN