Dependency Graph

[RafaelRMachado]

First of all this project is amazing!

Would it be possible to add a dependency graph option ?
I think on something to let easier to understand what modules are dependent to each other.

[NikolajSchlej]

Thanks.

There is a problem with dependency graph, and it's a big one: modules are very rarely dependent on modules (the only cases are BEFORE and AFTER opcodes). Most of modules are dependent on PPIs/protocols, but there is no easy way to determine what module publish/unpublish/republish a given protocol. There are some easy heuristics like "if the module has protocol GUID inside, but it's not in it's DEPEX section, it's probably publishing it", there are some more complex heuristics, there are disassembler/decompiler engines that can be used to locate calls of RegisterProtocol/NotifyProtocol and similar functions - possibilities are many, but all of them are very hard to automate well enough.
One of the best options is symbolic execution, or something like @jethrogb did here, but it also very hard to do without human assistance. And then there are events and notifications, and callbacks, and interrupts, and SMI handlers, and...

I don't say the feature isn't worth it, but there are many easier things to do right now, like NVRAM parsing/validation and new builder code, so I don't think I can get into DepGraph problem any time soon.

[jethrogb]

"if the module has protocol GUID inside, but it's not in it's DEPEX section, it's probably publishing it"

In my experience, even this is not always the case in practice. For example the ThinkPad modules I've worked with often contain many GUIDs inside which are never referenced by the code.

[NikolajSchlej]

Yep, seen such cases too.
DepGraph based on firmware image only will be a tough nut with symbolic exec/virtualization, and even tougher without it, that's why the only thing done in this general direction was DEPEX parsing.