Help identify bricked PTZ camera

just finished teaching a class, heading home and will see if I can get in. I will also put a meter on the pins mentioned earlier to see what they read.

Thanks again!

Brent
 
Thanks VorlonFrog,

Just got the firmware from the vendor. Now I need to review the process for loading the correct firmware back onto the camera.

Thanks again
 
Ok,
I have the camera in uboot. also, I was able to get the firmware from the seller. They sent me two files. One is app.ifu (to be used via IE web gui), and the other is update.bin. They are different than the app.ifu I posted earlier, which is the one that caused the issues in the first place.

I'm confused about the next steps: I downloaded a tftp server, but I'm not sure of the next steps.

Do I need to unpack one of the firmware files, can I tftp a firmware file without unpacking, I'm a little confused, and tired at this point. Way past my bedtime.

Thanks for any quidance, I'm off to bed now to get a few hours sleep before heading to work.

also, here is the output from uboot:

U-Boot 2010.06 (Jun 17 2014 - 10:50:48)


Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
16384 KiB hi_sfc at 0:0 is now current device


## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.0.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2203452 Bytes = 2.1 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK


Starting kernel ...


Uncompressing Linux... done, booting the kernel.




U-Boot 2010.06 (Jun 17 2014 - 10:50:48)


Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
hisilicon #
hisilicon #
hisilicon #
hisilicon #
hisilicon #
hisilicon #
hisilicon #
hisilicon #
hisilicon # ls
Unknown command 'ls' - try 'help'
hisilicon # help
? - alias for 'help'
base - print or set address offset
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
getinfo - print hardware information
go - start application at address 'addr'
help - print command description/usage
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv - set environment variables
sf - SPI flash sub-system
tftp - tftp - download or upload image via network using TFTP protocol
usb - USB sub-system
usbboot - boot from USB device
version - print monitor version
hisilicon # printenv
bootdelay=1
baudrate=115200
ethaddr=00:00:23:34:45:66
bootfile="uImage"
mdio_intf=rmii
bootcmd=sf probe 0;sf read 0x82000000 0x40000 0x240000;bootm 0x82000000
filesize=17DDCC
fileaddr=82000000
netmask=255.255.252.0
ipaddr=192.168.6.99
serverip=192.168.6.10
board=hi3516c
bootargs=mem=66M console=tty,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:256K(boot),2304K(kernel),1536K(rootfs),12288K(data)
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jun 17 2014 - 10:50:48)


Environment size: 506/65532 bytes
hisilicon # help
? - alias for 'help'
base - print or set address offset
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
getinfo - print hardware information
go - start application at address 'addr'
help - print command description/usage
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv - set environment variables
sf - SPI flash sub-system
tftp - tftp - download or upload image via network using TFTP protocol
usb - USB sub-system
usbboot - boot from USB device
version - print monitor version
 
You're in U-boot, and need to use the tftp command (near the end of your 'help' output) to get the camera ready to accept a tftp upload of the new app.ifu file you received. Then use a tftp client program to send the app.ifu file to the camera's IP address. If you're using Windows 7 through Windows 10, it's likely you'll need to "enable Windows features" and enable the TFTP client before it will be available in a DOS/CMD window. In my example command below, the app.ifu file is located in your current directory, and 192.168.1.100 is the IP address of the camera.
Code: 
C:\Users\VorlonFrog\Downloads> [B]tftp[/B]

Transfers files to and from a remote computer running the TFTP service.

TFTP [-i] host [GET | PUT] source [destination]

  -i              Specifies binary image transfer mode (also called
                  octet). In binary image mode the file is moved
                  literally, byte by byte. Use this mode when
                  transferring binary files.
  host            Specifies the local or remote host.
  GET             Transfers the file destination on the remote host to
                  the file source on the local host.
  PUT             Transfers the file source on the local host to
                  the file destination on the remote host.
  source          Specifies the file to transfer.
  destination     Specifies where to transfer the file.

C:\Users\VorlonFrog\Downloads> [B]tftp -i 192.168.1.100 PUT app.ifu[/B]
 
VrolonFrog,
Thanks, I was able to tftp the firmware.

printenv shows the fileaddr and filesize changed after the tftp completed.

I feel like a total noob, and I've read multiple threads, but I don't know what the next step is in the process.

Do I need to move the firmware to a new location on the camera filesystem, extract something, etc. Like I said, I feel like a noob.

Thanks for your help,
Brent
 
In my understanding, no, you should not need to do anything. If the TFTP PUT action succeeded, then the camera should have unloaded the app.ifu file into it's MTD filesystems, then rebooted.
 
Well, I'm not sure what to do next. I could not get the windows10 version of tftp to put the file, but I got the Opentftp server to work, and served up the two files I received from the seller.
I could then issue the tftp <filename> from the uboot console and the file would be transferred successfully. However, it doesn't seem uboot flashed the firmware.
here is the output from the tftp command.

hisilicon # tftp update.bin
Hisilicon ETH net controler
MAC: 00-00-23-34-45-66
UP_PORT : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M
TFTP from server 192.168.1.9; our IP address is 192.168.1.110
Download Filename 'update.bin'.
Download to address: 0x80008000
Downloading: #################################################
done
Bytes transferred = 8138099 (7c2d73 hex)
hisilicon #


Could this firmware files be packaged in such a way that uboot is unable to unpack them? The seller indicated the app.ifu was to be used via the web gui, and the update.bin was to be used by the camera managment utility.

I seem so close, but can't seem to get over this last bump in the road.

Any thoughts are greatly appreciated,
Brent
 
I'm a little lost, because I don't know what the boot log should look like. If you could capture and post that here, it would tell us things like the MTD (flash ram) configuration which is necessary to understand where things should be written. It would also help more experienced users like fenderman, bp2008, and others understand more about this camera.
 
Here is the boot log from a power down/restart:

U-Boot 2010.06 (Jun 17 2014 - 10:50:48)


Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
16384 KiB hi_sfc at 0:0 is now current device


## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.0.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2203452 Bytes = 2.1 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK


Starting kernel ...


Uncompressing Linux... done, booting the kernel.
ø
ipc login:


I'm reading lot of other threads, so I might run across something similar. Getting ready to build an ubuntu VM and start playing around/learning binwalk to poke around in the firmware files the vendor sent me.

Stupid mistake to try to update the firmware in the first place, but I've learned a good bit over the past few days on how these cameras work.

Thanks again,
Brent
 
You can probably get a little more relevant info/experience by reading Sergei's blog, especially this post. So, the fact you're getting the 'ipc login:' prompt is good. Have you tried logging in using either of the two username/password combinations I previously provided?

admin/123456
HANKVISION/HANKVISION

If you can get a login using either of those, then you can do almost anything. The U-boot prompt 'Hisilicon #' is also another excellent sign. So, if/when you can login, use the dmesg command to dump the full boot log. It looks like they're not outputting it to the console by default. :(

Attached is a dump of the app.ifu file you provided a few days ago. After the ASCII text, there are hex bytes <FD><37><7A><58><5A> that signal the beginning of an XZ compressed blob. This will be recognized by the binwalk program. If you uncompress this XZ blob, you get a tar archive of the Linux filesystem. The 7-Zip tool can decompress/unload both the XZ and tar formats.

app_ifu_dump.png
 
Last edited by a moderator:
I've tried every IP camera username/password I can find, but nothing has let me in yet, including the ones you listed.
I will try some of his tips in the blog. I actually hit his page last night when I google the root entry on the /etc/passwd file from the extracted firmware. The camera he was tinkering with had the same hashed password, but I don't think he cracked it.

I used the binwalk -Mer <filename> to explode the firmware file. That command unpacked the entire structure in a subdirectory, including the tar archives contained in the firmware file.

The only difference I can find between the two firmware files that were sent by the vendor is the top level tar archive. in the app.ifu, the tar file is named 54, in the update.bin it is CB.
The bad app.ifu I originally loaded also has a 54 at the top level. the rest of the bad app.ifu archive has some differences compared to the vendor supplied app.ifu.

still poking around and learning.
 
Your printenv output above included the bootargs variable:

bootargs=mem=66M console=tty,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:256K(boot),2304K(kernel),1536K(rootfs),12288K(data)

Taking a cue from Sergei's blog, you could add the init=/bin/sh to the end of it:

bootargs=mem=66M console=tty,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:256K(boot),2304K(kernel),1536K(rootfs),12288K(data) init=/bin/sh

and have a root shell prompt upon boot completion. :)
 
@nayr Not sure why and I am not trying to be rude to the OP but why do people always insist on having the most up to date firmware. If it works good for you now, why change it. People don't update to a new version of windows every time it comes out...
 
Last edited by a moderator:
pal251 said:
@nayr Not sure why and I am not trying to be rude to the OP but why do people always insist on having the most up to date firmware. If it works good for you now, why change it. People don't update to a new version of windows every time it comes out...
Click to expand...

I don't know what to say.. you're really telling everybody not to update any device if it works OK?
New releases can have bug fixes, new features, security patches, heating fixes etc.. etc..
Your device might be working as expected, but might still have issues.

People should always update to new versions if possible. Doesn't mean people should blindly update.
And also make sure you're updating the device with appropriate files for that particular device.
 
I'm just hoping vmsguy/Brent had some measure of success with his camera last night. I'm still interested in seeing the 'dmesg' output from this camera. The partition information from the BOOTARGS variable is helpful, but there's nothing like actual output for reference.
 
pal251 said:
@nayr Not sure why and I am not trying to be rude to the OP but why do people always insist on having the most up to date firmware. If it works good for you now, why change it. People don't update to a new version of windows every time it comes out...
Click to expand...
@pal251, maybe a bit of background on my motives will help. I've been an IT professional since 1984 starting with Digital Equipment Corporation, and have always liked to tinker with things. I take DSLRs apart to remove filters to make them more sensitive to do astrophotograpy, converting old Philips based CCD web cams to do long exposure by adding a logic chip, cutting traces, and lifting pins on the control chip to control exposure length, building arduino kits, flashing new builds where I tweaked some code, playing around building scratch built quad copters using different flight control boards, etc. I'm curious and like to see how things work. I purchased this camera to play with PTZ features but it didn't have any motion detection setting, so I went looking for a firmware update. I made the choice to roll the dice on firmware that matched the model number and had just been released on another site. My mistake, but I knew the possbility of bricking the camera and I made that choice to go ahead. I'm usually quite successful in my tinkering adventures, but I do have a drawer of "spare parts" from some failures.

In hindsight, by bricking the camera, I have learned a great deal on how these things work, and picked up some new skills along the way. I don't recommend people go wild and try to apply any software update unless it has been tested and stable, especially in production/critical applications. Tinkering with cameras is a hobby for me, so I take chances, and sometimes I pay the price of having a non-usable device.

I'm still hopeful that I can recover this camera, and in doing so will have gained significant insight on how they work.

and BTW, I didn't take your comment as being rude, but I just wanted to give you some insight on to why I would go down the path of updating with unproven/unknown firmware in the first place.
Brent
 
Last edited by a moderator:
VorlonFrog said:
I'm just hoping vmsguy/Brent had some measure of success with his camera last night. I'm still interested in seeing the 'dmesg' output from this camera. The partition information from the BOOTARGS variable is helpful, but there's nothing like actual output for reference.
Click to expand...

No luck yet. If I add the init=/bin/sh to the bootargs in u-boot, then boot the camera, it boots, but I do not get a root shell, and the telnet port is no longer active, so it apparently doesn't like the init=/bin/sh. For the heck of it, I tried init=/bin/bash and the camera booted as though no init param was added. I'm running john the ripper now on the passwd file. The passwd file is the same on both the "bad" firmware and the new firmware supplied by the vendor. We will see in a couple days/weeks if I can crack the root password. If I can get in via telnet, I should be able to figure out what is going on.

Brent
 
You must log in or register to reply here.
Top Bottom