We break and restore the 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 by the organization, so that there were no excesses between employees and visitors under the supervision of a big brother.
Not to say that everything was good ... Everything was average. And it seemed to us that the software update of cameras could improve something. It turned out that some models of Falcon Eye, Tenvis, Foscam and, perhaps, some other companies almost coincide. Somewhere buttons more conveniently, somewhere the interface Russian is. And we decided!
Updated software cameras on a similar model from the Tenvis TR3818. Then they read it and decided that it was possible to upgrade to a steeper firmware from another camera.
After the update, the camera ordered to live long. Checking the motors when turned on did not occur, the speakers did not rustle, the LED did not blink. Only the LED on the LAN interface was on, and when turned on, a single broadcast packet was leaving.
')
After such an incident, the rest of the cells were hung in places, and the “brick” moved to live with us. From time to time there were attempts to reanimate it. The camera was disassembled, found a site where you can solder for access through the console.
(there are 3.3V, GND, TX, RX markings under the wires)
(camera board assembly)
I had to take a USB-TTL converter.
(there is a contact)
Connect to the console via putty or HyperTerminal and see the following:
Bad, says you have a magic number. And he doesn’t want to react to my choice of any other menu item. This was completed the first approach to the camera and she returned to the shelf in the department.
Having gained strength, we made another approach. I had to spend my nerves to understand that it was in our case that the RX converter should be connected to the RX cameras, and the TX to the TX. Either the marking was incorrectly applied or one of the two. The camera began to respond to the choice of menu items, but this did not explain the nature of the magic numbers.
Then the firmware for Tenvis TR3818 and several firmware for similar cameras were downloaded, a tftp-server was configured and item 4 was selected, the entrance to the command interface. Actually, by ? gives us a list of possible commands, where we find tftpboot - which loads the file from tftp into memory and bootm - which loads the application from memory.
The procedure is as follows:
And the results were as follows:
I hope this is much more interesting and less tedious to read than switching wiring, shoveling the Internet and calculating offsets, restoring the logic of the work of Chinese genius. Perhaps this should teach us the next time to refrain from thoughtless firmware technology than got.
And thank you! If it were not for the desire to please Habr, perhaps this camera would have stood in our department for a long time.
Not to say that everything was good ... Everything was average. And it seemed to us that the software update of cameras could improve something. It turned out that some models of Falcon Eye, Tenvis, Foscam and, perhaps, some other companies almost coincide. Somewhere buttons more conveniently, somewhere the interface Russian is. And we decided!
Updated software cameras on a similar model from the Tenvis TR3818. Then they read it and decided that it was possible to upgrade to a steeper firmware from another camera.
After the update, the camera ordered to live long. Checking the motors when turned on did not occur, the speakers did not rustle, the LED did not blink. Only the LED on the LAN interface was on, and when turned on, a single broadcast packet was leaving.
')
After such an incident, the rest of the cells were hung in places, and the “brick” moved to live with us. From time to time there were attempts to reanimate it. The camera was disassembled, found a site where you can solder for access through the console.
(there are 3.3V, GND, TX, RX markings under the wires)
(camera board assembly)
I had to take a USB-TTL converter.
(there is a contact)
Connect to the console via putty or HyperTerminal and see the following:
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
Bad, says you have a magic number. And he doesn’t want to react to my choice of any other menu item. This was completed the first approach to the camera and she returned to the shelf in the department.
Having gained strength, we made another approach. I had to spend my nerves to understand that it was in our case that the RX converter should be connected to the RX cameras, and the TX to the TX. Either the marking was incorrectly applied or one of the two. The camera began to respond to the choice of menu items, but this did not explain the nature of the magic numbers.
Then the firmware for Tenvis TR3818 and several firmware for similar cameras were downloaded, a tftp-server was configured and item 4 was selected, the entrance to the command interface. Actually, by ? gives us a list of possible commands, where we find tftpboot - which loads the file from tftp into memory and bootm - which loads the application from memory.
The procedure is as follows:
- load the firmware into the camera via tftpboot
- run the bootm command
- We look at the result, think it over.
And the results were as follows:
- On the firmware of similar cameras - the magic number does not match
- On Tenvis TR3818 firmware
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 learned the magic number, but only here 110 KB and this is the firmware of the bootloader, and the firmware file is 7 MB) - We are trying to feed the entire firmware file as a boot loader update (item 9 in the menu) - it swears at a file that is too large. Browse the file with Frhed and see that the magic number is at the very beginning of the file. And since we know that the size of the loader is 112920 bytes + 64 bytes is the size of the header, then we copy 112984 bytes into a separate file, feed the camera through 9 menu items and rejoice in the updated loader.
- Inspired by the success, we are looking for a repetition of the magic number 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 .
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
(The number came together, the size is known, we load it as it is through the 2nd menu item and we see what is written to the memory at offset 0x30000, and when the camera starts, it accesses 0xE0000, that is, we miss by 0xB0000 bytes past the magic number) - So we take another 0xB0000 byte of data before the magic number from the file with Tenvis firmware. Fill through the 2nd menu item and the camera comes to life!
I hope this is much more interesting and less tedious to read than switching wiring, shoveling the Internet and calculating offsets, restoring the logic of the work of Chinese genius. Perhaps this should teach us the next time to refrain from thoughtless firmware technology than got.
And thank you! If it were not for the desire to please Habr, perhaps this camera would have stood in our department for a long time.
Source: https://habr.com/ru/post/335810/
All Articles