لماذا قد يُنتج هيكل C طلب SOCKS سيئًا
افحص عروض الحقول الصريحة وترتيب البايتات وإدخال/إخراج التدفق بدلًا من اعتبار تخطيط المترجم صيغة الشبكة.
عنوان وكيل صالح لا يجعل رسالة SOCKS المكتوبة يدويًا صالحة. إرسال هيكل C أو C++ قد يرسل حشوًا أو أعدادًا صحيحة بترتيب المضيف لم يطلبها البروتوكول قط.
لطلب SOCKS5 من نوع CONNECT باسم نطاق، قم بتسلسل هذا الترتيب صراحةً بعد التفاوض على الطريقة وأي مصادقة مختارة:
- الإصدار والأمر والبايت المحجوز ونوع العنوان
- طول النطاق وبايتات النطاق
- منفذ الوجهة المكوَّن من بايتين بترتيب بايتات الشبكة
تعتمد أطوال العناوين على إصدار SOCKS ونوع العنوان. تحتاج الحقول الرقمية ذات العرض الثابت تمثيلها المحدد؛ ولنصوص النطاق ترميز الطول الخاص بها. إن مُنهي سلسلة C ليس تعليمًا عامًا لإضافة صفر إلى رسالة الشبكة.
| اختصار في التنفيذ | مشكلة يجب فحصها |
|---|---|
| إسناد قيمة 32 بت عبر مؤشر 8 بت | لا يُخرج البايتات الأربعة كلها |
| تحويل مخزن مؤقت إلى مؤشر عدد صحيح أكبر | لا تزال المحاذاة وترتيب البايتات بحاجة إلى معالجة |
| افتراض أن قراءة أو كتابة واحدة رسالة واحدة | يمكن لـTCP نقل جزء فقط من تسلسل البروتوكول |
قارن كل حقل بالوجهة المقصودة وتعامل مع الإدخال/الإخراج الجزئي. استلام بايتين لا يثبت أن الرد كاملًا وصل. فحص تلك الحدود يمكن أن يميز بين طلب مشوّه وخادم يرفض اتصالًا موصوفًا بشكل صحيح.