0

I started reversing this camera in order to get rid of the unwanted traffic it constantly does towards Chinese servers.
I have a serial access to it thanks to an obvious UART port (bottom left in the picture).
camera board The camera is based on a Hi3518 chip and runs Huawei LiteOS 1.4.5:

SPI Nor(cs 0) ID: 0xef 0x60 0x17
Block:64KB Chip:8MB Name:"W25Q64FW"
SPI Nor total size: 8MB


********hello Huawei LiteOS ARM926********

version : Huawei LiteOS V200R001C10B017
open-version : Huawei LiteOS 1.4.5
build data : May  2 2018 19:06:05

**********************************
********Hello Huawei LiteOS********

version : Huawei LiteOS V200R001C10B017
open-version : Huawei LiteOS 1.4.5
build data : May  2 2018 19:06:05

********
Huawei LiteOS # Spi Nor ID:0xEF 0x60 0x17 0x00 0x00 0x00 0x00 0x00
Spi Nor Flash Info:
Name:"W25Q64FW" Size:8MB Block:64KB
osal_proc_mkdir - parent is NULL! proc=0x80976bd0
<6>Hisilicon Media Memory Zone Manager

And once started it does not give a typical /bin/sh to the console, but instead a custom made CLI they call a shell. Here are the commands that this "shell" has:

Huawei LiteOS # help                                                            
*******************shell commands:*************************                     
                                                                                
ap_test       armbenv       arp           call          cat           cat_logmpp
    cd            cp                                                            
cpup          debug         dns           excInfo       findsym       format    
    free          help                                                          
hiddrs        himd          himm          hwi           i2c_read      i2c_write 
    ifconfig      lddrop                                                        
local_alarm   ls            mclose        memcheck      mkdir         mopen     
    mount         msgqueue                                                      
nand_bad      netstat       ntpdate       partinfo      partition     ping      
    pwd           readreg                                                       
reset         rm            rmdir         sem           sendbps       shutdown  
    sleep_device  ssp_read                                                      
ssp_write     sta_test      statfs        swtmr         sync          systeminfo
    task          telnet                                                        
tftp          touch         uart_close    uart_config   uart_read     uart_write
    umount        uname                                                         
writeproc     writereg      

Note those commands are functions from this custom CLI, not actual UNIX/Linux/busybox commands.

Those are documented, as is the whole LiteOS SDK, in a pretty well put documentation available on their Github, but nothing really give access to the underlying Linux system, unlike many Hi35xx based devices, looks like their build is configured with this shell enabled.

The most annoying thing is that they also seem to have disabled U-Boot access, even trying to brute force a keystroke during power up doesn't do anything. Nevertheless I think U-Boot is looking for something on the SD-Card as it initializes the SD slot when the camera is powered on with the reset button pressed:

Block:64KB Chip:8MB Name:"W25Q64FW"
SPI Nor total size: 8MB

EMMC/MMC/SD controller initialization.
MMC/SD Card:
    MID:         0x3
    Read Block:  512 Bytes
    Write Block: 512 Bytes
    Chip Size:   60906M Bytes (High Capacity)
    Name:        "SD64G"
    Chip Type:   SD
    Version:     2.0
    Speed:       25000000Hz
    Bus Width:   4bit
    Boot Addr:   0 Bytes
Interface:  MMC
  Device 0: Vendor: Man 035344 Snr e2cf5b82 Rev: 8.5 Prod: SD64G
            Type: Removable Hard Disk
            Capacity: 60906.0 MB = 59.4 GB (124735488 x 512)
Partition 1: Filesystem: FAT32 "NO NAME    "

I tried to copy the obvious, uImage, update/uboot etc... doesn't trigger anything.

I also tried to overflow the shell commands, messing with /jffs0/etc/init.d/rcS, nothing worked so far.

I'd be very happy with some fresh ideas I didn't try yet!

Edit

The flash serving as block device is a W25Q64.W, I dumped it using a brand new CH341a and a test clip, first time I did this, very cool. Now I have this dump but the binwalk analysis doesn't look promising:


DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
102060        0x18EAC         CRC32 polynomial table, little endian
5767168       0x580000        JFFS2 filesystem, little endian
6512540       0x635F9C        gzip compressed data, from Unix, last modified: 1970-01-01 00:00:00 (null date)
6512780       0x63608C        JFFS2 filesystem, little endian
6512968       0x636148        Zlib compressed data, compressed
6513460       0x636334        Zlib compressed data, compressed
6513640       0x6363E8        gzip compressed data, from Unix, last modified: 1970-01-01 00:00:00 (null date)
[hundreds of lines of those]
8257536       0x7E0000        JFFS2 filesystem, little endian

Here's the entropy graph binwalk entropy graph which seems to indicate a huge chunk of the firmware is either encrypted of compressed.

7
  • 1
    No way to pull a flash dump of the bootflash in some way? Boot log tells that there is some sort of SPI flash on the board. Post a pic of the board backside, too if possible
    – masterX244
    Feb 9 at 9:19
  • Yes that's exact;y what I ordered, will update the post if I get further, thanks!
    – iMil
    Feb 9 at 13:16
  • Picture of reverse side of the PCB should be quick to do though since you only need to unscrew the 4 corner screws and then make the picture of whats at the back of the board. Knowing if there is useful stuff there helps massively
    – masterX244
    Feb 9 at 13:43
  • 1
    would be interested if this goes any further as I'm working on a xshcam doorbell running the same OS (Huawei liteOs 1.4.6). Block:64KB Chip:8MB Name:"W25Q64FW" SPI Nor total size: 8MB Camera OV9732 I can Uboot but doesn't help if there are proprietary blobs for the drivers for camera module and wifi etc..
    – tv athome
    Mar 16 at 16:11
  • Linux kernels are usually compressed and get uncompressed by a small stub. Possible to share the flashdump? Also: JFFS2 allows compressed files, too.
    – masterX244
    Mar 17 at 8:27

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy