Asecam / Jieuno (fullhan / vatilon) integration
Hello, I would like to help / provide some small info for cameras.
SoC of my cameras is fh8856v200 or fh8856/IF56N
There is my repo with extracted partitions, etc: https://github.com/mtrakal/ipc-vatilon
I'm not able to help with integration itself, but if you will need anything get from cameras or be a beta tester with firmware I can be that person :).
I still didn't catch network traffic / didn't try to / while upgrading FW, so I don't know process how camera is possible to flash firmware without uboot / uart usage. It's not possible in camera UI itself, but possible by some external tool. But it's work for some of next days for me, if I'll have some time :)
I have a number of the ASECAM Vatilon PB1 cameras. They can be affected by something on the network that causes them to all reboot at once. This can continue for some time, all rebooting regularly. I am willing to assist where I can. I upgraded the firmware using the Windows tool. It didn't help with the reboots but it may be the way to install alternative firmware.
I have a number of the ASECAM Vatilon PB1 cameras. They can be affected by something on the network that causes them to all reboot at once. This can continue for some time, all rebooting regularly. I am willing to assist where I can. I upgraded the firmware using the Windows tool. It didn't help with the reboots but it may be the way to install alternative firmware.
In the camera WebGui is possible to setup autoreboot. Maybe you have it enabled? I have no issue with reboots of camera when this settings is disabled. But I have it enabled to reboot once per day to cleanup possible FW memleaks, sync time again, etc.
No, it's not set to auto-reboot. I can crash all the cameras together if I use wsdd on the same network.
On Fri, 29 Nov 2024, 7:44 am Matej Trakal, @.***> wrote:
I have a number of the ASECAM Vatilon PB1 cameras. They can be affected by something on the network that causes them to all reboot at once. This can continue for some time, all rebooting regularly. I am willing to assist where I can. I upgraded the firmware using the Windows tool. It didn't help with the reboots but it may be the way to install alternative firmware.
In the camera WebGui is possible to setup autoreboot. Maybe you have it enabled? I have no issue with reboots of camera when this settings is disabled. But I have it enabled to reboot once per day to cleanup possible FW memleaks, sync time again, etc.
image.png (view on web) https://github.com/user-attachments/assets/32aa564c-4c76-4f30-bf07-61cf1c37d30f
— Reply to this email directly, view it on GitHub https://github.com/OpenIPC/firmware/issues/1610#issuecomment-2506781236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVMWCQQBVC2ZOI2M2UD2C6FFJAVCNFSM6AAAAABSE5CH7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBWG44DCMRTGY . You are receiving this because you commented.Message ID: @.***>
I upgraded the firmware using the Windows tool. It didn't help with the reboots but it may be the way to install alternative firmware.
Yeah, I already caught FW upgrade packets, but it's a bit useless because it's encrypted. So App and Cam changed the keys and session and encrypted the rest of the communication. So until we know the algorithm and how the key is build, we are lost I think this simple way for upgrade FW, but we have 2 others ⏬.
Discover camera is based on Broadcast on Network L2 (ARP broadcast on same network area):
{
"DeviceType": "IPC",
"ChannelNum": 1,
"DeviceModel": "PB4",
"DeviceModel2": "PB",
"DeviceName": "PB4",
"CloudID": "__CLEARED__",
"SerialNo": "__CLEARED__",
"NetType": 1,
"MAC": "__CLEARED__",
"DHCP": 0,
"Address": "10.0.0.33",
"Submask": "255.255.255.0",
"GateWay": "10.0.0.254",
"DNS": "10.0.0.252",
"TCPPort": 8600,
"RTSPPort": 554,
"HTTPPort": 80,
"Language": "English",
"SoftwareVersion": "V1.13.23-20240524",
"DeviceRunTime": 78,
"QWTEnable": false,
"IPAdaptive": 1,
"LampType": 1,
"DayNightSwitch": 0,
"P2PType": 4,
"P2PPID": "__CLEARED__",
"P2PQRCode": "__CLEARED__",
"LensCount": 1,
"StreamCount": 2,
"StreamNumPerChannel": 2,
"NetTypeSet": 1,
"NetProtocolSet": 143,
"Status": 2,
"Version": 1,
"Scode": "__CLEARED__"
}
After that application sends UDP packet to camera IP address with body:
{
"operation": "login",
"param": {
"user": "JmsRxTtVEW+J5da5aSt3lw==",
"password": "bC+UKGMPDDiynIUE9ViJzw==",
"heartbeat_timeinterval": 1,
"heartbeat_timeoutcounts": 3,
"sessionid": 179511328,
"encryptionkey": "EOtDcH4DFPJZj2CDhLFNAg==",
"roletype": 5
}
}
So we know, that decrypted user = admin and password = 123456.
Response is:
{
"operation": "login_response",
"code": 0,
"msg": "successful ",
"sessionid": 179511328,
"encryptionkey": "HO55v18ZnC9cL6pJe0U9Tg=="
}
And the rest is encryped with new key.
But we already have ROOT access to telnet, so I don!t think, that we need use standard way how to upgrade firmware, when you can (I supose) re-mount partition as write or use dd to rewrite flash memory. Not sure, but expecting, that with root bash / bussybox it is possible.
And second tested variant - the author of articles on Reddit already used UART and flash his own custom FW (changed default password to telnet with custom one). So flash new FW is not the main problem I think :)
I opened one up and took some pics. Trouble is, after I checked the chip numbers I didn't get a pic of the camera chip. Only the flash and ethernet. I've ordered a new one to have a decent look around inside.
On Sat, 30 Nov 2024, 8:03 am Matej Trakal, @.***> wrote:
I upgraded the firmware using the Windows tool. It didn't help with the reboots but it may be the way to install alternative firmware.
Yeah, I already caught FW upgrade packets, but it's a bit useless because it's encrypted. So App and Cam changed the keys and session and encrypted the rest of the communication. So until we know the algorithm and how the key is build, we are lost I think this simple way for upgrade FW, but we have 2 others ⏬.
Discover camera is based on Broadcast on Network L2 (ARP broadcast on same network area):
{ "DeviceType": "IPC", "ChannelNum": 1, "DeviceModel": "PB4", "DeviceModel2": "PB", "DeviceName": "PB4", "CloudID": "CLEARED", "SerialNo": "CLEARED", "NetType": 1, "MAC": "CLEARED", "DHCP": 0, "Address": "10.0.0.33", "Submask": "255.255.255.0", "GateWay": "10.0.0.254", "DNS": "10.0.0.252", "TCPPort": 8600, "RTSPPort": 554, "HTTPPort": 80, "Language": "English", "SoftwareVersion": "V1.13.23-20240524", "DeviceRunTime": 78, "QWTEnable": false, "IPAdaptive": 1, "LampType": 1, "DayNightSwitch": 0, "P2PType": 4, "P2PPID": "CLEARED", "P2PQRCode": "CLEARED", "LensCount": 1, "StreamCount": 2, "StreamNumPerChannel": 2, "NetTypeSet": 1, "NetProtocolSet": 143, "Status": 2, "Version": 1, "Scode": "CLEARED" }
After that application sends UDP packet to camera IP address with body:
{ "operation": "login", "param": { "user": "JmsRxTtVEW+J5da5aSt3lw==", "password": "bC+UKGMPDDiynIUE9ViJzw==", "heartbeat_timeinterval": 1, "heartbeat_timeoutcounts": 3, "sessionid": 179511328, "encryptionkey": "EOtDcH4DFPJZj2CDhLFNAg==", "roletype": 5 } }
So we know, that decrypted user = admin and password = 123456.
Response is:
{ "operation": "login_response", "code": 0, "msg": "successful ", "sessionid": 179511328, "encryptionkey": "HO55v18ZnC9cL6pJe0U9Tg==" }
And the rest is encryped with new key.
But we already have ROOT access to telnet, so I don!t think, that we need use standard way how to upgrade firmware, when you can (I supose) re-mount partition as write or use dd to rewrite flash memory. Not sure, but expecting, that with root bash / bussybox it is possible.
And second tested variant - the author of articles on Reddit https://www.reddit.com/r/hardwarehacking/comments/1cuu1wf/hacking_an_asecam_ip_camera_part_1/ already used UART and flash his own custom FW (changed default password to telnet with custom one). So flash new FW is not the main problem I think :)
— Reply to this email directly, view it on GitHub https://github.com/OpenIPC/firmware/issues/1610#issuecomment-2508696114, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVPWI7IBURFKECQFO7D2DDQEXAVCNFSM6AAAAABSE5CH7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBYGY4TMMJRGQ . You are receiving this because you commented.Message ID: @.***>
Hi, i have a few Simicam cameras from Aliexpress. They are Vatilon PB4 boards and various firmware version:
- V1.13.23-20240524 ( linux-4.9-11 , uboot-2016-15 )
- V1.14.10-20240725 ( linux-4.9-11 , uboot-2016-15 )
On Vatilon website there is 1.15.11 firmware version but still didn't tried it.
I have root access via telnet on port 2360.
Let me know if i can contribute in some way.
I have multiple Vatilon cameras, including PB4. They actually work pretty well if you block internet comms to them. I see we can already get to Uboot and have root access to the firmware. I can contribute. Nice cheap cameras these.
i also have two ASECAM cameras that say they are PB1 in their web UI.
i'm relatively experienced in lowlevel hw hacking, i can also help, but i'm very new to openipc.
i have two of these: https://www.aliexpress.com/item/1005006826151802.html
i have used nmap to scan the ports, and 2360 was not listed as open, but i can indeed telnet to that port.
but the admin 123456 doesn't work there (it works through the web UI, though).
any other ideas for login/pw?
i have two of these: https://www.aliexpress.com/item/1005006826151802.html
i have used
nmapto scan the ports, and 2360 was not listed as open, but i can indeed telnet to that port.but the
admin123456doesn't work there (it works through the web UI, though).any other ideas for login/pw?
Try root/ipc@hs66
i have two of these: https://www.aliexpress.com/item/1005006826151802.html i have used
nmapto scan the ports, and 2360 was not listed as open, but i can indeed telnet to that port. but theadmin123456doesn't work there (it works through the web UI, though). any other ideas for login/pw?Try root/ipc@hs66
it worked! :) thank you!
it seems with the v1.14 and v1.15 there is a bug that does not let you save the time settings on the webgui on the PB4... I have one camera with v1.13 and that works fine but I used IPC tool and tried to upgrade from v1.14 to v1.15 and neither allows me to save the time settings
hello everyone i have a chinese camera which runs a V1.14.91-20241120, but everytime my nvr reboots (once a week) the camera fails to connect and needs a manual password input can someone supply me with the V1.12 version thank you
@mtrakal Any progress on this? Also have an Vatilon PB4 with the fh8856v200 so would be nice to flash OpenIPC on it :-)
Just here to add some info as there isn't much on the internet. I have two of these cameras and can help any sort of testing if needed.
I bought some REVODATA fisheye cameras in 2022 that turned out to run these Vatilon boards. I can confirm I also had the same issue darrylb123 had where both of these cameras would just reboot on their own, and I didn't have auto reboot on. These cameras eventually broke and started boot looping, the webUI would show up just for a moment and I couldn't get in.
I didn't know much about them at the time, opened them up and bought new SOCs/mobos for them, so these cameras now run this module: https://www.aliexpress.us/item/3256804887434971.html
in case the link goes down: FH8852V200+GC5053 V1.14.91-20241120 PA4 uboot-2016-22
Well these ones eventually broke in the exact same way so I dug further and found the info discussed here: the open telnet port and cracked root password. root/ipc@hs66
I got in and found the /tmp/ipcam binary was segfaulting on boot, which then caused it to restart forever. After reading the /usr/app/run.sh I found you can force a factory reset which I did, but still it was bootlooping. The fix for me was to manually edit the /tmp/etc/config/ipcam.conf and disable ONVIF. I don't know what changed, cause it worked before but if that camera booted with ONVIF it would segfault on startup, and no way to get in the webUI. My camera now boots and I just have to use RTSP
point being, if you have this Vatilon firmware and your camera boot loops, I fixed it by killing ipcam process to keep it up, editing the /tmp/etc/config/ipcam.conf to disable ONVIF. So having a nice working OpenIPC would be great, there are tons of cheap cameras out there that that use these chips =)