Unreadable BMP files

32 posts in this topic

Posted · Report post

Any way to maybe fix the IG tower robot easter egg? Its arms get clipped off.

Share this post


Link to post
Share on other sites

Posted · Report post

Any way to maybe fix the IG tower robot easter egg? Its arms get clipped off.

 That would require extending its area as the arms would make the building a 5x3 building from a 3x3, unless you can get overlapping to work and not break things and not break or destroy anything that's taking up those sides including the radar station.

 

Also I need to get on RRU more often as I LOVE THIS.

Share this post


Link to post
Share on other sites

Posted · Report post

I accidentally disappear for several months, and I miss this!  I'm kicking myself now. xD

 

This has turned out to be way more complicated than I can easily understand... but I'm glad this was accidentally started.

 

Now, to bone up as much as I can on this so I can try to be useful again...

Share this post


Link to post
Share on other sites

Posted · Report post

Well, it seems I've forgotten about this place once again. Sorry for the random disappearance, this was literally just a small one-day project idea which I had and I kinda forgot about it. Although coming back to it, I really want to figure out how this stuff is compressed and stored, as well as the sounds since they seem to use compression as well. I might work on it tomorrow if I can and get to the bottom of this format. If I can get some sort of idea of how this format works by comparing the bitmaps I extracted vs the compressed versions, I might get somewhere.

 

EDIT: Some things I'm noticing after getting a more fresh view on things:

 

The first value in the header seems to be a 32 bit unsigned value, denoting something in terms of length (ie uncompressed size/decoded size). Depending on the file, this value gets marginally larger or smaller (ie the train carts and sounds have much larger values than things like houses and whatnot which only have one frame or many smaller frames)

 

The table at 0x408 seems to be a sort of lookup table, with each value being 32 bits long (4 bytes). The amount of entries in this table from 0x408-0x808 come out to 256 entries, or multiplied by 4, 0x400 bytes. As for what looks up entries in this table, I have a small feeling that the data at 0x808 is just a bunch of byte values referencing this table to make a set of data to be read. Don't have anything official yet, but I do believe that this is a very good hunch considering that while I was messing with the values everything was seemingly random despite the values only being messed with by a tiny bit. This could expain that. It also could explain how this format could be used for sounds as well since this area has been confirmed to not be a palette, but rather a sort of 'palette' of 32 bit values available to use. Again, not entirely sure at this point, but it seems to be a good hunch for now.

 

Once the bitmaps are decompressed, it might be possible that there's another bit of fluff to go through to figure out what format the uncompressed data is in. I'm praying that it's just an uncompressed raw 8bpp bitmap, but with how things are going that might not be the case. I'd also like to test this against sounds as well since it might be easier to figure out the sounds vs the images since sounds are more likely to just be raw data.

 

EDIT 2: I think the table might be in a slightly different format than I thought initially. I'm thinking it might actually be a sort of table which specifies bytes and the number of repetitions of that byte, perhaps in the format <byte> <repetitions> <byte> <repetitions>

 

EDIT 3: I think I'm getting somewhere with this. I'm doing comparisons between the ripped version of house12.bmp I have vs the house12.bmp which is compressed, and it seems to be that I'm somewhat correct. I counted 305 transparent pixels before reaching actual data, and based on the number of 0x55 bytes present at the end of the file, if you counted them and multiplied by 4 you'd get 304. If you add in the other 05 prior to the 55 array it might equal the 305 we're looking for. Now, since each entry in the table is (gasp!) 4 bytes long, we might be able to assume that one of the two hypothesis I had are correct. I'm actually placing my bets on the byte + repetitions because it seems that it would make the most logical sense seeing that every other byte is usually less than 4.

 

EDIT 4: This might be, once again, a little more complicated than I thought. I almost wonder if it's not even a compression format but just an encryption format or something, because this format is used on just about everything from bmp's to wav's even to a file called ee.ini. Honestly at the moment I think that this so called ee.ini might be my best bet on cracking the format since the wav's and bmp's could be under another layer of proprietary formatting, while an INI is a little more easy to guarantee what it will produce. I might actually be able to find a copy of the uncompressed version in RAM while the game runs, or find out how it's uncompressed and go from there. Since it's an INI file it's probably easier to track down than other files.

 

The main issue I've run into is that the data at 0x808 can have values over the length of the table. The table obviously seems to have values used to create the uncompressed data, but I cannot figure out the exact relationship.

 

EDIT 5: Apparently there's an uncompressed EE.ini. Might try to do some comparisons here...

 

EDIT 6: The values used in the table at 0x404 consist only of the values used in the INI, albeit in a slightly different order. However, every value is there.

 

EDIT 7: Not much real progress so far, but, I have found the file loading function in IDA. Apparently the weirdly formatted files are actually supposed to be handled through the resource file extractor. Oddly enough, it was mentioned once by Cyrem, the guy who made the extractor:

 

 

It seems to be marked in the archive file which files have a custom format, so once a finish the next version of this can start working on that. Also, the extraction process of the next version is like 500x faster than v1.1, it completes in like under 30 seconds now.

 

Luckily I actually found the check for compressed and uncompressed files, so now it's just a matter of reverse engineering the function which decompresses the file. If anyone's curious, the file header is formatted as such:

<32 bit word: amount of space to malloc, aka file size> <8 bit byte, something with decompression/compression> <8 bit byte, if 1 file is read as compressed>

All compressed files are normal files underneath, with normal file headers and easy-to-edit stuffs. So once I can write a decompression program you can keep the files uncompressed for as long as you please.

 

EDIT 8: This compression... I literally can't even. It's the weirdest compression I've ever seen in my entire life. It might be because I'm looking at in in assembly but I have no idea how I'm even going to attempt to recompress any of these files. Decompression maybe, but how in the world does this work...

 

EDIT 9: Witchcraft. That is the only answer here. Pure witchcraft.

 

EDIT 10: Success has been had. Documentation and a tool will be coming shortly...

 

EDIT 11: While I'm still kinda messing with things, here's an image file I extracted of the launchpad in it's full frameset:

FDmv5k3.png

This was actually one of the ones I was having difficulty ripping manually. I'm not sure if this is an error with me adding a header to the headerless bitmap, but one of the frames seems to be cut in half on each end for some reason. 

7 people like this

Share this post


Link to post
Share on other sites

Posted · Report post

Well now I need to get LEGO Loco working on something again. I might have a virtual already loaded for it and Hamachi.

 

I never got to play Loco on Hamachi with others. All the icons work client side I would imagine, right? What if you edited the train sprites? Is it the same train icons if it travels to another's area?

Share this post


Link to post
Share on other sites

Posted · Report post

I believe that the resources are entirely client side, so you would need everyone to have the same data or things could go weird. Not entirely sure how the networking works though...

I believe that the resources are entirely client side, so you would need everyone to have the same data or things could go weird. Not entirely sure how the networking works though...

Share this post


Link to post
Share on other sites

Posted · Report post

I believe that the resources are entirely client side, so you would need everyone to have the same data or things could go weird. Not entirely sure how the networking works though...

 

I am almost positive this is correct, just like (as a poor example) Minecraft mod packs.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now