কেন একটি C struct খারাপ SOCKS অনুরোধ তৈরি করতে পারে
কম্পাইলার লেআউটকে ওয়্যার ফরম্যাট ধরে না নিয়ে স্পষ্ট ফিল্ড প্রস্থ, বাইট ক্রম ও স্ট্রিম I/O পরীক্ষা করুন।
বৈধ প্রক্সি ঠিকানা হাতে লেখা SOCKS বার্তাকে বৈধ করে না। C বা C++ struct পাঠালে প্রোটোকল কখনও চায়নি এমন প্যাডিং বা হোস্ট-ক্রমের পূর্ণসংখ্যা পাঠাতে পারে।
SOCKS5 ডোমেইন-নাম CONNECT অনুরোধের জন্য, পদ্ধতি আলোচনা ও নির্বাচিত প্রমাণীকরণের পরে এই ক্রমটি স্পষ্টভাবে সিরিয়ালাইজ করুন:
- সংস্করণ, কমান্ড, সংরক্ষিত বাইট এবং ঠিকানার ধরন
- ডোমেইনের দৈর্ঘ্য ও ডোমেইন বাইট
- নেটওয়ার্ক বাইট ক্রমে দুই বাইটের গন্তব্য পোর্ট
ঠিকানার দৈর্ঘ্য SOCKS সংস্করণ ও ঠিকানার ধরনের উপর নির্ভর করে। নির্দিষ্ট প্রস্থের সংখ্যাসূচক ফিল্ডের নিজস্ব নির্ধারিত উপস্থাপনা দরকার; ডোমেইন স্ট্রিংয়ের নিজস্ব দৈর্ঘ্য এনকোডিং আছে। C স্ট্রিং টার্মিনেটর ওয়্যার বার্তায় শূন্য যোগ করার সাধারণ নির্দেশ নয়।
| বাস্তবায়নের শর্টকাট | যে সমস্যা যাচাই করতে হবে |
|---|---|
| 8-বিট পয়েন্টারের মাধ্যমে 32-বিট মান নির্ধারণ | এটি চারটি বাইটই নির্গত করে না |
| একটি বাফারকে বড় পূর্ণসংখ্যা পয়েন্টারে কাস্ট করা | সারিবদ্ধতা ও বাইট ক্রম এখনও সামলাতে হবে |
| ধরে নেওয়া একটি পড়া বা লেখা একটি বার্তা | TCP প্রোটোকল ক্রমের কেবল একটি অংশ স্থানান্তর করতে পারে |
প্রতিটি ফিল্ডকে অভীষ্ট গন্তব্যের সঙ্গে তুলনা করুন এবং আংশিক I/O সামলান। দুটি বাইট পাওয়া মানে এই নয় যে সম্পূর্ণ উত্তর এসেছে। এই সীমাগুলি পরীক্ষা করলে বিকৃত অনুরোধকে সঠিকভাবে বর্ণিত সংযোগ প্রত্যাখ্যানকারী সার্ভার থেকে আলাদা করা যায়।