Xbox1 random padding compression

I tried converting a 7mb chunk of non game data, by first adding a bmp header from a real 7mb bmp image.

Intrestingly if you open-->save as-->tiff, psd, raw, or pxr-->then open-->tiff, psd, raw, or pxr-->then save over the original bmp.

There is practically no difference only 1 par2 block, which if we set the par2 block size very small this could be as little as a few bytes.

The only problem is when saved to a tiff, psd, raw, or pxr the size is the same as the bmp.

Does anyone know if theirs a file format like tiff, psd, raw, or pxr, that would save and be smaller than the original bmp, but when it is saved back as the original bmp, gives us back are bmp, with maybe a small sized repair.

Random data is random data, no matter which format you save it as. It simply can't be (losslessly) compressed in any way.

You could try png. It compresses lossless. Here's more info about its compression scheme: http://en.wikipedia.org/wiki/Portable_N … ompression
Considering that this is random data and not an actual picture, I doubt you'll see any significant compression gains over another file type. Wouldn't hurt to try though. 

I know of a way that could compress this sort of image. I couldn't make the program, and I'm not a 100% it would work, but it might.

An xbox iso is 7433027584 bytes

If if it was slpit into 7433027584 seperate files. 1 byte per file.

And every byte was numbered from 0000000001-7433027584 and kept in order

If a program was made to scan the iso.

When it see's the first byte (which just say it was) FF, it could then create a folder called FF, then all the FF bytes would be grouped into this folder but numbered by the byte position in the iso.

So say the first byte was FF and the 0000010099 th byte was also FF. tHE FF folder would contain the bytes @ 0000000001 and also 0000010099 and so on and so forth.

Once the iso had been split into sepertate bytes and seperate byte folders.

Then all the seperate folders could be compressed individually.

Then to get the iso back all the files would be extracted to a single folder and joined in number order, to form the iso again.

Any one know of any actuall programs that can split a 100mb or above into seperate 1 byte files numerically ordered, so far I've only found tools that can split up to 999 files. I need something that can split to 1 byte files, and able to at least handle 100mb files (1073741824 bytes)

I'm beginning to think we have no chance other than winrar store compression. But it was worth a go.

Thanks for sharing that nfo velocity37, you know more than me.

Im not that technically minded, but I am a fighter, and don't like giving in or loosing. So I persist, even if I am banging my head against a brick wall most of the time.

Just looking at that pic above, when I saw it 1st time, It made me feel sick. Why? Because looking at it, their is a hidden pattern. RANDOMNESS

If you think about it, they are using the same bytes just in a random order. I read somehere the gamecube garbage, is cipher something or other. In other words completely random.

In an ideal world we should make some small sized random file, using say every hex value, and have it shift randomly, like a blob of mercury, and at the same time have like another program like par2 that scans the random shifting file untill it finds a block then copies the block and carries on shifitng and finding more blocks.

FACT: (not much of one), but say quickpar's block size could be set to one byte. You can set it to 384,000 and below.

But thats stil 384 thousand times bigger than we want. The smallest size it goes on very small size files is 4 bytes

Take any 4 consequetive bytes "F3 28 A9 F7" and they only appear once. Take the next 4 consequetive bytes "4D 1B 95 1E" and they only appear once. And it would probably go on like that throughout the whole iso.

So theirs a clue in their pointing to the obvious it's as random as can be, but going back to my earlier point we need to make a small constantly shifting random file that kind of acts like a safe cracker.

If only par done 1 block par's, maybe that could be hacked, and it might do it as it may be able to but they left some of its possiblities out of the program for various reasons. Maybe on big files with 1 byte as its size, it would lock up syatems probably and thats why they left that option out!

Keep thinking we need to crack this, rather than forget it.

By the way I have tried converting a small samle about 4000 characters of the random data, to binary, it came out a lot bigger in binary, which I thought might compress to less, but it ended up bigger, and I have tried PNG

.

Would this work, converting hex to say base36?

F328A9F78C67ED651971BF74DCE989D5 - HEXADECIMAL

F328A9F78C67F0000000000000000000 - BASE 16

EE8OQPJ6BFKKWCGWGGOOOG0K0 - BASE 36

3631212476743063760000000000000000000000000 - OCTAL

This is all I've got time for now..

1/ How much padding would an average game have, does the amount vary from game to game?
2/ Would 2 copies of the same game have the same padding?
3/ Is the padding common to different games (maybe a particular developer has their own)?
4/ Is the entire padding for a game contiguous?
5/ Is the padding referenced in any way (maybe a hash check to ensure it's there), or is it properly just padding?

A1/ The smaller the actuall game data the more padding, so its exactly the same as the gamecube.
A2/ Yep I believe they do, two dumps that are equal have the same padding.
A3/ I haven't checked, as to check would be to make a 1:1 dump and the very difficulty wipe the game data, that could be something I might try though.
A4/ Dunno?
A5/ Dunno?

If padding is the same across many games, you've got the simplest answer.  Definately put I'm pretty sure its as random for each game, just as each individual game seems to have random padding from start to finish.

I did examine a section from the begggining of a padded part of the iso. I split of 999 parts 2048 bytes. I tried compressing using ape and they all came out bigger except two. I think it was probably those two half blank sectors, that contained some words of intrest.

IT SAID SOMTHING LIKE "MICROSOFT*XBOX*DVD" SHOULD HAVE MADE A NOTE OF IT. their was a bit more writing, I get the feeling it has something to do with the padding but it was just a header type bit of text like at the start of a dreamcast.bin file. But it was maybe 50 sectors from the start of the file.

You mods if you havent already seen this, go to the lba past the end of the video section, then sector view in isobuster, about 20-30 sectors and you'll see the MICROSOFT*XBOX*DVD text.

I have decided to give up finding better ways of compressing the random data.

The best compression I have found for the random padding is WinRAR store m0.

That only leaves one feasable option that would make us all jump for joy, would be to be able to generate it from scratch.

Wipe the padding first so it compresses then work out how to generate the exact data that was wiped, and hopefully the person in the process of doing this will spot what the random code is generated by.

nice thread and good thoughts. tossEAC's idea is great and sounds utopic, but this is the key.
jamjam suggestion is also good, it would be so awesome if someone could find out the algorithm for random padding.

i just doubt that both things are possible. i like this discussion. maybe someone has an even better suggestion. let's see.

in my opinion it's better to skip those data. who knows if they're useless because of copy protection?

How is that meant?

By that I mean that for games with more game data (as opposed to random padding), a higher % of the 7433027584 bytes an xbox image takes up will have a chance of being compressed well. I hope that makes sense.