Closed alessandromrc closed 1 year ago
Thanks for your suggestion and I'm not opposed to supporting something like this, but your implementation is quite flawed and I don't see much use for it in its current state.
The main point of using signatures is for them to be version indepedent, which your signatures are not. Additionally, these signatures point to the native handler rather than the actual function, and it's pretty much impossible to create a viable signature for a native handler.
To address these concerns you could try to figure out what function is being called by the native handler, and create a signature of it. This would be quite difficult to accomplish though, as it's not always obvious what the underlying function is. You'll also have to keep in mind that some natives are obfuscated to the point where this is not possible, becuase the individual chunks could be too short to make a signature. Finally, you'd also have to make sure to replace bytes that would change between versions with a wildcard (?
).
If you're open to suggestions, I think a tool that can generate a set_name
script for the native handlers would be more useful and a more achievable goal. Althought that wouldn't be something relevant for this nativedb.
Hi @DottieDot I'm surely open to suggestions and the tool to set the name of all the function is actually there already in the repository. Anyway I was thinking about making the script jump into the native function instead of having the handler there with all the "E9" (which are jumps) to the actual function, I think that might solve the issue you pointed at before for most natives.
Those jump instructions will rarely go to the actual function being called. In older game versions the addresses of these functions are actually included, but you have to dump the game during native registration to get access to those.
I doubt having patterns of older game versions would be useful anyway
Anyway the set_name script is actually here: https://github.com/tooling-gta/IDA_NATIVE/blob/main/main.py
I doubt having patterns of older game versions would be useful anyway
When properly made a signature will work on all game versions as long as the function logic doesn't change.
Also I actually have no idea about what you're meaning with "dumping the game during native registration"
After making it "jump" into the function it seems to actually find a function that makes sense to me.
Hi, I've made a JSON file that (should) contains all the patterns of the natives in the game and I think it would be a great addition to the DB. The repository which contains all the patterns is here. The tooling to generate all the patterns is included in a different repository which is linked in the description.