[HN Gopher] Ghidra Analyzer for UEFI Firmware
___________________________________________________________________
Ghidra Analyzer for UEFI Firmware
Author : adulau
Score : 111 points
Date : 2021-04-15 12:35 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| phendrenad2 wrote:
| Has anyone had any luck debugging via USB 3 on modern Intel CPUs?
| __init wrote:
| Oh boy. Yes, I spent nearly a year trying to work with the
| Direct Connect Interface (DCI), Intel's implementation of this.
| It's a long, complicated, difficult, and frustrating process.
|
| The short version is that, unless you have a corporate contract
| with Intel, there is so much randomness involved that the time
| and effort necessary to get it working are probably not worth
| it.
|
| The main challenge is finding a compatible motherboard. There
| are three main factors that need to align for a given board to
| work:
|
| 1. The CPU XDP (Extended Debug Probe, includes JTAG) lines need
| to be routed to the chipset. Because you're actually talking to
| the chipset via DCI (it's the one that manages the USB ports),
| if they aren't, you'll only be able to access the chipset in
| your debugging session (i.e. you'll have no access to the
| typical debugging stuff that you're probably after), which,
| without Intel's keys to unlock Yellow and Red mode, isn't super
| interesting (though I would like to look into it more . . .).
| It's extremely difficult to guarantee a given board has these
| routed before getting your hands on it; I wasted some money on
| a few that didn't. Your best bet is if you can find a schematic
| buried somewhere on the internet, although even then, this is a
| part of the board that's likely to change between revisions
| without notice.
|
| 2. You'll want the BIOS to "support" enabling DCI -- In quote
| marks because I've never encountered one that will just let you
| do it through the GUI. Instead, most of the time you'll wind up
| modifying a non-volatile UEFI configuration bank for something
| called Intermediate Forms Representation (IFR), which is a
| format that Intel's Firmware Support Package (FSP) uses to
| store the BIOS configuration options. (Most BIOS GUIs are just
| skins on top of this.) There are a few options you need to flip
| in here, so you'll need to use an IFR extractor on your
| particular BIOS to recover the offsets and such for the
| appropriate options; once you have them, you'll use something
| like RU.efi to actually twiddle the bits. It's worth noting
| that not every BIOS uses this approach. I can't recall who it
| was, but there was at least one vendor whose BIOS didn't
| contain any IFR. In that case, you'll likely need to patch the
| BIOS directly -- an enormously complicated task, worthy of
| another post. I developed a successful patch once, which would
| have worked were it not for the third factor . . .
|
| 3. The chipset must be configured to serve DCI over a
| particular USB port. This is the factor I know the least about.
| There were a few boards I found that were _very_ finicky about
| which ports they would serve. Obviously, at the bare minimum,
| you have to connect to a port served _directly_ by the chipset,
| but it seems that there are factors even beyond that. Perhaps
| they are configurable in firmware, or maybe they are programmed
| in eFuses in the chipset -- I'm not sure. In any case, be sure
| to try all of the available ports, including USB-C. There was
| one board where I got everything else working, but none of the
| ports let me in -- absolutely infuriating.
|
| All in all, I evaluated several dozen boards (looking for
| schematics, downloading and reversing BIOSes) and purchased
| eight; of those, two worked. The first was a Dell Precision
| 5520, and the second was a Asus TUF Z370 Plus Gaming. I
| couldn't get a 8th Gen Intel NUC working (it was behaving as
| though the CPU wasn't connected, which is odd considering the
| chipset and CPU are integrated onto one die).
|
| Once you have a board, you'll need Intel System Debugger. (This
| was previously packaged with Intel's free version of System
| Studio, but I've heard rumblings that, as of just recently,
| this is no longer the case.) This part is pretty straight
| forward -- the documentation should have you covered.
|
| This was definitely one of my favorite projects, but if you're
| looking for a simple debugging solution, this ain't it.
| azalemeth wrote:
| This is an excellent, detailed reply. I've never had much
| experience debugging _anything_ related to hardware beyond
| (linux) kernel drivers and JTAG on (far slower) devices.
|
| As an outsider who is interested, what's the best source to
| read about Intel's Yellow & Red modes, and its toolchain
| (which I is analogous to AMD's)? I've always felt that this
| is the level in which "the way things work" goes from being
| well-documented and google-able to "leet hax0rz", accessible
| only behind corporate NDAs - very complex, very hard to read
| about, and rather hidden. Of course, this could be just my
| ignorance talking - but I want to learn! IME seems complex
| and hidden enough!
| unnouinceput wrote:
| Ghidra and IDA Pro are definitely good RE tools, but hot damn I
| miss SoftIce sooo much. Best tool ever.
| xvilka wrote:
| Have you tried Cutter[1]? It's a GUI for the underlying
| Rizin[2][3] framework.
|
| [1] https://cutter.re/
|
| [2] https://rizin.re/
|
| [3] https://github.com/rizinorg/rizin/
| rurban wrote:
| cutter has better arm support than ghidra. But getting a
| version they works on macOS Big Sur is tricky
| c-c-c-c-c wrote:
| Any real reason to use rizin instead of radare2? It just
| seems to be name fork because of drama.
| xvilka wrote:
| It's all described in the FAQ[1]. Moreover, there are a lot
| of different technical decisions to improve stability,
| packaging experience, user experience, etc. One of the
| biggest such points - new Projects[2].
|
| [1] https://rizin.re/posts/faq/
|
| [2] https://rizin.re/posts/introducing-projects/
| ynezz wrote:
| SoftICE is actually something different, it's like kernel
| mode debugger, so you could essentially freeze the running
| kernel at any time and poke into the system internals.
| xvilka wrote:
| Yes, I know. There was a continuation of it called Syser[1]
| but it is dead long ago too. Even the site of the company
| is not available anymore, it seems.
|
| [1] https://syser-debugger.soft32.com/
| mike_d wrote:
| Check out https://binary.ninja/ too
| unnouinceput wrote:
| I just did, since is first time I've heard of it. And to me
| it seems Ghidra is more advanced. Maybe in the future will
| surpass it.
| nekitamo wrote:
| Yeah I feel that there are are still good disassemblers
| available for RE, but debuggers have really fallen behind.
| Especially on non x86 architectures, the best you're going to
| find is GDB/LLDB, which is a far cry from Softice and Ollydbg.
| ynezz wrote:
| You can't beat gdb+opencd.
| engineer_22 wrote:
| Can someone tell me what this is and why I would use it?
| zamadatix wrote:
| The repo assumes you know "Ghidra" is a reverse engineering
| tool https://en.wikipedia.org/wiki/Ghidra. You'd use this as
| part of reverse engineering various boot fimware as Coreboot
| has been known to do for example.
| engineer_22 wrote:
| Thank you
| the_only_law wrote:
| The readme does a better job than I could (it's been a while
| since I read up on UEFI stuff in detail) but if you were
| hacking, reversing, etc. UEFI firmware it looks like it
| provides some helper functions to identify different UEFI
| functions : endpoints / structures from a decompiled image in
| Ghidra. Which is a disassembler / decompiler application.
___________________________________________________________________
(page generated 2021-04-15 23:01 UTC)