5

Ghidra uses .cspec files like x86win.cspec to define compiler related information, which are imported in the .ldef files like x86.ldef that define a processor language.

How can I add a new CompilerSpec via a .cspec file to Ghidra without editing the existing .ldef file which is inherently part of the Ghidra core, but also without adding a new processor (with a new .ldef file)? This should also work with analyzeHeadless, so no just adding it in the GUI.

This will probably end up requiring an extension which isn't an issue, I just don't know where to either put the file so it gets automatically loaded, or which API functions to call as part of the extension initialization to add the new CompilerSpec. The classes that implement the CompilerSpec interface have public constructors, that take the .cspec file as a parameter, but this doesn't look like it will be automatically added then after just creating an instance of it.

Florian Magin
  • 1,444
  • 6
  • 22

2 Answers2

2

It's not possible currently (Ghidra 9.2.2) to do what you're asking. Each processor is identified by a 4-tuple of architecture, endianness, size, and variant. You can only specify an ID once. So unfortunately, you can't just add another .ldefs file somewhere and "open up" the language (internal name for a processor) to add new compiler spec entries and .cspec files. This is a limitation of the way Processors are loaded by the SleighLanguageProvider.

Aside: I'm assuming what you want to do is, for instance, add a new compiler spec to x86:LE:32:default so that it shows up in the list along with clang, gcc and Visual Studio.

The best you can do right now is add an Extension with a new processor that has the same architecture, endianness and size, but a different variant name. This might have serious ramifications for future official Processor upgrades though; you'd probably have to watch the version numbers carefully and duplicate the .trans files if any.

You might want to consider making your changes directly in the Processor directory, and sharing your additions with the official team.

Mike J. Bell
  • 21
  • 2
  • In my case sharing the cspec file isn't as simple because it consists mainly of opinionated choices for callfixups that clean up ObjectiveC code. Specifically by defining callfixups for various runtime functions normally used for reference counting with NOP. Definitely not suitable for general use :/ – Florian Magin Mar 29 '21 at 08:23
1

This feature will be part of Ghidra 10 according to the preliminary release notes: https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Configurations/Public_Release/src/global/docs/WhatsNew.html#L124-L130

Extensions can be added from the Specification Extensions tab under the Options dialog for the Program.

The beta is already available for download at https://ghidra-sre.org/

Adding new Compiler Spec

The full process is, starting from a Codebrowser window with some binary named ls:

Edit - Options for 'ls' then this window should open, where you can click on Specification Extensions on the left:

enter image description here

click Import... and select the file defining the extension. If you want to e.g. define a callfixup that tells the decompiler to treat some function as a NOP if called, you can write a file like this:

<callfixup name="objc_retain">
    <target name="_objc_retain"/>
    <target name="_objc_retainAutorelease"/>
    <pcode>
      <body><![CDATA[
      x0 = x0;
     ]]></body>
    </pcode>
  </callfixup>

It seems like you can only define one extension per file, and can't import multiple files at once. Though at least in my case the actual replacement is often the same, just for different functions, so you can just add multiple targets.

Florian Magin
  • 1,444
  • 6
  • 22