misternote
n3wb
Hello Community,
as written in the other threads, we are working on a project to include several types of cameras in a tiny app for raspberry without using any SDKs.
So far it works well for Dahua and other cameras, but we have trouble getting into the hikvision protocol.
For Testing we purchased some hikvision cameras and sniffed the traffic from wireshark, same as all the calls via Api Monitor and IDA Pro.
We figured out that before NET_DVR_Login_V30/V40 is called, several RSA functions were called from libssl-1-1-x64 before it finally goes into SHA256.
The SHA256 contains the following for our testcamera using admin:admin12345 as a "string" parameter, which is very confusing.
admin37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6admin12345
By repeating the same procedure, it's always the same string which is used for SHA256.
Since 37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6 seems to be a SHA256 hash already, we tried to find out what it could be.
Shortly before SHA256 is called, there is a method call to RSA_private_decrypt which contains 37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6.
Before all that, there are several RSA_generate_key_ex calls, which might also just usages from API Monitor.
The traffic which is sent straight after SHA256 is always changes a bit, which means that there is some "random"-number for encryption which could for example a counter which is used by NetSDK::CUseCountAutoDec::CUseCountAutoDec ( ... ).
.
In that example: 000000e05a000000000000000001000005013d4b0000010119b2a8c02cfda1ce43266f0061646d696e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000030818902818100d0bd45ac2aa3e22d93c22d182e8240c71f2e68ab09e8962b432c98b0fd905dc620cb0844a09300ec6f7f4ad6820e36b6d0c47d864ff86b696b9b62a6b77b5018ddc254ab963b1e3a26424b234fc0568f8951bce9fce793af208ec6bd42e79f480b594d89a62424c83c30d4dbe8a5d837b1c8b81ed3898e08743c89ee2ed4be790203010001
I'm not sure if the part between the user and the password above matters which is used to SHA256, but when creating a SHA256 hash out of admin37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6admin12345 it never matches the actuall traffic which is sent to the camera.
Maybe someone got it working and could share how the login process works.
Thank you
as written in the other threads, we are working on a project to include several types of cameras in a tiny app for raspberry without using any SDKs.
So far it works well for Dahua and other cameras, but we have trouble getting into the hikvision protocol.
For Testing we purchased some hikvision cameras and sniffed the traffic from wireshark, same as all the calls via Api Monitor and IDA Pro.
We figured out that before NET_DVR_Login_V30/V40 is called, several RSA functions were called from libssl-1-1-x64 before it finally goes into SHA256.
The SHA256 contains the following for our testcamera using admin:admin12345 as a "string" parameter, which is very confusing.
admin37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6admin12345
By repeating the same procedure, it's always the same string which is used for SHA256.
Since 37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6 seems to be a SHA256 hash already, we tried to find out what it could be.
Shortly before SHA256 is called, there is a method call to RSA_private_decrypt which contains 37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6.
Before all that, there are several RSA_generate_key_ex calls, which might also just usages from API Monitor.
The traffic which is sent straight after SHA256 is always changes a bit, which means that there is some "random"-number for encryption which could for example a counter which is used by NetSDK::CUseCountAutoDec::CUseCountAutoDec ( ... ).
.
In that example: 000000e05a000000000000000001000005013d4b0000010119b2a8c02cfda1ce43266f0061646d696e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000030818902818100d0bd45ac2aa3e22d93c22d182e8240c71f2e68ab09e8962b432c98b0fd905dc620cb0844a09300ec6f7f4ad6820e36b6d0c47d864ff86b696b9b62a6b77b5018ddc254ab963b1e3a26424b234fc0568f8951bce9fce793af208ec6bd42e79f480b594d89a62424c83c30d4dbe8a5d837b1c8b81ed3898e08743c89ee2ed4be790203010001
I'm not sure if the part between the user and the password above matters which is used to SHA256, but when creating a SHA256 hash out of admin37e11b56fb7d3a10a3ccf7fe306b2114b68075d6bcd501a7a8093ec17287b7d6admin12345 it never matches the actuall traffic which is sent to the camera.
Maybe someone got it working and could share how the login process works.
Thank you