Kial C-strukturo povas produkti malbonan SOCKS-petaron
Inspektu eksplicitajn kampolarĝojn, bajtordanon kaj fluan I/O anstataŭ trakti la aranĝon de la kompililo kiel la dratan formaton.
Valida prokura adreso ne faras validan mane skribitan SOCKS-mesaĝon. Sendi C aŭ C++ strukturon povas sendi plenigaĵon aŭ entjerojn en gastigila ordo, kiujn la protokolo neniam postulis.
Por SOCKS5-domajnoma CONNECT-petaro, seriajigu ĉi tiun sinsekvon eksplicite post la metodintertraktado kaj ajna elektita aŭtentikigo:
- Versio, komando, rezervita bajto kaj adresotipo
- Domajna longeco kaj domajnaj bajtoj
- La dubajta celhavena pordo en reta bajtordo
Adreslongecoj dependas de la SOCKS-versio kaj adresotipo. Nombraj kampoj de fiksa larĝo bezonas sian specifitan prezenton; domajnaj signoĉenoj havas sian propran longecan kodadon. C-signoĉena finilo ne estas ĝenerala instrukcio aldoni nulon al la drata mesaĝo.
| Implementa fuŝsolvo | Problemo kontrolenda |
|---|---|
| Asigni 32-bitan valoron per 8-bita montrilo | Ĝi ne eligas ĉiujn kvar bajtojn |
| Konverti bufron al montrilo de pli granda entjero | Ĝisrandigo kaj bajtordo ankoraŭ devas esti traktataj |
| Supozi, ke unu legado aŭ skribado estas unu mesaĝo | TCP povas transdoni nur parton de la protokola sinsekvo |
Komparu ĉiun kampon kun la celata celo kaj traktu partan I/O. Ricevi du bajtojn ne pruvas, ke la tuta respondo alvenis. Inspekti tiujn limojn povas distingi misformitan petaron de servilo, kiu rifuzas ĝuste priskribitan konekton.