Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharing project files #3

Open
ItzSwirlz opened this issue Apr 6, 2024 · 3 comments
Open

Sharing project files #3

ItzSwirlz opened this issue Apr 6, 2024 · 3 comments

Comments

@ItzSwirlz
Copy link

Is it possible there could be a shared Ghidra/other RE tools project file(s) in the repo? This way as new information is found and more things are labeled, they can be labeled in other tools that make it easier to assess things.

@smx-smx
Copy link
Owner

smx-smx commented Apr 6, 2024

I'm more in favour of making something that can be imported back into Ghidra/Ida, rather than putting the full project files on the repository (unless there's a good reason to do that).

For labelling symbols, we can make a Ghidra/Ida script that renames the obfuscated names by using xzre.lds as knowledge.
For types, we can make a version of xzre.h that can be imported (in case it already isn't, due to external headers).

Do you think this could suffice?

An alternative could be to have some sort of human readable form of the project (like Ghidra XML export) to ease versioning, but at that point i'd rather go with the source+scripts route.
The benefit of source+scripts is that modifications to the source code reflect back into the project, without having to maintain separate code and project files that need to be manually synced.

@ItzSwirlz
Copy link
Author

Yeah, I think that'd be cool. Something that could at least be imported back into those tools would actually be better than the project files. Not sure what I was thinking with that. I think it's possible to parse a C header into Ghidra, but I don't know how that works. I've never tried it myself

@smx-smx
Copy link
Owner

smx-smx commented Apr 11, 2024

656c217 adds a "slim header" that will be written to xzre.h in the build directory.
It doesn't have external dependencies, so it should be loadable.

f84ef2c adds a CSV output in the form "name,section".
However, it doesn't handle sections that have multiple entries, and in any case misses some kind of script to load it (if there is an existing format that could be used without writing a loader, let me know).

An option that crossed my mind was to replace it with something that pulls the names from the compiled xzre binary, since each renamed symbol will appear with 2 names per location, like this:

# readelf -sW xzre| grep 000000000000a180
    56: 000000000000a180   240 FUNC    LOCAL  HIDDEN    24 .Llzma2_encoder_init.1
   293: 000000000000a180     0 NOTYPE  GLOBAL DEFAULT   24 find_function

However, this wouldn't work for the few symbols that lack a name.

An alternative is to load the resulting xzre binary in Ghidra in place of the object file or the liblzma shared library.
This however makes it more tedious to cross reference things between the mock binary and the real binary.

In other words, it needs to be worked on further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants