 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - The Cutting Room Floor - Pokémon Colosseum bullshit |  -  -  |
| Next newer thread | Next older thread |
| Afti Member Level: 25     Posts: 108/114 EXP: 80039 For next: 9581 Since: 06-21-10 Since last post: 7.2 years Last activity: 6.9 years |
|
||
|
SamEarl13 Nipper Plant Trying (and failing) to learn Lua. Level: 43  Posts: 201/419 EXP: 523186 For next: 41860 Since: 02-14-12 Since last post: 4.1 years Last activity: 8 days |
|
||
| I've currently got that game on my hard drive so i'll help you look into it. ____________________ I'm currently saving up for a game so if you are going to buy anything from amazon could you click this link first: This is the link |
| GuyPerfect Catgirl Level: 68 Posts: 795/1096 EXP: 2663392 For next: 65408 Since: 07-23-07 Since last post: 1.6 years Last activity: 210 days |
|
||
Originally posted by Afti Post some sample data. We'll figure it out for you. |
| Afti Member Level: 25 Posts: 109/114 EXP: 80039 For next: 9581 Since: 06-21-10 Since last post: 7.2 years Last activity: 6.9 years |
|
||
|
You sure? All right; a handful of things I yanked out of common.fsys. I can supply more as needed.
https://www.dropbox.com/s/rwa2n649o7wotpd/sample1.zip ____________________ |
| Rena I had one (1) message in Discord deleted and proceeded to make a huge, huge mess about how it was a violation of free speech and how moderators are supposed to be spam janitors and nobody should have the right to tell me not to talk about school shootings Level: 135 Posts: 4893/5390 EXP: 29050689 For next: 284316 Since: 07-22-07 Pronouns: he/him/whatever From: RSP Segment 6 Since last post: 333 days Last activity: 333 days |
|
||
|
Post #4893 · Fri 121109 231859
$ hd -n 256 common_relFirst word is obviously a signature; second is 1,369,520, which is about 2.9 times the file's size, so good bet for uncompressed size; third is 478,305 which the file's size; fourth is likely padding, but potentially an offset into the file (minus header). What I've seen from similar formats was that the header pointed to two sections, one containing raw data and the other containing offset/length pairs, and was followed by a bitmap telling which to read from next. This doesn't have any such pointer, and the following data seems to have quite a few zero bits, actually resembling machine code somewhat for the first few words. The name "common_rel" suggests an executable, so this makes sense. I haven't tried to disassemble it though, so I might be way off there. As you look further into the file there are some pretty obvious patterns, which is strange for compressed data. Starting around 0x700 looks like some type of uncompressed graphic. Especially you can see a pattern 1C xx xx repeating often... but, sometimes there are three bytes between the 1Cs instead of two. That looks similar to the ASCII text around 0x440, that has readable words with single bytes inserted: 00000480 05 c5 07 e7 77 69 6e e7 00 d5 0c 76 69 72 ef 74 |....win....vir.t|And there's an obvious bit pattern in some of those. Check this from 0x48E: EF ;binary 1110 1111 74 75 61 6C ;ASCII "tual" (from "virtual") BF 0A ;??? 73 69 72 ;ASCII "sir" (from "siren"?) FF ;binary 1111 1111 65 6E 5F 61 74 6D 6F 73 ;ASCII "en_atmos" (siren_atmos, probably a sound file name) FE ;binary 1111 1110 BF 0A ;??? 6C 65 76 65 6C 5F 79 ;ASCII "level_u" See the pattern... Counting from right to left (least significant bit first), 0xEF has 4 ones, a zero, and three ones. And immediately after it, we see 4 bytes of ASCII, something unusual (BF 0A), and then three bytes of ASCII. The same pattern follows further on: FF followed by 8 ASCII bytes, FE followed by one unknown (BF 0A again) and 7 ASCII bytes. So, obviously these bytes are bitflags, counting from least significant bit upward, where 1 indicates a raw data byte and 0 indicates something else. I would expect that "BF 0A" is some type of offset, meaning to copy some bytes from elsewhere into the output. I also notice that these are occurring at the end of each string, and 0A is a newline character, but this doesn't seem to repeat further on, so this is probably coincidental. I'd guess that BF 0A means to copy 0xA bytes from offset 0x0BF. In other formats I've dealt with, those are relative offsets, so this would mean seek 0xBF bytes back in the output buffer and copy from there. It's a bit odd to see the same offset twice if it's relative, though. Another interpretation is 0x0A bytes from 0xBF. More likely, the actual count is 0xC or 0xD, because it takes two bytes to encode this, so there'd be no reason to ever have a count of less than 2. 0xC seems likely, since it's a multiple of 4, so as to align the strings to word boundaries. If we assume this applies to the entire file after the header, we run into an interesting situation: the first byte is EA, binary 11101010, which means the first bit decoded would be 0, meaning to copy from previous output... but there's no previous output to copy from, so that doesn't make much sense. The pattern does seem to fit, though: EA ;binary 1110 1010 EDF0 7D E6F8 0B EDF0 4C 00 00 AB ;binary 1010 1011 15 3C EDF0 27 EDF0 03 ECF2 14 EB ;binary 1110 1011 BF 70 1200 60 EDF0 10 01 01 FD ;binary 1111 1101 01 EAF4 05 FC 00 00 0A 80 following the bits from lowest to highest, we reliably encounter pairs that resemble those we saw earlier, and bytes that don't, exactly where we'd expect. So it's reasonable to say that this is the encoding of the entire file; the question being what exactly ED F0 (and BF 0A and so on) means. Mostly they seem to be twelve bits having a high value (0xEDF, 0xE6F, 0xBF0) and four arbitrary bits. That corresponds well with length/offset pairs, and matches some of Nintendo's older compression formats. I always thought it didn't seem very efficient when the maximum number of bytes that can be repeated is so small, though. Still, that doesn't tell where the data is coming from, given these offsets don't make any sense for such a large output buffer. (The offsets might be interpreted as 0xFED, 0xFE6, 0x0BF, but they're still too large.) It's possible they're offsets into some separate dictionary. That would make the repeated offsets between strings make sense, too, especially if it's padding and/or metadata. Being an offset into the file itself is another possibility, but it doesn't look that way here. So, it might be necessary to find a dictionary table that goes with these files. ____________________ |
Eon Hammer Brother MLB Level: 68 Posts: 958/1085 EXP: 2623791 For next: 105009 Since: 07-22-07 Since last post: 300 days Last activity: 120 days |
|
||||||||
|
|||||||||
| Next newer thread | Next older thread |
| Jul - The Cutting Room Floor - Pokémon Colosseum bullshit | - - |
 |
Acmlmboard - commit 47be4dc [2021-08-23] ©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al. Warning: You are using TidyHTML mode! Pages MAY and probably WILL break. To disable, click here or append 'xxx-off=1' to the URL!  |
| Query execution time: | 0.086822 seconds |
| Script execution time: | 0.018911 seconds |
| Total render time: | 0.105733 seconds |
