Available on AliExpress, the 360Eyes Pro (also known as IPC365, from the default network host name of this camera) is a cheap wireless CCTV camera supporting night vision and RTSP. I bought mine for around 18 USD, shipping included:
Despite looking very similar to the V380 Pro which has 10 IR LEDs, this camera has only two. Nevertheless, night vision is still satisfactory. Configuration is also done via a mobile app, with the camera serving an open adhoc wireless network during the initial phase. Unlike the V380 Pro which requires copying a file to the SD card, RTSP on the ICP365 can be easily enabled from the mobile app, and the default RTSP URL is
As with most cheap security cameras, it would be wise to configure the router to prevent the camera from accessing the Internet. For the IPC365 camera, this would also prevent the live footage from being viewed via the mobile app, which attempts to retrieve the footage from their cloud server, instead of from the camera directly. This does not bother me as I always view the live footage via RTSP and only use the mobile app for initial configuration. Allowing any cameras to upload footage to some unknown server is a serious security risk and should be avoided at all costs. Interestingly, there is a CR2032 battery on the camera board so the system time is always preserved as long as the battery is good regardless of whether the NTP server is accessible. The battery is highlighted in red in the photo below:
There is a serious issue with the RTSP implementation on this camera caused by a typo before the ssrc parameter during the RTP setup phase. The following is the data sent by the camera:
Notice the comma before ssrc which should have been a semicolon. The correct data should have been:
The above typo prevents the camera from being used in iSpy or FFmpeg but HappyTime RTSP client has no issues. VLC has no issues playing back the video, but does not split the recorded files properly when used on the iPC365’s RTSP stream. This issue prevented me from using my Raspberry Pi with FFmpeg to remotely capture the camera video footage, and I decided to spend some time finding a solution.
My specific unit uses the Ingenic MIPS T10 camera board that runs on a W25Q64FV 8MB flash chipset and has a specific model number of EC79A-S12 printed at the back. The board has unmarked (but easy to identify) RX/TX/GND pins for a 115200bps serial port connection. After a few minutes of soldering, I was quickly able to connect the board to my PC and access the u-boot menu via Putty. Although there is no firmware dump option in the menu, the objective can be achieved by using sf read and md commands that dump the memory contents as hex and by writing codes to parse the hex dump and write the content back to a binary file. The whole process took around three hours and I was able to retrieve the original firmware as a binary file!
The exact firmware size is 8,388,608 bytes (8MB), divided into 8 partitions, listed in the order they appear in the flash memory dump:
- Boot partition (524,288 bytes)
- Kernel partition (1,638,400 bytes)
- Root partition (2,883,584 bytes)
- User partition (1,572,864 bytes)
- Web partition (851,968 bytes)
- MTD partition (917, 504 bytes)
The Root, User and Web partitions use SquashFS filesystem and can be extracted with unsquashfs. The embedded web and RTSP server is run from the bin/Alloca file on the User partition. The bug can be fixed by searching for ,ssrc in that file and replacing suitable occurrences with ;ssrc like below:
On my unit, telnet is disabled but can be enabled by editing /etc/init.d/rcS on the root partition and uncomment the call to telnetd:
I also took the opportunity to show a login prompt on the serial interface by modifying /etc/inittab and add a call to getty:
With this, I can login normally via Putty through the serial connection. The default account is root with empty password, but you might also want to update /etc/passwd and set the value you want.
After all modifications, use mksquashfs with the xz compression parameter to regenerate the firmware file. To be extra careful, study the original firmware dump and try to match the format as closely as possible. If the generated file is smaller than the original firmware file, pad it with zero to match the original file size. You should only be modifying the Root and the User partitions. Once done, transfer the firmware files to the device and use sf update to write the updated firmware files, one at a time. To do so, configure u-boot to receive files in YMODEM mode and use something like ExtraPuTTY to send the binary files. Although u-boot on this board supports Kermit, attempting to send/receive via Kermit would always result the received file being a few kilobytes smaller in size, regardless of which software I used. In the end, YMODEM is the only protocol that worked well.
Take note to only update the required partitions and leave other partitions untouched. In particular, the Boot and the Kernel partitions contain the u-boot code. If these partitions are damaged and the u-boot menu is inaccessible, the only fix is to unsolder the chips and manually flash the firmware. If this happens, you might as well buy a new camera. Remember to use sf update and not sf write. The latter will appear to write data successfully but will only cause the board to end up in an infinite reboot loop – I wasted 2 days on that!
After successfully flashing, the camera should reboot normally and telnet should now be accessible. RTSP will now work with most software including FFmpeg and iSpy. If you prefer, you might also want to find some simple HTTP/FTP server code, compile for MIPS and embed in the firmware to offer HTTP download and FTP functionality. The only other thing I do not like about this camera is the fact that recorded videos are not timestamped, which result in waste of resources on my Raspberry Pi trying to re-encode the video with the correct timestamps. Wireless reception can be weak at times, but this might just be due to my particular environment. Long story short, this camera is good to play with since it offers the possibility of flashing custom firmware via u-boot. To this end, I like the IPC365 even more than the V380 as I just couldn’t find any way to access the V380 firmware because its board does not contain any easy to identify serial connection pins.
The original dump, modified firmware and some C# code I write to help with the memory dump can be downloaded here for those who are interested.