I spent (quite) a while last night exploring how to unbrick this Mini PTZ V2 camera and eventually succeeded.
And I'd promised
@pozzello I'd write it up for this forum in response to the challenge that he'd set me.
So - how to cut a long story short? That's not going to happen - as it did take me longer than I thought it would!
Including dealing with a Catch-22 situation where you can have working hardware but no root command access, or root access but only partly working hardware.
It's actually not going to be that short - but hopefully will still be of interest, and maybe even useful, to the techies amongst us.
To recap slightly - the camera was bricked after it accepted a mismatching firmware version. It appeared dead.
But finding and using the serial console connections showed that there was actually a lot of activity.
The kernel was booting OK, but the firmware was falling over in the final stages when starting up the application.
Amboot, the Ambarella bootloader, was fully functional.
Transcripts of initial findings are in the first post of this thread.
In any forensic examination it's good practice to gather as much info as possible before changing anything.
So I was able to use the Amboot 'spinor dump <memory address range>' command to extract in hex form the entire flash storage via a PuTTY logfile.
This was converted into binary and split into the segments corresponding to the 5 flash partitions, the mtdblocks.
mtdblock4 at 16MB, labelled 'lnx', was a jffs2 file system image.
With a bit of trickery this can be mounted on a Linux box after a pseudo mtd device has been created. It yielded a file system that had much of the Linux components present, but none of the application components.
So how to apply the full firmware when there is no web GUI update, and the firmware file is ZIPped with a strong password?
Amboot suggests an upgrade path via a USB device - but that would need special firmware from Huisun.
Mtdblock4 could be cloned from a working copy, given a functional enough root shell access to the kernel.
So I extracted the kernel root hash from my reconstituted mtdblock4 and cracked it very easily.
@pozzello agreed to try, and succeeded, a telnet access to his working Mini PTZ and pulled out a copy of mtdblock4.
That was pretty well done, as he had to set up an NFS share and configure the mount point in the camera.
Having decided on the method, now to finally attempt some changes to implement it.
As it stands, there is no shell access on bootup, the console finally just pops up the same handful of odd characters every few seconds, and no shell prompt is available.
Bootloaders such as U-boot and Amboot pass command-line startup parameters to the Linux kernels they boot.
These are configurable.
The camera was using a standard
"[ 0.000000] Kernel command line: console=ttyS0 root=/dev/mtdblock4 rw rootfstype=jffs2 init=/linuxrc"
which uses the init function of Busybox to process the contents of /etc/inittab to start the system up.
Well - that looks easy!
Just replace "init=/linuxrc" with "init=/bin/sh" and I'll have root shell access so I can re-write mtdblock4.
Sure enough - the device boots eventually to a full root shell.
But - the console shows quite a few differences in getting there.
No network interface - unable to be initiallised. That's a bummer - how to get files in and out?
Problems with the memory manager.
No /proc interface, or a few of the other standard kernel facilities.
In summary, no real facility to be able to bring the mtdblock4 copy in and apply it.
I did at this point insert a Micro-SD card, but trying to access it just gave garbage, and I did not know how to attempt formatting it from the shell.
At this point, what had seemed like it would be straightforward had just receded into the distance.
I tried manually executing the commands in /etc/inittab, and lots of others, but it seemed like the kernel was not functioning properly. No way to configure the network when the hardware apparently does not exist.
Experiments showed that ANY parameters given to the Amboot 'boot' command resulted in only partially working hardware.
I'd speculate that this is an Amboot bug - that a modified boot command is not resetting and initiallising the hardware properly.
I tried all sorts of things and got nowhere.
Definitely a form of Catch-22 situation.
Until -
Finally, I decided to try customising the scripts that /etc/init.d/rcS processes as part of /etc/inittab processing.
I renamed the existing ones out of the way. Anything named S??* gets processed.
Here is what i created, to attempt to get it executed as part of a normal startup, a bit like a trojan horse.
Code:
#!/bin/sh
echo "Just about done"
/sbin/ifconfig
/sbin/ifconfig eth0 192.168.1.131 up
/sbin/route add -net 192.168.1.0 netmask 255.255.255.0 eth0
/sbin/ifconfig
/usr/sbin/telnetd
/bin/mount -t nfs -o nolock 192.168.1.12:/home/alastair/tftp_root /tmp
/bin/cp /etc/inittab /tmp
/bin/ls -al /tmp
#
date >> /etc/init.d/status.log
/sbin/ifconfig >> /etc/init.d/status.log
mount >> /etc/init.d/status.log
ping -c 5 192.168.1.12 >> /etc/init.d/status.log
ls -al /dev/mmc* >> /etc/init.d/status.log
df >> /etc/init.d/status.log
How did I transfer the file?
Just a small amount of trickery - copy the text to the PC clipboard, then at the camera use the echo command pasting the text in:
echo "pasted text from the PC" > S01udev.sh
and the new small text file is created.
chmod +x S01*
and it's ready to use.
And it worked! Mostly.
On bootup, the console still showed the bunches of odd characters every few seconds.
But I could ping the camera.
But there was nothing showing in my tftp_root folder.
Rebooting to to the shell prompt showed that the nfs mount command wasn't working, some bogus error about no known route to host.
But when I rebooted normally again, I did a port scan and saw that telnet was running!
And I could log in via telnet to a root shell, with the cracked root password.
Wow! Home straight here we come.
OK, so manually trying the nfs mount still didn't work.
But with no app running, there is loads of free memory available, so plenty of space to copy in the 16MB mtdblock4 file with
tftp.
Last hurdle in sight!
I issued the oh-so-familiar (from Hikvision) command
cat mtdblock4 > /dev/mtdblock4
"Permission denied - read-only device". Shades of Hikvision NVRs.
OK, so lets try flashcp from the full-fat Busybox that Huisun are using, unlike those skinny Hikvision versions.
flashcp -v mtdblock4 /dev/mtdblock4
"Not an mtdblock flash device"
Hmm... OK, try
flashcp -v mtdblock4 /dev/mtd4
"Erasing flash ....
Writing flash ....."
So it appeared to do what I had so wanted it to do. Dare I reboot? What's it going to do?
Well, I rebooted, and watched with amazement as the camera sitting on the floor with wires sticking out started it's calibration dance. And the console showed so much more activity, apps starting up, video status message etc etc.
It was working!
But I couldn't ping it, or access the web GUI. SADP (amazing how Hikvision-like this camera is) showed it on a foreign IP address - presumably due to something I'd not considered - it was
@pozzello 's configuration in the mtdblock4 he'd sent me.
I changed the PC IP address and was able to get a web GUI logon page. But the default logon credentials didn't work.
I was part way through penning a PM to
@pozzello to ask for his password, and hope it wasn't embarrassing or too rude when I thought it might be worth looking in the config files to see if it was available.
And it was, in plain text! And it worked.
I think that's much more than enough for now.
Thanks for reading.
Footnote : With the cracked linux root password, and the web GUI passwords held in plain text, these cameras are wide open.
