General > General Technical Chat
CRC: How probable is it to find two diferent files with the same CRC
Bicurico:
So I was looking at the "Wando T2 Max" portable video projector with Android 9. This is a cheap chinese made video projector which costs around 150-200 Euro, from a company that belongs to Xiaomi, as it seems. I was trying to figure out if this would suit my needs (watching movies on a large screen in bed, with lights out, so the little lumen of this device should/could be enough).
Anyway, reading through reviews and what not, I stumbled on XDA Developers, where there are two threads, one for the T2 Max with Android 6 and the other for T2 Max with Android 9. Of course, this being a chinese product, there are different HW versions of the T2 Max and even more FW versions.
On the thread for the Android 9 version, people were discussing different FW version to fix some issues like lag caused by the software based keystone correction. On the thread, there were links for two different FW versions. I downloaded both and wanted to check how safe it seems, considering there might be different HW versions. I wanted to test how similar these two FW were or if they hinted at one single HW revision.
To my surprise I found something odd: two files for the main flash space had different size and content, but 7Zip showed them having the same CRC! I know that this is not impossible, as there are many more combinations in 1.6GB than in the 32 bits of a CRC. Still, I found it funny to find such two files in two different FW releases for the same HW, yet both files are different (even if slightly).
I wonder if this is indeed a coincidence or if the CRC is in fact used as a checksum by the flashing routine and bytes have been added/set in order to achive that specific CRC.
Attached is a picture showing both files in an Hexeditor and the respective CRC32 being shown.
What do yo think about this?
Cheers,
Vitor
Siwastaja:
"CRC32" does not specify the exact algorithm (polynomial, reflection, etc), but assuming it's some of the usual suspects (like the most usual 0x04C11DB7), it is so unlikely that I'd place my bets on that program miscalculating the CRC one way or another, for example truncating data and only using part of it by accident.
Can you try another CRC calculation software?
But of course it is possible; you can also win in a lottery.
Brianf:
It feels like the answer to the question ought to be 1:2^n, where 'n' is the number of bits in the CRC.
tom66:
--- Quote from: Brianf on January 16, 2023, 07:05:34 pm ---It feels like the answer to the question ought to be 1:2^n, where 'n' is the number of bits in the CRC.
--- End quote ---
This. CRC values are evenly distributed, think of them as a remainder of a sum. Therefore, a 32-bit CRC has 2^32 possible values. All zeroes, all ones, and every bit pattern in between is equal, and there should be no reason the distribution is anything other than flat (for random input).
CRCs are very easy to fool, they are even less cryptographically secure than MD5. For any n-bit CRC, you can change the CRC to match an arbitrary value by appending between n and ~2n bits to the file. (2n for the case of a 9-bit CRC, you would have to change up to 16-bits as byte boundaries exist).
It could be that the CRC is deliberately faked to allow a buggy firmware updater to work (perhaps the CRC was hardcoded somehow!)
gorignak:
--- Quote from: Bicurico on January 16, 2023, 06:13:47 pm ---I wonder if this is indeed a coincidence or if the CRC is in fact used as a checksum by the flashing routine and bytes have been added/set in order to achive that specific CRC.
--- End quote ---
I have seen that before. It's easy to make the CRC be whatever you want, so having a fixed CRC for all firmware updates isn't big deal.
Navigation
[0] Message Index
[#] Next page
Go to full version