GoodTools reverse engineering research project.
- Unpack the GoodTools executable using your method of choice. x32dbg is suggested but not required.
- Find the hash details of the first entry with OpenGood or manually with Ghidra or IDA Pro. If the tool you are dumping is an old-style database, you may only need the CRC32 or name of the first entry.
- Use
zg-findto find the offsets of the first entry. - Use
zg-dumpto dump the database once the offsets are found.
zg tools only work with unpacked GoodTools executables. The executable can be unpacked with x32dbg and the Scylla plugin.
Helper to find offsets for the embedded database. For 'old-style' databases (generally prior to 3.2x), only the CRC32 or the name of the first entry is needed. For 'new style databases (3.2x+), all of the CRC32, SHA1, and name of the first entry is needed.
The first entry is the entry listed in first line in the *Miss.txt file when GoodTools is ran within an empty folder.
Any necessary hashes for 'new-style' databases can be looked up with OpenGood unless if the first entry is missing; in that case, it will have to be determined manually with a reverse engineering suite.
For example, to find offsets for GoodWSx (new-style)
$ zg-find "GoodWSx_unpacked.exe" new --crc "2cbe41a6" --sha1 "28a0e1bccc4c10a57379f87c67c6c5ecf07fb0f4" --name "#Wonderwitch Promo Beta Demo by Dox (PD)" For GoodPico (old-style)
$ zg-find "GoodPico_unpacked.exe" old --crc "d62e3372"A line of command arguments that can be pasted directly to zg-dump can be outputted with the -C flag.
Dumps CRC32 and SHA1 hashes given the known offsets of each table and the number of known ROMs. Generally you should find offsets with zg-find -C and pipe the resulting command line arguments into zg-dump.
zg-dump can also output Logiqx XML or TSV with the -f flag and -o flag to write output to a file. See zg-dump --help for more information.
There is nothing really specific to GoodTools in zengyaku's code; at its core it just searches an executable for some patterns, then tries to make sense of it. If you feed zg-find or zg-dump other executables in all likelyhood it will dump out some (albeit questionable) output. However, if you unpack a GoodTools EXE with a debugger, then run zengyaku on the result, that pretty clearly violates clause 3, if you care. For that reason, I do not publish any database information extracted directly from the GoodTools executable here.
Outside of intellectual curiosity, most definitely not. GoodTools does not contain any size or file extension information that OpenGood provides for the same set of ROMs. OpenGood is also clearly not in violation of the GoodTools license as the information there was not directly extracted from the GoodTools executable, whereas zengyaku can be used to do so.
No, zengyaku is a source-only distribution. If you have trouble setting up a Rust toolchain, please take a look at OpenGood and see if that would better fit your use case.
Please take a look at OpenGood and see if that would better fit your use case. While there are some missing ROMs owing to the nature of how OpenGood's data was collected, OpenGood provides additional information like file size and MD5 hashes as well. Publishing a database extracted directly from GoodTools is clearly in violation of clause 3 of the GoodTools license.
As a rule of thumb, new-style databases are used in V3.2x-tools, with older tools using the old-style database. To know for sure, you may need to try zg-find a few times until the resulting offsets make sense. New-style databases store hashes in separate contiguous binary arrays, whereas old-style databases is an array of strings containing ASCII-encoded hash information. zg-dump can handle both formats, but the proper offsets must be supplied.
zengyaku is licensed under the MIT License and is provided for educational purposes only.