How can I share a ghidra project without the program binaries?

[aldelaro5]

I am reverse engineering a commercial GBA game and the way these works is everything is in the rom file for the game to function. This means that I have to use a custom loader to load the entire thing in ghidra, this is all fine, I got a setup that works p well.

However, I want to be able to share this and the problem is I can't really do this because if I share a ghidra archive, I implicitly share the whole rom which is piracy.

I was wondering if there is a way for me to export a project WITHOUT sharing the binaries. In other words, is there a way to export the project that contains JUST my own markups, type definitions etc... and have someone only being able to load it with the correct binaries?

If not, what ways do I have to at least export part of it?

[dragonmacher]

Although lossy, you could try exporting using another format, such as XML. Clients would then import via XML.

[aldelaro5]

Although lossy, you could try exporting using another format, such as XML. Clients would then import via XML.

What kinds of information I am expected to loose by doing this?

[dragonmacher]

I do not recall. It should get most of the important things. You will have to try it to see if anything you need is not covered.

[astrelsky]

Although lossy, you could try exporting using another format, such as XML. Clients would then import via XML.

What kinds of information I am expected to loose by doing this?

Iirc you can explicitly select what and what not to serialize when exporting.

[aldelaro5]

Although lossy, you could try exporting using another format, such as XML. Clients would then import via XML.

What kinds of information I am expected to loose by doing this?

Iirc you can explicitly select what and what not to serialize when exporting.

I tried this and it appears all I need to do is to uncheck "memory content" and now I have all markups, but no memory to back it yay!

...except now I do not know how I can put the memory back. Everything shows up as ??, but if I have the binary file with the memory content that it should be, how do I tell ghidra to map it to this memory region? The block already exists, but it just has no content.

[aldelaro5]

Nvm I figured it out so to mark the whole thing as answer in case someone wants to know:

1. In the source program, right click, export and select XML. In Options, select everything BUT "Memory Content", this will export everything except the actual memory such that it won't be recoverable after this.
2. You can freely share this XML file now.
3. The person receiving it has to first open the ACTUAL binary like they would normally to make use of the XML (they can't import it on its own because it will have the markup, but no content to back it).
4. Once imported DO NOT ANALYSE YET (since the XML is already from an analysed state) and do File -> Add to program then select the xml file. Leave everything default (it should detect XML input format) and click ok.
5. You now have a program with the content AND the markup of the original without actually sharing the content.

As said though, this is lossy: it was unable to for example recover some instruction flow override I did, but MOST of the information is there (data types, functions, symbols, XREFS, etc...).

[ghidra1]

If intended for viewing only, you could also export listing details using the HTML or Ascii Program Export based upon a selection which will limit amount of output.

[GrasonHumphrey]

I know this is super late to the party, but I just developed a tool to do this 100% lossless with a "cleaned" .gzf that's scrubbed/encoded with the ROM it decompiles. I was tired of how bad the lossy XML import/export was for a game I'm decompiling. Tool and instructions here:

https://github.com/GrasonHumphrey/GhidraZipCleaner

[gynt]

Hi Andrew, that's correct (and a good reminder for me to be more precise in my language), the .gzf with the decompile can only be retrieved by applying the original ROM to it, and the "clean" .cgzf contains no ROM data. I'm also not a lawyer, but I believe this should avoid potential copyright issues.

I read through the source code but I don't see where you remove the ROM from the gzf file. Does the cgzf file contain the ROM data but then xor-ed?

[GrasonHumphrey]

Hi Gynt, to be more specific, the original gzf contains the ROM data (as well as the other Ghidra comments, labels, functions, etc), which is then XOR-ed with the ROM binary (looping as many times as necessary to XOR the entire gzf) to create the cgzf ("clean" file). The cgzf can then be XOR-ed with the ROM binary again to retrieve the original gzf.

This is admittedly not as elegant of a solution as I could hope for, since the gzf is compressed and so the ROM data cannot be precisely "removed". However, it is certain that no ROM data is accessible in the cgzf unless you have access to the original ROM to perform the decoding with, making it mathematically equivalent to removing the data. It's analogous to locking a key in a box, with the same key being needed to open the box's lock. You already need a copy of the key to access the key that's locked in the box.

[gynt]

The project hinges on the encryption of the ROM. Without unbreakable encryption, the copyright holder could sue. Unfortunately, repeated key XOR-ing isn't very secure. The size of the ROM, i.e. the key, can be legally obtained. Given that a gzf file contains a zip file header (PK) at offset 64, there is known plaintext an algorithm could look for. To be honest, no one will likely try to even break it, especially if the ROM is large, but technically speaking, the techniques used are known to be insecure, which might be enough legal basis to sue.

I would suggest the following, which is slower obviously:

# encrypt
keyinfo = sha512(unguessable random salt + rom)
iv = keyinfo[:16]
key = keyinfo[16:]
output = salt + aes(iv, key, gzf)

#decrypt
salt = input[:16]
keyinfo = sha512(salt + rom)
iv = keyinfo[:16]
key = keyinfo[16:]
output = aes(iv, key, input[16:])

[GrasonHumphrey]

That's a good point I hadn't considered, and a great solution to the issue. I'm working on implementing that and will push an update when it's ready, hopefully early next week.

[GrasonHumphrey]

Big v2.0 update is up with that issue fixed using a solution similar to what gynt proposed. Thanks, gynt!