alastairstevenson
Staff member
Hikvision G1 5.5+ firmware Exploring the Cam & attempting unlock
- Thread starter rearanger
- Start date
Been reading this thread (and the "Unrestricted root shell on G1 cameras" one) - thanks to everyone who mapped this platform out. I've got a G1 I'm trying to unlock and I've boxed myself into a corner. Hoping someone recognises the state.
The camera
- Alarm.com OEM unit (ADC-VC726), Ambarella S3L33M-B0-RH, NAND MT29F1G08ABAEA (128 MiB), platform G1
- Stock fw V5.5.82 build 210706, EN/World region (serial …WR…)
- U-Boot 3.1.6-486718 (Jan 5 2019), bootloader prompt is HKVS #
- Original boot log had bootParms.devType=141826
- Full two-way serial at 115200 8N1; camera boots fine, not bricked.
I already know from this thread that the old setenv bootargs … init=/bin/sh / debug single route is dead on anything past ~3.1.6-297597, and my loader confirms it - printenv is stubbed ("not supported") and setenv only accepts ipaddr/serverip/netmask/gatewayip/ethaddr/bootdelay/dbg, not bootargs. So no shell that way. I also saw the report that a modified mImage got root/ash on U-Boot 3.1.6-540659 - that's the kind of lead I'm chasing (see questions).
The mistake I need help undoing
Before I understood the partition map, at HKVS # I ran erase cfg_pri, erase cfg_sec, erase dpt, and - the damaging one - erase param. (For what it's worth: none of those cleared the admin credential. The password salt came back byte-identical after all four wipes, so on this unit the credential is not in any bootloader-erasable config/data partition — it's in the app/firmware area or fixed per-device. That alone might save someone a wasted evening.)
Since erasing param, every boot prints:
please check flash
init_boot_param:nand_read_data failed
U-Boot and the psh recovery shell both still work. format app_pri app_sec cfg_pri cfg_sec succeeds and
drops to psh. But the one thing that would come up inactive — a clean reflash of the stock EN package —
is refused at the burn step, writing nothing:
[ERROR] BURN: Can't get platform, default flash size is 128M!
[ERROR] BURN: Can't get platform, default platform is g1!
[WARN ] BURN: get bp failed, cn default.
[ERROR] BURN: digicap package error, can not upgrade!!!
[ INFO] BURN: Write Flash [FAIL] error: write flash.
!!!!! UPDATE FAIL !!!!!
The .dav is the correct IPC_G1_EN_STD_5.5.82_181211 (TFTP download reports [OK], full 36,390,527 bytes).
My read: the boot params / region+devType lived in param, and with them gone the burner falls back to CN
and rejects the EN package on a region check. upf is no help — it TFTPs for a factory mImage_g1 before
formatting, which I don't have and the forum builds I found are for older loaders / fail signature on
3.1.x.
Questions
1. Has anyone recovered a G1 from get bp failed, cn default - i.e. rebuilt the param / boot-param block from the HKVS # loader or the psh recovery shell? Is upbs (it's in my command list) the tool for that, and if so what does it expect?
2. Is the param partition board-generic, or per-unit (MAC/serial/devType baked in)? If generic, a raw dump from a healthy same-gen G1 would get me out - is anyone willing/able to dump theirs, and what's the clean way to read it on a loader where printenv is stubbed (no obvious nand read/md)?
3. Is there a modified mImage that yields root/ash on U-Boot 3.1.6-486718 specifically (the 540659 success gives me hope)? If I can get a one-time root shell I don't need persistence - I'd rewrite the boot params directly and then the stock reflash should take. Unsigned-digicap-once-you-have-root is also on the table.
Serial logs (locked-U-Boot command inventory, post-erase param boot, the failed burn, the upf/mImage_g1 attempt) all available - say which would help. Thanks!
The camera
- Alarm.com OEM unit (ADC-VC726), Ambarella S3L33M-B0-RH, NAND MT29F1G08ABAEA (128 MiB), platform G1
- Stock fw V5.5.82 build 210706, EN/World region (serial …WR…)
- U-Boot 3.1.6-486718 (Jan 5 2019), bootloader prompt is HKVS #
- Original boot log had bootParms.devType=141826
- Full two-way serial at 115200 8N1; camera boots fine, not bricked.
I already know from this thread that the old setenv bootargs … init=/bin/sh / debug single route is dead on anything past ~3.1.6-297597, and my loader confirms it - printenv is stubbed ("not supported") and setenv only accepts ipaddr/serverip/netmask/gatewayip/ethaddr/bootdelay/dbg, not bootargs. So no shell that way. I also saw the report that a modified mImage got root/ash on U-Boot 3.1.6-540659 - that's the kind of lead I'm chasing (see questions).
The mistake I need help undoing
Before I understood the partition map, at HKVS # I ran erase cfg_pri, erase cfg_sec, erase dpt, and - the damaging one - erase param. (For what it's worth: none of those cleared the admin credential. The password salt came back byte-identical after all four wipes, so on this unit the credential is not in any bootloader-erasable config/data partition — it's in the app/firmware area or fixed per-device. That alone might save someone a wasted evening.)
Since erasing param, every boot prints:
please check flash
init_boot_param:nand_read_data failed
U-Boot and the psh recovery shell both still work. format app_pri app_sec cfg_pri cfg_sec succeeds and
drops to psh. But the one thing that would come up inactive — a clean reflash of the stock EN package —
is refused at the burn step, writing nothing:
[ERROR] BURN: Can't get platform, default flash size is 128M!
[ERROR] BURN: Can't get platform, default platform is g1!
[WARN ] BURN: get bp failed, cn default.
[ERROR] BURN: digicap package error, can not upgrade!!!
[ INFO] BURN: Write Flash [FAIL] error: write flash.
!!!!! UPDATE FAIL !!!!!
The .dav is the correct IPC_G1_EN_STD_5.5.82_181211 (TFTP download reports [OK], full 36,390,527 bytes).
My read: the boot params / region+devType lived in param, and with them gone the burner falls back to CN
and rejects the EN package on a region check. upf is no help — it TFTPs for a factory mImage_g1 before
formatting, which I don't have and the forum builds I found are for older loaders / fail signature on
3.1.x.
Questions
1. Has anyone recovered a G1 from get bp failed, cn default - i.e. rebuilt the param / boot-param block from the HKVS # loader or the psh recovery shell? Is upbs (it's in my command list) the tool for that, and if so what does it expect?
2. Is the param partition board-generic, or per-unit (MAC/serial/devType baked in)? If generic, a raw dump from a healthy same-gen G1 would get me out - is anyone willing/able to dump theirs, and what's the clean way to read it on a loader where printenv is stubbed (no obvious nand read/md)?
3. Is there a modified mImage that yields root/ash on U-Boot 3.1.6-486718 specifically (the 540659 success gives me hope)? If I can get a one-time root shell I don't need persistence - I'd rewrite the boot params directly and then the stock reflash should take. Unsigned-digicap-once-you-have-root is also on the table.
Serial logs (locked-U-Boot command inventory, post-erase param boot, the failed burn, the upf/mImage_g1 attempt) all available - say which would help. Thanks!
alastairstevenson
Staff member
Not from that u_boot version, but an earlier version, this may be worth trying (worked for me to get a root shell on a DS-2CD2135 some years ago) :
And the 'param' partition from the G1 camera DS-2CD2135FWD-I running the 5.6.4 firmware, if it may be useful, attached.
Thanks, this is really helpful context. Confirmed the mechanism (tftp mImage_g1 + digicap.dav, then upf > update) is exactly the G1 path I was looking at over UART.
One gotcha for anyone landing here: that image is scoped to U-Boot 3.1.6-279309 (May 2017) or earlier, and my board is on 3.1.6-486718 - newer build, so the signed-digicap.dav checks it sidesteps are back in play. Going to confirm the SoC from the full U-Boot banner before trying a build-matched psh-free image rather than flash this one blind.
Appreciate you pointing me at it either way - the "keep mImage_g1.original to restore" note especially.
Also grabbed the mtd5ro param dump - looks like 3 redundant encrypted copies on a 0x20000 stride, so it's a handy layout reference for sanity-checking my own dump even if the config itself is sealed. Thanks for attaching it.
One gotcha for anyone landing here: that image is scoped to U-Boot 3.1.6-279309 (May 2017) or earlier, and my board is on 3.1.6-486718 - newer build, so the signed-digicap.dav checks it sidesteps are back in play. Going to confirm the SoC from the full U-Boot banner before trying a build-matched psh-free image rather than flash this one blind.
Appreciate you pointing me at it either way - the "keep mImage_g1.original to restore" note especially.
Also grabbed the mtd5ro param dump - looks like 3 redundant encrypted copies on a 0x20000 stride, so it's a handy layout reference for sanity-checking my own dump even if the config itself is sealed. Thanks for attaching it.