3 ms·
Figure 33's hexdump and Figure 35's binwalk output look suspicious to me. The hexdump is too sparse - lots of zero bits but no long runs of 0x00, consistent 0x0
by nneonneo 3y ago
Figure 33's hexdump and Figure 35's binwalk output look suspicious to me. The hexdump is too sparse - lots of zero bits but no long runs of 0x00, consistent 0x00, 0x01 or 0x10 in odd-numbered positions, etc. It might be valid, or it might point to some kind of clocking or pinout issue. The binwalk output is even more suspicious - the signatures are likely all spurious. One does not expect a Flash ROM to consist solely of MySQL databases, particularly not random versions; this is likely the result of random bytes happening to match the file signature. As such, there don't seem to be any recoverable files in the dump per binwalk.
- chc4 3y agoYeah, I'd suspect that binwalk output to be junk from the flash tripping heuristics: "MySQL database" is one of those heuristics that a lot of random binary files trip spuriously for who knows what reason. Practically every other read word is `10 00 10 00` which is definitely strange, but also it's hard to judge if that's wrong without looking at the dump more IMO.
- monocasa 3y agoYeah, there's no way it's running MySQl. I'd expect to see a CPIO archive, a UBoot copyright string, or something in that wheelhouse at the top of binwalk given that it's the NOR flash to a mediatek soc.
- Boardbricker34 3y agoThe binwalk is more than likely not aligned for the endianess that is used. This dump was made to just be an example that magic existed and there was data that came from the flash chip using this method. Not necessarily the binary enumeration of the dump. The magic binwalk found is more than likely junk. If one was looking to flip endianess on a dump, use the -swap and it will flip around strings.