dh p2p
1.0.0
وهذا دليل على تنفيذ مفهوم RTSP عبر بروتوكول Dahua P2P. يعمل مع Dahua والكاميرات المشتقة / NVRs.
يتم استخدام بروتوكول Dahua P2P للوصول عن بعد إلى أجهزة Dahua. يتم استخدامه بشكل شائع بواسطة تطبيقات Dahua مثل gDMSS Lite على Android أو SmartPSS أو KBiVMS على Windows.
في السيناريو الخاص بي، لدي نظام KBVision CCTV. على الرغم من أنه يمكنني الوصول إلى الكاميرات باستخدام عميل KBiVMS، إلا أنني أستخدم في المقام الأول منصات غير Windows. ولذلك، أردت استكشاف خيارات بديلة لبث الفيديو باستخدام عميل RTSP، وهو مدعوم على نطاق أوسع. ونتيجة لذلك، قررت تجربة إعادة تنفيذ بروتوكول Dahua P2P.
src/*.rs - ملفات مصدر الصدأCargo.toml - تبعيات الصدأmain.py - البرنامج النصي الرئيسيhelpers.py - وظائف المساعدrequirements.txt - تبعيات بايثونdh-p2p.lua - مُشرح Wireshark لبروتوكول Dahua P2P تنفيذ الصدأ باستخدام البرمجة غير المتزامنة ونمط تمرير الرسائل، مما يجعلها أكثر كفاءة ومرونة.
A PoC implementation of TCP tunneling over Dahua P2P protocol.
Usage: dh-p2p [OPTIONS] <SERIAL>
Arguments:
<SERIAL> Serial number of the camera
Options:
-p, --port <[bind_address:]port:remote_port>
Bind address, port and remote port. Default: 127.0.0.1:1554:554
-h, --help
Print help
يعد تطبيق Python لـ DH-P2P أسلوبًا بسيطًا ومباشرًا. يتم استخدامه لأغراض الصياغة والاختبار نظرًا لطبيعته السريعة وسهلة الكتابة. بالإضافة إلى ذلك، يكون التنفيذ أكثر خطية ويتبع تدفق التنفيذ من أعلى إلى أسفل، مما يسهل فهمه. بايثون، كونها لغة برمجة شائعة، تساهم أيضًا في سهولة الوصول إليها ومعرفتها بين المطورين.
# Create virtual environment
python3 -m venv venv
source venv/bin/activate
# Install dependencies
pip install -r requirements.txt
# Run
python main.py [CAMERA_SERIAL]
# Stream (e.g. with ffplay) rtsp://[username]:[password]@127.0.0.1/cam/realmonitor?channel=1&subtype=0
ffplay -rtsp_transport tcp -i " rtsp://[username]:[password]@127.0.0.1/cam/realmonitor?channel=1&subtype=0 " لاستخدام البرنامج النصي مع جهاز يتطلب المصادقة عند إنشاء قناة، استخدم الخيار -t 1 .
عند التشغيل في وضع --debug أو عندما يكون --type > 0، تكون وسيطات USERNAME و PASSWORD إلزامية. بالإضافة إلى ذلك، تأكد من وجود ffplay في مسار النظام عند تمكين وضع التصحيح.
usage: main.py [-h] [-u USERNAME] [-p PASSWORD] [-d] serial
positional arguments:
serial Serial number of the camera
options:
-h, --help show this help message and exit
-d, --debug Enable debug mode
-t TYPE, --type TYPE Type of the camera
-u USERNAME, --username USERNAME
Username of the camera
-p PASSWORD, --password PASSWORD
Password of the camer
ffplay و- -rtsp_transport tcp لإجراء هندسة عكسية للبروتوكول، استخدمت Wireshark وKBiVMS V2.02.0 كعميل على Windows. باستخدام أداة تشريح dh-p2p.lua ، يمكنك رؤية البروتوكول في Wireshark بشكل أسهل.
بالنسبة لعميل RTSP، يمكن استخدام VLC أو ffplay للتحكم بشكل أسهل في الإشارات.
الرسم البياني LR
التطبيق[[هذا البرنامج النصي]]
الخدمة[Easy4IPCloud]
الجهاز[الكاميرا/NVR]
التطبيق--1->الخدمة
الخدمة--2->الجهاز
التطبيق <-. 3 .-> الجهاز
يبدأ بروتوكول Dahua P2P بمصافحة P2P. تتضمن هذه العملية تحديد موقع الجهاز باستخدام الرقم التسلسلي (SN) الخاص به عبر خدمة خارجية، Easy4IPCloud:
الرسم البياني LR
الجهاز[الكاميرا/NVR]
التطبيق[[هذا البرنامج النصي]]
العميل 1 [عميل RTSP 1]
العميل 2 [عميل RTSP 2]
العميلn[عميل RTSP n]
العميل 1 - TCP -> التطبيق
العميل 2 - TCP -> التطبيق
Clientn - TCP -> التطبيق
التطبيق <-. UDPnبروتوكول PTCP .-> الجهاز
بعد مصافحة P2P، يبدأ البرنامج النصي في الاستماع إلى اتصالات RTSP على المنفذ 554. عند اتصال العميل، يبدأ البرنامج النصي مجالًا جديدًا ضمن بروتوكول PTCP. في الأساس، يعمل هذا البرنامج النصي بمثابة نفق بين العميل والجهاز، مما يسهل الاتصال من خلال تغليف PTCP.
مخطط تسلسل
المشارك أ مثل هذا البرنامج النصي
المشارك ب كـ Easy4IPCloud
مشارك C1 كخادم P2P
المشارك C2 كخادم ترحيل
المشارك C3 كخادم وكيل
المشارك D ككاميرا/NVR
أ->>ب: /probe/p2psrv
ب-->>أ: ;
أ->>ب: /online/p2psrv/{SN}
ب-->>أ: معلومات p2psrv
أ->>C1: /مسبار/جهاز/{SN}
C1-->>أ: ;
أ->>ب: /online/relay
ب->>أ: معلومات التتابع
أ->>ب: /device/{SN}/p2p-channel (*)
قدم المساواة
أ->>C2: /relay/agent
C2-->>أ: معلومات الوكيل + الرمز المميز
أ->>C3: /relay/start/{token}
C3-->>أ: ;
نهاية
ب-->>أ: معلومات الجهاز
أ->>ب: /device/{SN}/relay-channel + معلومات الوكيل
C3-->>أ: معلومات Nat للخادم!
أ->>C3: PTCP SYN
أ->>C3: علامة طلب PTCP
C3-->>أ: علامة PTCP
أ->>د: مصافحة PTCP (*)
ملاحظة : يجب أن يستخدم كلا الاتصالين المميزين بالعلامة (*) وجميع الاتصالات اللاحقة بالجهاز نفس منفذ UDP المحلي.
PTCP (PhonyTCP) هو بروتوكول خاص تم تطويره بواسطة Dahua. إنه يخدم غرض تغليف حزم TCP داخل حزم UDP، مما يتيح إنشاء نفق بين العميل والجهاز خلف NAT.
يرجى ملاحظة أن الوثائق الرسمية لـ PTCP غير متوفرة. المعلومات المقدمة هنا مبنية على الهندسة العكسية.
رأس حزمة PTCP عبارة عن بنية ثابتة مكونة من 24 بايت، كما هو موضح أدناه:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| magic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| recv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lmid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rmid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
magic : قيمة ثابتة، PTCP .sent و recv : تتبع عدد البايتات المرسلة والمستلمة، على التوالي.pid : معرف الحزمة.lmid : المعرف المحلي.rmid : المعرف المحلي للحزمة المستلمة مسبقًا.يختلف حجم جسم الحزمة (0، 4، 12 بايت أو أكثر) بناءً على نوع الحزمة. هيكلها على النحو التالي:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| realm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type : يحدد نوع الحزمة.len : طول حقل data .realm : معرف المجال للاتصال.padding : بايتات الحشو، يتم ضبطها دائمًا على 0.data : بيانات الحزمة.أنواع الحزم:
0x00 : SYN، الجسم دائمًا 4 بايت 0x00030100 .0x10 : بيانات TCP، حيث len هو طول بيانات TCP.0x11 : طلب منفذ ملزم.0x12 : حالة الاتصال، حيث تكون البيانات إما CONN أو DISC .realm على 0):0x13 : نبضات القلب، حيث يكون len دائمًا 0.0x170x180x19 : المصادقة.0x1a : استجابة الخادم بعد 0x19 .0x1b : استجابة العميل بعد 0x1a . لقد استلهم هذا المشروع وتأثر بالمشاريع والأشخاص التاليين:
