New G1 camera root status

[watchful_ip]

Hello everyone
I want to upgrade a few of my EasyIP 1 cameras to newer 8MP G1s, and I just don't like the idea of no root access to cameras I own.

Read some threads, and seems there's a solution for older uBoot versions using sec.bins or minisys. How likely is it if I buy a new camera anything will work with newer uBoot?

Don't really want to flash the NAND directly.

Thanks! This is a really great forum!

 

[alastairstevenson]

The @rearanger modded @montecrypto minisys should work OK, allowing the initrun.sh startup script to be modified to bypass psh and give a root shell.
Check out this thread : Hikvision G1 5.5+ firmware Exploring the Cam & attempting unlock

 

[watchful_ip]

Hi!

I did read it - but I saw all the uBoot versions were 2017 and wondered if anyone had got a G1 with a uBoot version newer, that there was no confirmed working minisys for?

Great work by all on this by the way.

 

[alastairstevenson]

In post #7 is the @rearanger modified minisys that worked OK with this version of bootloader :
Boot 3.1.6-526164 (May 6 2019-11:48:53)

 

[watchful_ip]

oooh interesting - I'd missed that. Sorry for potentially making a thread asking questions maybe already answered.

@rearanger did you mod that yourself? Have some experience of making new images, repacking existing linux filesystems, kernels etc so if so, just good to know it can be done without signing keys etc. Also is it necessary to simply change a version tag, or is a dump of the minisys partition associated with the uBoot version on a camera needed?

Just asking in case a new G1 comes with a uBoot newer than 3.1.6-526164 - I like to do research before hitting that tempting "buy" button

 

[watchful_ip]

In post #7 is the @rearanger modified minisys that worked OK with this version of bootloader :
Boot 3.1.6-526164 (May 6 2019-11:48:53)

Are you sure that's the case? Rereading it looks like 2017 versions were ok, but the 2019 version mentioned was on a different potentially non G1 from another user?

Is the minisys touched during normal boot? If one were to overwrite it with a non functional version would that:

a) prevent further updates to the mini system (as it's needed to update itself)?
b) prevent normal boot assuming the other partitions had valid data?

 

[alastairstevenson]

Are you sure that's the case? Rereading it looks like 2017 versions were ok, but the 2019 version mentioned was on a different potentially non G1 from another user?

Yes, that example was from a camera I was / is experimenting with that was running this firmware :

netprocess Infomation:
version: 8.11.3 [12:04:04-Dec 25 2018]
Path: /Camera/Platform/Branches/branches_FSP_network_protocol/shizhi/FSP_network_protocol_chanpin_V5.5.81_G1
Last Changed Rev: 482112
Last Changed Date: 2018-12-25 10:37:43 +0800 (Tue, 25 Dec 2018)

Is the minisys touched during normal boot?

Not that I'm aware of.

If one were to overwrite it with a non functional version would that:

a) prevent further updates to the mini system (as it's needed to update itself)?

A good question.
Possibly yes if the partition that hosts it is write-protected from a root shell in the normal running environment.
Writing the minisys from the normal running environment isn't something I've tried with a G1 camera.

b) prevent normal boot assuming the other partitions had valid data?

That should still be OK.
Worth noting is that the G1 architecture has quite an effective redundancy-based self-repair facility for the app and kernel partitions. But not for the recovery parition.
Damage the primary partition and the secondary is used for the running environment, and used to re-write the primary.

 

[watchful_ip]

Ah thanks for clearing that up. I'd only seen that uBoot version mentioned by @polaris here Hikvision G1 5.5+ firmware Exploring the Cam & attempting unlock and there it was maybe not a G1 (the thread was unclear) and no result was given.

But if you've tried it yourself on a G1 that's good news

I'm sure it's possible to write to the recovery partition even if it's kernel write protected. As long as you have a proper root shell of course

Ordered 2 cameras today, in part due to your quick and helpful responses @alastairstevenson
Look forward to getting my new toys, err I mean sensible home security products

 

[alastairstevenson]

I'm sure it's possible to write to the recovery partition even if it's kernel write protected. As long as you have a proper root shell of course

Unless the kernel has been compiled to make the partition read-only.
And the bootloader won't (obviously) boot another kernel over the network.

Ordered 2 cameras today, in part due to your quick and helpful responses

I do feel a bit guilty now.

Look forward to getting my new toys, err I mean sensible home security products

Yes indeed, mine fulfill both functions.

 

[watchful_ip]

Kernel write protection for a partition is overridable in my experience with the right LKM. Can be handy at times!

 

[alastairstevenson]

No kernel write protection for a partition is overridable in my experience with the right LKM. Can be handy at times!

Well, that might be interesting to explore.
The camera I was experimenting with has what looks like the 'bootpara block' in a read-only flash partition, as the old R0 series has.
This would be quite a change from other series which hold that data in a protected security chip.

 

[watchful_ip]

Yes I had a few cameras some years ago before I moved on to other things where I changed read only bootparams partitions. This was in the days on Chinese imports without EMV chips.

 

[rearanger]

The G1 minisys is just an Kernal image. I figured out what the bytes were at the time in the header. But I have forgotten why I changed them. But it works lol (there are documents out there with details on the header bytes)

You can also use the main kernel image from the digicap.dav. As a minisys and boot the cam.

Any G1's I have tried have taken the modified G1 minisys.

I have not looked at the internal workings of the cam any further . Due to the fact Leecher has removed public access to the unpacker/packer. I have been looking at that. and how it works. Also motecrypto's packer (confused by that a little, as it contains all the keys needed for G0 cams)

 

[watchful_ip]

The G1 minisys is just an Kernal image. I figured out what the bytes were at the time in the header. But I have forgotten why I changed them. But it works lol (there are documents out there with details on the header bytes)

You can also use the main kernel image from the digicap.dav. As a minisys and boot the cam.

Any G1's I have tried have taken the modified G1 minisys.

I have not looked at the internal workings of the cam any further . Due to the fact Leecher has removed public access to the unpacker/packer. I have been looking at that. and how it works. Also motecrypto's packer (confused by that a little, as it contains all the keys needed for G0 cams)

Thanks mate for the reply.

Presumably if you flash minisys with normal boot kernel then TFTP is effectively disabled and you can't update minisys anymore?
I am assuming the update of minisys is done not by the bootloader but rather minisys itself?

I played with ARM kernel images a while ago - and made a few of my own. It's a bit fuzzy though in my memory

 

[rearanger]

Thanks mate for the reply.

Presumably if you flash minisys with normal boot kernel then TFTP is effectively disabled and you can't update minisys anymore?
I am assuming the update of minisys is done not by the bootloader but rather minisys itself?

I played with ARM kernel images a while ago - and made a few of my own. It's a bit fuzzy though in my memory

NO

u-boot > minisys > main Linux

so you can trash minisys and or main Linux. Then just update good minisys, then use minisys to update digicap dav

I only ever trashed the partition files . I never trashed the actual partition structure.

 

[rearanger]

I was working on a shell script to unpack and repack hImage. unpack was fine but was unable to get repack to work.

 

[watchful_ip]

NO

u-boot > minisys > main Linux

so you can trash minisys and or main Linux. Then just update good minisys, then use minisys to update digicap dav

I only ever trashed the partition files . I never trashed the actual partition structure.

OK so that would mean TFTP and flashing of minisys is done by uboot, otherwise if you borked minisys and main linux (both pri and sec?) you'd be screwed unless you can flash the NAND directly.

If that's right that's much better!

 

[watchful_ip]

OK so the update script in the minisys looks to only deal with TFTP digicap,dav and updating it. That means the bootloader has to be updating the minisys so that's good.

There are RSA signing checks in the minisys updating binary, so if it will accept unsigned then it must be patched so that's all good.

Ideally I'd dump the original minisys before changing it, but of course if it's easy to do that then might not need to change it in the first place!

 

[alastairstevenson]

The G1 minisys is just an Kernal image.

But with a cpio rootfs section incorporated.
And within that is the update script (below), and the actual upgrade program, and tftp is still available.
From what I recall there is no NFS support in the kernel, but tftp can move files in and out OK.

#!/bin/sh

DOWN_STATUS=0

# cofig eth0
ifconfig eth0 $IP netmask $MASK
if [ "$GW" != "0.0.0.0" ]
then
    route add default gw $GW
fi

#/bin/checkip #remove it from firmware, set ip in SecureCRT script to avoid ip conflict
echo "[ INFO][MIN]TFTP: TFTP from server $SERVER "
echo "[ INFO][MIN]TFTP: Filename: 'digicap.dav'"
#echo "[ INFO][MIN]TFTP: Load address: 0xc0100000"

# get digicap.dav through tftp
if [ "$SERVER" != "0.0.0.0" ]
then
    if [ "$MS_ACTION" = "bld_update" ] || [ "$MS_ACTION" = "factory_update" ] || [ "$MS_ACTION" = "auto_update" ] ; then
        tftp -g -r digicap.dav  -l /digicap.dav -b 8192 $SERVER
        if [ "$?" = "0" ] ; then
            DOWN_STATUS=1
        fi
    fi
    if [ "$MS_ACTION" = "auto_updatev2" ] ; then
        /bin/flag4tftp
        if [ "$?" = "0" ] ; then
            DOWN_STATUS=1
        fi
    fi
else
    echo "[ERROR][MIN]TFTP: SERVER is none"
    exit
fi

if [ "$DOWN_STATUS" = "1" ] ; then
    echo ""
    echo "[ INFO][MIN]TFTP: Download File [OK]"
    upgrade /digicap.dav
    if [ "$?" = "0" ] ; then
        echo ""
        echo "[ INFO][MIN]BURN: Write Flash [OK]"
        echo "***** UPDATE COMPLETE *****"

        echo "***** SYSTEM REBOOT *****"
        if [ "$MS_ACTION" != "auto_updatev2" ] && [ "$MS_ACTION" != "auto_update" ]; then
            reboot
        fi

    else
        echo ""
        echo "[ INFO][MIN]BURN: Write Flash [FAIL] error: write flash."
        echo "!!!!! UPDATE FAIL !!!!!"
    fi
else
    echo "[ INFO][MIN]TFTP: Download File [FAIL] error: tftp."
    echo "!!!!! UPDATE FAIL !!!!!"
fi

That means the bootloader has to be updating the minisys so that's good.

That appears to be correct, judging by these string fragments from mtdblock0
A needed and important safety net ...

***** UPDATE START *****
mImage_g1
info:Download File [OK]
info:Writing Flash
error: check err version12.
[ERROR][BLD]BURN: %s (%d > %d)
error: write flash.
Write Flash [OK]
factory_update
error: upm.
error: upf.
***** UPDATE FAIL *****

 

[watchful_ip]

It's likely possible to add nfs support to the minisys but like you say not really needed. And you can probably just copy files via ssh (not scp) as an alternative.

I might make my own version of minisys once the camera is rooted just for fun. I'll probably be playing with it a fair bit with custom digicap.dav for NFS server support (as opposed to NFS client) so I'd rather minisys do it's TFTP job automatically without me needing to prod it.

A good way to do that it for it to automatically TFTP and reboot unless it finds a specific IP on the network. If it does then it stops and waits for me and I can control that easily with an IP alias on a different host.