-
-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asecam / Jieuno (fullhan / vatilon) integration #1610
Comments
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? |
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
<#1610 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTSUVMWCQQBVC2ZOI2M2UD2C6FFJAVCNFSM6AAAAABSE5CH7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBWG44DCMRTGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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 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
<#1610 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTSUVPWI7IBURFKECQFO7D2DDQEXAVCNFSM6AAAAABSE5CH7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBYGY4TMMJRGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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 :)
The text was updated successfully, but these errors were encountered: