Chron0s
n3wb
- Joined
- Apr 1, 2018
- Messages
- 2
- Reaction score
- 0
I have several of these. One, in an Escam QD300 housing, decided to die one evening so I replaced the front board with that from a TOP-201 after transplanting the IR filter switcher and a few hacks to get rid of telnetd, add dropbear and set up NFS. That fixed the QD300 but it transpired that the front board simply had a dicky SPI flash and there was nothing else wrong with it.
Long story short, I replaced the 8MB SPI chip and flashed a copy of a backup from the other board to it. No problem, right? We can change the MAC from within u-boot with the mac command, right? Wrong.
It turns out there's a bit of encrypted/obfuscated code at address 0x1fc00 in the u-boot partition that holds the MAC and some sort of key that Sofia uses to authenticate. With the original MAC (definitely sub-optimal as there's now two cameras with the same MAC on the segment) the thing works perfectly. If I erase the 0x4000 block at 0x1fc00 and force a MAC change, the binary bit in the version ID changes from a 1 to a 3 and Sofia resolutely refuses to do anything. It's a pain in the backside.
My question is this: Does anyone know how to reconstruct that 0x4000 block at 0x1fc00 from the MAC address that will allow Sofia to run without a) rebooting and setting the MAC to the clone, which it does with the cloned block in place or b) sulking, which it does without the block. I know these are cheap and hardly worth wasting time on but it's annoying me. What should be a simple bit o' faffing with a CH341 and throwing the right incantations onto the sacrificial altar of u-boot has turned into a big, red stop sign. I'd rather spend the time to fix what I already have than contribute to the planet's e-waste.
If anyone has a scrap board (dead sensor, lightninged and so on) that doesn't need its MAC any more, that would be handy instead, although I really would like to understand that block of data.
Long story short, I replaced the 8MB SPI chip and flashed a copy of a backup from the other board to it. No problem, right? We can change the MAC from within u-boot with the mac command, right? Wrong.
It turns out there's a bit of encrypted/obfuscated code at address 0x1fc00 in the u-boot partition that holds the MAC and some sort of key that Sofia uses to authenticate. With the original MAC (definitely sub-optimal as there's now two cameras with the same MAC on the segment) the thing works perfectly. If I erase the 0x4000 block at 0x1fc00 and force a MAC change, the binary bit in the version ID changes from a 1 to a 3 and Sofia resolutely refuses to do anything. It's a pain in the backside.
My question is this: Does anyone know how to reconstruct that 0x4000 block at 0x1fc00 from the MAC address that will allow Sofia to run without a) rebooting and setting the MAC to the clone, which it does with the cloned block in place or b) sulking, which it does without the block. I know these are cheap and hardly worth wasting time on but it's annoying me. What should be a simple bit o' faffing with a CH341 and throwing the right incantations onto the sacrificial altar of u-boot has turned into a big, red stop sign. I'd rather spend the time to fix what I already have than contribute to the planet's e-waste.
If anyone has a scrap board (dead sensor, lightninged and so on) that doesn't need its MAC any more, that would be handy instead, although I really would like to understand that block of data.