This is a scrambled image challenge from nanochang. The thread is dead over there and I'm curious to see if this can be solved. Here is the official hint:
>the bytes of a certain value get replaced by the bytes of another certain value and vice versa, the bytes of the latter value get replaced by the bytes of the former value. to make it more understandable - if you run the algorithm with the same two byte values on the output, you get the previous input, and vice versa
I'm supposing this means that one chosen value is swapped for another, for example if the values are FF and 0A, then all 0A bytes turn into FF and all FF bytes turn into 0A. I'm also supposing only the JPG image data is touched and the JPG header is left untouched. But the autistic way the hint is worded makes me doubt a little.
So without any checksum for the correct sum we'd have to generate and verify around 65,000 files. Anybody got any better ideas?
>>3630 Why is the image almost three times as big if you are only swapping bytes around hmmm
>>3624 Jesus fuck thats worded horribly. So the quest is to find the combination of bytes? i suppose we could take all the blue as a hint... it looks very, very blue
Color is written as three bytes, with each corresponding to a red, blue or green value. If you are swapping bytes and had an image that had very little blue (therefore very high bytes for the red and green bytes and something low for the blue) and swapped the high for the low as the autist said, you would end up toning down the red and green bytes and massively raising up the blue ones. So if my reasoning is correct, we can conclude that the two bytes have a very large distance between each other.
Also the way it is done suggests that the combination is not ordered, meaning the total amount of possible combinations is nowhere near 256**2 as youve suggested. Additionally we dont have to convert the entire image, i suppose the first third or even less would suffice to find out whether its something meaningful, cutting down on processing time
Also since the layers are shifted, it would appear that the header was touched and changed up a bit. Somebody who knows something about jpeg headers could tell us whether thats useful or not. Also the bytes that were switched must not just occur in the file, they must also do so in a very large amounts so that it will end up this fucked.
So a very good first step would be counting the bytes to see if that tells us something
>Why is the image almost three times as big
He's obviously angry at us for having this thread here, so tries to ruin it.
>it looks very, very blue
>Color is written as three bytes, with each corresponding to a red, blue or green value.
I am not sure if this is how JPG works. I know it is smarter than BMP.
>Also the way it is done suggests that the combination is not ordered, meaning the total amount of possible combinations is nowhere near 256**2 as youve suggested.
I was so wrong about that it's not even funny but can you tell me how many images would need to generate please? And how you calculated the number? I stopped at generating over 200,000.
>Also since the layers are shifted, it would appear that the header was touched and changed up a bit.
Yes he admitted on nanochang the entire file was modified, header included. Maybe the trick is to see in the header which values are bad if any, like you said.
>>3638 Ive tried to generate all the non-repeating (meaning combination 00 ff = ff 00) combinations of the 40 most common bytes but it only makes it into about a half and then it ends with a
* stack smashing detected *: <unknown> terminated
error
Ive never seen that one not gonna lie
From those that i did manage to generate, pic related is the most interesting one: the layers line up perfectly
Not sure what is the significance of that. the bytes swapped are FB and CF. Maybe one of these is the correct one and it swapped a byte in the header from an invalid one to a valid one?
Ive used the brute force approach and it took me about 5 mins to scroll to it
I wont reveal it as to not spoil it for the other nanons, ive just wanted to tell you that its solvable
If id just generated them all at the start it could have saved me an hour of attempting to outsmart it... an interesting lesson was learned today i suppose
>>3648 Got it. At first I thought there were 128 different swaps going on instead of just 1.
sha512: c7f80fb8f3b78629fa3894cc33a58bc7dc40ffab52ad5d33320ec4525f8115145b0748b6920ba34da2cf8b49c96129257a63c69a0a7b531be560478163557b12
>>3652 For a simple example every even number would be paired with the number above it (mod 256). There are very many different ways you can make pairs out of all 256 numbers.
>the bytes of a certain value get replaced by the bytes of another certain value and vice versa, the bytes of the latter value get replaced by the bytes of the former value. to make it more understandable - if you run the algorithm with the same two byte values on the output, you get the previous input, and vice versa
I'm supposing this means that one chosen value is swapped for another, for example if the values are FF and 0A, then all 0A bytes turn into FF and all FF bytes turn into 0A. I'm also supposing only the JPG image data is touched and the JPG header is left untouched. But the autistic way the hint is worded makes me doubt a little.
So without any checksum for the correct sum we'd have to generate and verify around 65,000 files. Anybody got any better ideas?