What is the problem? It seems like everything is functional
#e
unique talon
prisma echo
The data it extracts seems to be compressed? Or are not images from what we can tell
We tried to throw the bytes to Pillow and save it as png but that didnt work
but it should be correct. there is a crc32 checksum, and it does match, I assume it's some compression format, completely unknown. lzma might be an option, but if so, there is no lzma header, and the properties and so on where hardcoded instead. But we couldn't figure out what those might be. And we're not even sure if it's lzma to begin with.
I did notice that every single one of those extracted files ands in: 0x21 0x00 0x00
even those that are "empty" (bitmap resolution is defined as 0x0 width and height)
prisma echo
@unique talon any idea?
unique talon
how do you know the picture is a PNG? @prisma echo
prisma echo
it's bitmaps most likely
unique talon
well from the src code it doesn't look like any compression is happening
prisma echo
the files all have this header:
compressionMethod=stream.readBits(8);
compressionParams=stream.readBits(8);
and
there's this function
unfortunately, Fay:: isn't in the source and nowhere to be found online
the data we have might be little endian? but again, we dont know how to tell for sure
unique talon
so you're reading the correct number of bytes and everything else is making sense. its just the blob of data isn't able to be interpreted as an image
send the binary as a file
unique talon
wait no send the parsed out bitmaps
prisma echo
these could be anything, GUI images, sprites, tiles
fonts? the data file has sounds "archived" too it seemed, at the bottom of it
this one is larger
what just struck me
is that these have different headers and one was "recognized"
unique talon
the bitmaps probably are just data. so the fact it was "recognized" was possibly just a coincidence like the data formed a "header"
prisma echo
i see
ฦตnull*
a 24MB archive doesn't have 24k bitmaps in it
you're seeking in the file based on bad data, if you'd log the positions it seeks to i'm sure you'll find yourself revisiting the same data repeatedly... not sure how you manage to get out of that loop but it really doesn't matter
hmm
unique talon
It doesn't seem that the bitmaps are distributed equally
If I had to guess, all the headers are first written to the start of the file, and then the bitmap data are written
So
Header1, H2, H3, ..., Hn
Data1, D2, D3, ..., Dn
but of course your script already takes this into account
unique talon
i think you're reading the file wrong
there's no way there are that many files in there
unique talon
@prisma echo did you parse the same file you sent me? i'm getting different numbers
ah i understand now. your script has a bug. you don't parse the version
unique talon
actually nvm you properly skip the version number
and im also wrong, i think there are that many bitmap files. because there's also exactly that many headers
but also, just because the file has the same crc doesn't mean that it is a duplicate
although yeah, some data positions point to the same data
unique talon
It is interesting that the data always ends with 21 00 00 it seems
Okay I'm off to bed but here's my work in decoding so far. it's just a list of all the headers
prisma echo
@unique talon morning mate
Huge huuuge thanks for these insights and your time, it was 3AM for me so i was lying on 1 ear at that time lmao
can you share your script with me? ๐
Good Boy Sani โ Today at 10:17 AM
I did verify that all crc32 checksums also produce unique sha1 sums at one point. So I'm pretty sure the crc32 sums (in the case for the "data" file) have no collisions.
prisma echo
It is interesting that the data always ends with `21 00 00` it seems
we figured out that too
might have to do something with compression is our current guess, though unsure
prisma echo
.
prisma echo
.
whole flax
Can you stop spamming . ffs
You do not need to bump your post 3 times in one day when there was literally a single post above yours
prisma echo
yeah sorry mate