I run Amcrest Surveillance Pro on my MacBook Pro but it does NOT provide the same functionality as the WinDoze version. I also run SP under Windows using Parallels for Mac. When I run the Windows version, if you go to the device config area and select a camera, there is an option to connect directly to the camera using a browser because the software sets up a local port forward for the S/N address that was originally entered into the configuration.
Amcrest says the difference in functionality (between the Win and Mac SP versions) must be because there must be a limitation in the operating system, which is BS. Mac OS is basically Unix under the covers and for sure you can set up a local re-route and port forwarding in Unix.
When you add a new camera in ASP using the serial number that is clearly being resolved by the application (much like a DNS look up) to a publicly addressable IP with a port, so the application can access the web GUI on the camera.
What I'm looking for is some way to access the Amcrest "resolver" so I can get the public IP and port using the serial number of the camera. If I can get that info I should be able do directly access remote cameras without needing to boot windows, then run APS for windows, and then linking to the camera GUI via the functionality in the Windows version of ASP.
The Amcrest IP Config utility does not provide that functionality, so does someone know of a way to do this?
Tool to Resolve S/N to an IP:port Address
Re: Tool to Resolve S/N to an IP:port Address
Not something you will find. 1 there is a lot that goes into a P2P setup and because of the info is Private for the security of the End User (you in this case) that info can't be found without the keys in place. In this case what are the keys. First Camera/DVR/NVR, second the App and in this case ASP.. Using the UUID to setup the connection is one thing, However the connection then adds in a path using the Encrypted connection to let the end user have access to the device they are connecting to using a tunnel path.. The issue is that the Path every time you connect isn't the same and this is designed to help protect the end user.
How does it work, Well when you setup a P2P connection with your device, It pings out to a server and the server waits for a call for the UUID in question. Once that call is made either by AVP or ASP in your case the server sets up a handshake, this is looking to confirm that the user has the rights to the connection, at this point an Encrypted tunnel opens and this data is passed off to the app that has requested the connection and you enter your password and user name and as long as it is correct it opens the connection. Then in the case of wanting to access the WebUI of the device it using the info of the Encrypted data and makes a local host tunnel to a new port, this using another bridge type connection isn't using the IP of the camera it is using another path of the local device if password and user name isn't correct it will fail.
How can you tell if this is the way it will work. Well make a good connection, I know you will have to use Windows but yeah. Then make your connection to the cameras WebUi, Then copy the info from the WebUI address, Then close the connection to the device. Close ASP. Now bring up asp again and bring up the camera in ASP so it is in use (Meaning that the connection is woke up but you have not tried to access the WebUI just that you have opened the cameras or DVR/NVR in the ASP software. Then open your browser and paste in the URL from your last connection with the localhost info and that connection will fail. that is because the tunnel that it was using before using the Encrypted data is no longer valid and the P2P connection has now opened a new tunnel UUID that would be required to access the WebUI of the ASP connected device..
How does it work, Well when you setup a P2P connection with your device, It pings out to a server and the server waits for a call for the UUID in question. Once that call is made either by AVP or ASP in your case the server sets up a handshake, this is looking to confirm that the user has the rights to the connection, at this point an Encrypted tunnel opens and this data is passed off to the app that has requested the connection and you enter your password and user name and as long as it is correct it opens the connection. Then in the case of wanting to access the WebUI of the device it using the info of the Encrypted data and makes a local host tunnel to a new port, this using another bridge type connection isn't using the IP of the camera it is using another path of the local device if password and user name isn't correct it will fail.
How can you tell if this is the way it will work. Well make a good connection, I know you will have to use Windows but yeah. Then make your connection to the cameras WebUi, Then copy the info from the WebUI address, Then close the connection to the device. Close ASP. Now bring up asp again and bring up the camera in ASP so it is in use (Meaning that the connection is woke up but you have not tried to access the WebUI just that you have opened the cameras or DVR/NVR in the ASP software. Then open your browser and paste in the URL from your last connection with the localhost info and that connection will fail. that is because the tunnel that it was using before using the Encrypted data is no longer valid and the P2P connection has now opened a new tunnel UUID that would be required to access the WebUI of the ASP connected device..
Be Safe.
Re: Tool to Resolve S/N to an IP:port Address
One way you might find it is rip apart their mobile app on a debugger and prune the code into a new python or swift app.madmacks wrote: ↑Fri Oct 04, 2024 11:20 am
When you add a new camera in ASP using the serial number that is clearly being resolved by the application (much like a DNS look up) to a publicly addressable IP with a port, so the application can access the web GUI on the camera.
What I'm looking for is some way to access the Amcrest "resolver" so I can get the public IP and port using the serial number of the camera. If I can get that info I should be able do directly access remote cameras without needing to boot windows, then run APS for windows, and then linking to the camera GUI via the functionality in the Windows version of ASP.
But I imagine there is more to this because p2p doesn't scale without a database server somewhere. Your IOT device contacts a database server, then you add an account to the database server with an app, then you scan or input the serial number the database already has from the NVR joining the database, then either a stored ip number the nvr updates independently on the database or $_SERVER['remote'} envars are called to complete the stun media connection. This hasn't changed very much in the past decade or so, just the end viewing. Before all this used flash and I think even Hikvision still uses the old flash video in its web gui.
A lot of people know of the security hole in these types of connection which is you don't have control of the P2P/app server. Because you wouldn't know if they have a media buffering/turn server hooked up remotely recording. This is why P2P is not NDAA compliant.
The other security hole that is in most ip cameras is the lack of user input sanitization. That is why it's important to secure the network and most even isolate them. Because a simple code injection routine can set up a hacking beach head in a camera very easily on security cameras, NDAA compliant or not.
Re: Tool to Resolve S/N to an IP:port Address
By the way I have a NDAA 16ch Ai NVR and some Ai Ip cameras that are NDAA that do in fact use P2P and to be honest I don't feel it is as secure as the Amcrest P2P services.. NDAA fails on servers that are in the middle like Cloud based P2P because that data is not really Peer 2 Peer like a normal IP based system is.. The UUID changes many times in each connection in Peer 2 Peer connections and that is part of the Encryption. Even if you happen to figure out the P2P Id and make a connection to it without in this case Amcrest app and Amcrest device it will never get the new UUID to keep the connection going...
Here is some info that I have posted some time ago about P2P and this is how Amcrest normal P2P works.
In a normal IP camera system with DVR (Digital Video Recorder) or NVR (Network Video Recorder) using Peer-to-Peer (P2P) technology, the goal is to allow remote access to video feeds without requiring complex network setups like port forwarding.
Here’s a breakdown of how the P2P functionality works in these systems:
1. Device Registration
Unique ID: Each DVR/NVR or IP camera has a unique identifier (UID) that is registered with the manufacturer’s P2P server when it first connects to the internet.
P2P Server Role: The manufacturer’s P2P server plays a key role as an intermediary, facilitating communication between the DVR/NVR and the remote viewing device (like a smartphone or PC). However, unlike Cloud-Based P2P, the video stream itself doesn’t go through the server but rather connects directly between devices once they’re authenticated.
2. Initial Setup and Connectivity
Network Discovery: Once connected to the internet, the DVR/NVR or IP camera sends a signal to the P2P server (a manufacturer-hosted server) and registers itself. This helps avoid complicated network configurations like port forwarding.
User App: On the user side, a mobile app or computer software is used to access the cameras. The user logs in, and the app communicates with the same P2P server using the camera’s UID.
3. Remote Access
P2P Connection Establishment: When you open your app and request a live view from your DVR/NVR, the app contacts the P2P server and provides the UID of the DVR/NVR or IP camera. The server then helps to negotiate a direct connection between your app and the DVR/NVR.
NAT Traversal: Many DVRs/NVRs and IP cameras are behind routers using Network Address Translation (NAT), which can block direct communication from external devices. P2P technology uses NAT traversal techniques to bypass these obstacles, allowing remote devices to connect directly to the camera through the router without needing manual configuration (such as opening ports).
Direct Peer Connection: Once the connection is established, the video stream flows directly from the DVR/NVR to your viewing device. The P2P server is no longer involved except for occasionally checking the connection's health.
4. Data Flow and Encryption
Direct Video Streaming: In a typical P2P setup, video data streams directly from the IP camera or DVR/NVR to your app, not through the P2P server. This makes the system more efficient and private compared to cloud-based solutions where footage may pass through or be stored on external servers.
Encryption: Many P2P systems implement encryption (e.g., AES) to secure the video stream between the camera/DVR and the remote viewing device, ensuring that even though the data flows over the internet, it remains secure from third-party interception.
5. Reliability and Limitations
Reliability: P2P eliminates the need for complex network setups like port forwarding and makes remote access easier for end users. However, the performance of the system depends on the quality of your internet connection and the stability of the P2P server used to facilitate connections.
Single Point of Failure: If the manufacturer’s P2P server goes down, remote access will not be possible even though the video streams remain functional locally. However, since the server is only used for connecting devices, the actual video footage is not compromised.
Example of How P2P Works in a DVR/NVR System:
Connection Setup:
You install a DVR or NVR with IP cameras at home and connect it to your home network (via Ethernet or Wi-Fi).
The DVR/NVR registers itself with the manufacturer’s P2P server, storing its unique identifier (UID) and current network information.
Remote Access:
You download the manufacturer’s mobile app and log in.
When you want to view the cameras, the app communicates with the P2P server using the UID of the DVR/NVR to locate it and initiate a connection.
Direct Video Stream:
Once the connection is established through NAT traversal, the DVR/NVR sends the live video feed directly to your app without routing through the P2P server. The connection stays active as long as you are viewing or controlling the system.
Advantages of P2P for DVR/NVR Systems:
Easy Setup: No need for port forwarding or dynamic DNS (DDNS) configurations, which can be complex for average users.
Direct Video Streaming: Ensures low latency and more privacy compared to cloud-based solutions since video is streamed directly without involving cloud storage.
Secure: Most systems use encryption for secure streaming.
Limitations:
Reliant on Manufacturer’s P2P Server: If the P2P server goes offline or has performance issues, remote access will be disrupted.
Privacy Concerns: Although the video stream isn’t typically routed through the P2P server, some metadata, like connection logs or device information, may still be handled by the server, which could be a privacy concern depending on the manufacturer’s policies.
Conclusion
In a standard IP camera DVR/NVR P2P system, the P2P server facilitates the initial connection and NAT traversal, making remote access easy without manual network configurations. Once connected, the video stream is sent directly between the camera and the remote device, providing efficient and secure access without relying on cloud storage or external servers for the video feed itself.
In a P2P system, the UID plays a central role in establishing a secure connection, and encryption processes often incorporate it to ensure secure data transmission. The use of dynamic encryption keys or rolling UIDs ensures that both the DVR/NVR and the remote app know what the next expected encryption key will be, allowing for secure communication while preventing replay attacks and ensuring forward secrecy. This system provides an extra layer of security for your video streams during remote access.
Here is some info that I have posted some time ago about P2P and this is how Amcrest normal P2P works.
In a normal IP camera system with DVR (Digital Video Recorder) or NVR (Network Video Recorder) using Peer-to-Peer (P2P) technology, the goal is to allow remote access to video feeds without requiring complex network setups like port forwarding.
Here’s a breakdown of how the P2P functionality works in these systems:
1. Device Registration
Unique ID: Each DVR/NVR or IP camera has a unique identifier (UID) that is registered with the manufacturer’s P2P server when it first connects to the internet.
P2P Server Role: The manufacturer’s P2P server plays a key role as an intermediary, facilitating communication between the DVR/NVR and the remote viewing device (like a smartphone or PC). However, unlike Cloud-Based P2P, the video stream itself doesn’t go through the server but rather connects directly between devices once they’re authenticated.
2. Initial Setup and Connectivity
Network Discovery: Once connected to the internet, the DVR/NVR or IP camera sends a signal to the P2P server (a manufacturer-hosted server) and registers itself. This helps avoid complicated network configurations like port forwarding.
User App: On the user side, a mobile app or computer software is used to access the cameras. The user logs in, and the app communicates with the same P2P server using the camera’s UID.
3. Remote Access
P2P Connection Establishment: When you open your app and request a live view from your DVR/NVR, the app contacts the P2P server and provides the UID of the DVR/NVR or IP camera. The server then helps to negotiate a direct connection between your app and the DVR/NVR.
NAT Traversal: Many DVRs/NVRs and IP cameras are behind routers using Network Address Translation (NAT), which can block direct communication from external devices. P2P technology uses NAT traversal techniques to bypass these obstacles, allowing remote devices to connect directly to the camera through the router without needing manual configuration (such as opening ports).
Direct Peer Connection: Once the connection is established, the video stream flows directly from the DVR/NVR to your viewing device. The P2P server is no longer involved except for occasionally checking the connection's health.
4. Data Flow and Encryption
Direct Video Streaming: In a typical P2P setup, video data streams directly from the IP camera or DVR/NVR to your app, not through the P2P server. This makes the system more efficient and private compared to cloud-based solutions where footage may pass through or be stored on external servers.
Encryption: Many P2P systems implement encryption (e.g., AES) to secure the video stream between the camera/DVR and the remote viewing device, ensuring that even though the data flows over the internet, it remains secure from third-party interception.
5. Reliability and Limitations
Reliability: P2P eliminates the need for complex network setups like port forwarding and makes remote access easier for end users. However, the performance of the system depends on the quality of your internet connection and the stability of the P2P server used to facilitate connections.
Single Point of Failure: If the manufacturer’s P2P server goes down, remote access will not be possible even though the video streams remain functional locally. However, since the server is only used for connecting devices, the actual video footage is not compromised.
Example of How P2P Works in a DVR/NVR System:
Connection Setup:
You install a DVR or NVR with IP cameras at home and connect it to your home network (via Ethernet or Wi-Fi).
The DVR/NVR registers itself with the manufacturer’s P2P server, storing its unique identifier (UID) and current network information.
Remote Access:
You download the manufacturer’s mobile app and log in.
When you want to view the cameras, the app communicates with the P2P server using the UID of the DVR/NVR to locate it and initiate a connection.
Direct Video Stream:
Once the connection is established through NAT traversal, the DVR/NVR sends the live video feed directly to your app without routing through the P2P server. The connection stays active as long as you are viewing or controlling the system.
Advantages of P2P for DVR/NVR Systems:
Easy Setup: No need for port forwarding or dynamic DNS (DDNS) configurations, which can be complex for average users.
Direct Video Streaming: Ensures low latency and more privacy compared to cloud-based solutions since video is streamed directly without involving cloud storage.
Secure: Most systems use encryption for secure streaming.
Limitations:
Reliant on Manufacturer’s P2P Server: If the P2P server goes offline or has performance issues, remote access will be disrupted.
Privacy Concerns: Although the video stream isn’t typically routed through the P2P server, some metadata, like connection logs or device information, may still be handled by the server, which could be a privacy concern depending on the manufacturer’s policies.
Conclusion
In a standard IP camera DVR/NVR P2P system, the P2P server facilitates the initial connection and NAT traversal, making remote access easy without manual network configurations. Once connected, the video stream is sent directly between the camera and the remote device, providing efficient and secure access without relying on cloud storage or external servers for the video feed itself.
In a P2P system, the UID plays a central role in establishing a secure connection, and encryption processes often incorporate it to ensure secure data transmission. The use of dynamic encryption keys or rolling UIDs ensures that both the DVR/NVR and the remote app know what the next expected encryption key will be, allowing for secure communication while preventing replay attacks and ensuring forward secrecy. This system provides an extra layer of security for your video streams during remote access.
Be Safe.
Re: Tool to Resolve S/N to an IP:port Address
It's because someone didn't write the mac version the same way. I still don't know why none of these IP camera companies write a Linux version since a great deal of people has dump Microsoft and switched to Linux.madmacks wrote: ↑Fri Oct 04, 2024 11:20 am I run Amcrest Surveillance Pro on my MacBook Pro but it does NOT provide the same functionality as the WinDoze version. I also run SP under Windows using Parallels for Mac. When I run the Windows version, if you go to the device config area and select a camera, there is an option to connect directly to the camera using a browser because the software sets up a local port forward for the S/N address that was originally entered into the configuration.
Amcrest says the difference in functionality (between the Win and Mac SP versions) must be because there must be a limitation in the operating system, which is BS. Mac OS is basically Unix under the covers and for sure you can set up a local re-route and port forwarding in Unix.
ffmpeg A.K.A. H.264/265 is originally a Linux product that later wrote mac and windows versions. So other than the programmer missing writing the function in the application, Mac and Linux can use ffmpeg to access it. But there is nothing stopping you from using a web browser and typing the ip address of the camera too.
Also, the cameras are not port forwarded to the local network and you wouldn't want port forward them to the internet.