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

Auto detect library #13

Open
riesentoaster opened this issue May 10, 2023 · 2 comments
Open

Auto detect library #13

riesentoaster opened this issue May 10, 2023 · 2 comments

Comments

@riesentoaster
Copy link
Collaborator

riesentoaster commented May 10, 2023

See #11

Should also rework handlers in lists for hook adding.

@floomm floomm mentioned this issue May 11, 2023
2 tasks
@riesentoaster
Copy link
Collaborator Author

After a long look into Ghidra's API I am no longer sure this is actually possible.

(Sorry for the ugly code, for some reason my IDE wouldn't let me loop over the iterator without doing it by hand…)

for (Reference e : p.getReferenceManager().getReferencesFrom(add)) {
	Map<String, List<String>> out = new HashMap<>();
	for (String externalLibraryName : p.getExternalManager().getExternalLibraryNames()) {
		List<String> functionNames = new LinkedList<>();
		out.put(externalLibraryName, functionNames);
		Iterator<ExternalLocation> it = p.getExternalManager().getExternalLocations(externalLibraryName);
		for (; it.hasNext();) {
			ExternalLocation ex = it.next();
			functionNames.add(ex.getLabel());
		}
	}

	System.out.println(out.entrySet().stream().map(
			entry -> entry.getKey() + entry.getValue().stream().collect(Collectors.joining(", ", ": ", "")))
			.collect(Collectors.joining("\n")));
}
<EXTERNAL>: calloc, __cxa_finalize, printf, __libc_start_main, strlen, abort, __gmon_start__, _ITM_deregisterTMCloneTable, _ITM_registerTMCloneTable
libc.so.6: 

This seems to suggest that while Ghidra knows about libc, the references in the functions seem to be tied to <EXTERNAL>. This might be because we are developing a ProgramPlugin, which is to my knowledge tied to a Program, and that wouldn't include external libraries. Looking at how other people solved similar issues (example), they basically look up the path to the external library and load it from a file. This seems not really doable since the machine that Ghidra runs on is different from the one running the executable. The former might not have all the libraries installed that would be necessary.

Specifically, in the mentioned example, the following line does not work on my machine (returns null):

String libPath = currentProgram.getExternalManager().getExternalLibrary(externalLocation.getLibraryName()).getAssociatedProgramPath()

I do not see an other way to bridge the gap between the output of ExternalManager:: getExternalLibraryNames and the rest of the API.

@riesentoaster
Copy link
Collaborator Author

Further evidence that the above is correct. Error message when importing a file into Ghidra:

----- Loading /Users/valentinhuber/Documents/Studium/BA/GhidraMorionExamples/armv7/memcmp -----
Failed to properly markup GNU Hash table at 003001b4: Conflicting data exists at address 003001cc to 003002ab
Setting block .init_array to read-only based upon PT_GNU_RELRO data
Setting block .fini_array to read-only based upon PT_GNU_RELRO data
Setting block .dynamic to read-only based upon PT_GNU_RELRO data
Setting block .got to read-only based upon PT_GNU_RELRO data
Setting block .data to read-only based upon PT_GNU_RELRO data
Linking external programs to memcmp...
  [libc.so.6] -> not found
----- [memcmp] Resolve 9 external symbols -----
Unresolved external symbols which remain: 9

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

No branches or pull requests

1 participant