Hey there. First post. (yay)
First of all, amazing work, all of you. The amount of reverse engineering here could fill volumes (and in fact, it seems you're working towards that goal).
So, I mean to ask: I want to edit the item data (specifically weapons and armors). From what I've read, it's in kernel.bin, which I've dutifully taken apart, and have 27 gzip archives, and 27 ungzipped directories with 1 file in each. I've been looking through them with Hex Workshop, but does anyone have any input on how the first few files (which I assume have the data, with 10-27 holding the text) are constructed?
Any help would be appreciated.
UPDATE: Made some progress, in that I think I know where the data is. File 6 contains data which matches Cloud's weapon data, and I'm trying to figure out the exact format now. Upon first inspection, if we can get the edited file back into kernel.bin we should be able to edit attack, hit%, slots, growth, etc. Basically, it's all in there.
Anyone know how to put these files back into kernel.bin? I can't find the right gzip format to use. Something proprietary?
UPDATE: It's gzip compression level 8 (pretty sure this is cross-platform), without storing the filename. I ran it as such:
cat 6.new | gzip -n -8 - >6.new.gz
where 6.new is the new 6th segment. However, there seems to be a 6-byte header on each file portion, with unknown data. The last two bytes seem to count which file it is, until it reaches 9, where it doesn't count up any more. The other 4 bytes don't appear to be a checksum, at least not in any format I know. The header for file 6 seems to be:
B0 06 00 16 05 00
Any ideas?
UPDATE: Alright, successfully re-inserted a modified 6th file into kernel.bin, which the game recognizes, leading to the picture in the post below. I think the 255 ATK was crashing the game, but either way, a Buster Sword where I just changed the slots / growth rate seems to have worked. However, the previous version had a different file length, which I accounted for in the 6-byte header. Anyway, I'll keep messing around.
By the way, the only part of the 6-byte header you have to change to re-insert into kernel.bin is the first two bytes: they contain the length of the following gzipped segment. The next two are a complete mystery, and the final two count up from 00 00 to 09 00. Whoopee.
Also, I rather recently realized through some deeper forum-diving that this kind of work has been started before, but I haven't seen any end results? Am I just being stupid here and re-inventing the wheel?
