Breaking and restoring a Chinese IP camera

    This story began more than a year ago, when several relatively cheap Chinese Falcon Eye FE-MTR300 P2P IP cameras were purchased at the organization so that there would be no excesses between employees and visitors under the supervision of a big brother.

    image

    Not to say that everything was good ... Everything was average. And it seemed to us that updating the camera software could improve something. It turned out that some models of Falcon Eye, Tenvis, Foscam and, possibly, some other companies almost coincide. Somewhere the buttons are more comfortable, somewhere the Russian interface is. And we decided!

    Updated camera software for a similar model from Tenvis TR3818. Then they read more and decided that it is possible to upgrade to a steeper firmware from another camera.

    After the update, the camera ordered a long life. The motors did not check when turned on, the speakers did not rustle, the LED did not blink. Only the LED on the LAN interface was on, and when it was turned on, a lone broadcast packet was leaving.

    After such an incident, the rest of the cameras were hung in their places, and the “brick” moved to live with us. From time to time there have been attempts to resuscitate him. The camera was disassembled, platforms were found where you can solder for access through the console.

    image
    (there is 3.3V, GND, TX, RX marking under the wires)

    image
    (camera circuit board assembly)

    I had to take a USB-TTL converter.

    image
    (there is a contact) We

    connect to the console through putty or HyperTerminal and see the following: Bad, says you have a magic number. And he does not want to react to my choice of any other menu item. This completed the first approach to the camera and she returned to the shelf in the department.
    U-Boot 1.1.3 (Aug 26 2014 - 17:15:00)

    Board: Ralink APSoC DRAM: 16 MB
    relocate_code Pointer at: 80fb0000
    spi_wait_nsec: 42
    spi device id: c2 20 17 c2 20 (2017c220)
    find flash: MX25L6405D
    raspi_read: from:2b000 len:1000
    .raspi_read: from:2b000 len:1000
    .============================================
    Ralink UBoot Version: 3.6.0.0
    --------------------------------------------
    ASIC 5350_MP (Port5<->None)
    DRAM_CONF_FROM: Boot-Strapping
    DRAM_TYPE: SDRAM
    DRAM_SIZE: 128 Mbits
    DRAM_WIDTH: 16 bits
    DRAM_TOTAL_WIDTH: 16 bits
    TOTAL_MEMORY_SIZE: 16 MBytes
    Flash component: 8 MBytes NOR Flash
    Date:Aug 26 2014 Time:17:15:00
    ============================================
    icache: sets:256, ways:4, linesz:32 ,total:32768
    dcache: sets:128, ways:4, linesz:32 ,total:16384

    ##### The CPU freq = 360 MHZ ####
    estimate memory size =16 Mbytes
    raspi_read: from:80028 len:6
    .
    start time:31742632l
    File: cmd_net.c, Func: do_my_tftpb, Line: 69

    netboot_common, argc= 3

    NetTxPacket = 0x80FE3C80

    KSEG1ADDR(NetTxPacket) = 0xA0FE3C80

    NetLoop,call eth_halt !

    NetLoop,call eth_init !
    Trying Eth0 (10/100-M)

    Waitting for RX_DMA_BUSY status Start... done

    Header Payload scatter function is Disable !!

    ETH_STATE_ACTIVE!!
    Using Eth0 (10/100-M) device
    TFTP from server 51.204.51.204; our IP address is 192.168.1.5
    Filename 'xx.img'.

    TIMEOUT_COUNT=10,Load address: 0x80100000
    Loading: ====================broadcast get file
    T ====================broadcast get file

    could not get file, cancel update
    ret = 1

    Please choose the operation:
    1: Load system code to SDRAM via TFTP.
    2: Load system code then write to Flash via TFTP.
    3: Boot system code via Flash (default).
    4: Entr boot command line interface.
    7: Load Boot Loader code then write to Flash via Serial.
    9: Load Boot Loader code then write to Flash via TFTP.

    You choosed 3
    0

    3: System Boot system code via Flash.
    ## Booting image at bc0e0000 ...
    raspi_read: from:e0000 len:40
    .Magic Number,85190320
    Bad Magic Number,85190320



    Gaining strength, we took another approach. I had to spend my nerves to understand that it is in our case that the RX converter must be connected to the RX camera, and TX to TX. Either the marking was incorrectly applied or one of two. The camera began to respond to the choice of menu items, but this did not explain the nature of magic numbers.

    Then the firmware for Tenvis TR3818 and several firmware for similar cameras were downloaded, a tftp server was configured and item number 4 was selected, the entrance to the command interface. Actually, by ? we get a list of possible commands, where we find tftpboot - which loads the file with tftp into memory and bootm - which loads the application from memory.

    The procedure is as follows:

    • download the firmware to the camera via tftpboot
    • run the bootm command
    • We look at the result, consider it.

    And the results were as follows:

    • On the firmware of similar cameras - the magic number does not match
    • On the firmware from Tenvis TR3818 (We recognized the magic number, but only here is 110 KB and this is the bootloader firmware, and the firmware file is 7 MB)
      RT5350 # bootm
      ## Booting image at 80100000 ...
      Magic Number,27051956
      Image Name: SPI Flash Image
      Created: 2014-11-26 6:26:49 UTC
      Image Type: MIPS Linux Standalone Program (uncompressed)
      Data Size: 112920 Bytes = 110.3 kB
      Load Address: 80200000
      Entry Point: 80200000
      Verifying Checksum ... OK
      OK

    • We are trying to feed the entire firmware file, like updating the bootloader (item 9 in the menu) - swears at a too large file. We look at the file with Frhed and see that the magic number is at the very beginning of the file. And since we know that the bootloader size is 112920 bytes + 64 bytes the size of the header, we copy 112984 bytes into a separate file, feed it to the camera through 9 menu items and enjoy the updated bootloader.
    • Inspired by success, we look for a magic number repetition in the firmware file and find the same header in the firmware file at 0xE0000, but only with Linux Kernel Image. We copy everything from it to the end of the file into a separate file and try to check through tftpboot and bootm . (The number has come together, the size is known, we load it as it is through the 2nd menu item and we see that it is written to memory at an offset of 0x30000, and when the camera starts, it turns to 0xE0000, i.e. we miss 0xB0000 bytes by the magic number)
      RT5350 # bootm
      ## Booting image at 80100000 ...
      Magic Number,27051956
      Image Name: Linux Kernel Image
      Created: 2014-11-26 6:26:54 UTC
      Image Type: MIPS Linux Kernel Image (lzma compressed)
      Data Size: 1065116 Bytes = 1 MB
      Load Address: 80000000
      Entry Point: 80347000
      Verifying Checksum ... OK
      Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover

    • So we take another 0xB0000 bytes of data from the file with the firmware from Tenvis before the magic number. Fill through the 2nd menu item and the camera comes to life!

    I hope this is much more interesting and less tiring to read than switching wiring, shoveling the Internet and calculating offsets, restoring the logic of the work of the Chinese genius. Perhaps this should teach us the next time to refrain from rash firmware firmware than anything.

    And thank you! If it were not for the desire to please the Habr, perhaps this camera would have stood in our department for a long time.

    Also popular now: