sometimes receive strange responses other nodes. transaction id match request transaction id remote ip tend believe node responded looks sort of mix of response , request
d1:q9:find_node1:rd2:id20:.év0özý.?tjn.?.!2:ip4:dÄ.^7:nodes.v26:.ï?m.:isµlw.Ðä¸úzdÄ.^æce1:t2:..1:y1:re worst of is malformed. @ 7:nodes.v means add nodes.v dictionary. supposed 5:nodes. so, i'm lost. it?
the internet , remote nodes unreliable or buggy. have code defensively. not assume receive valid.
remote peers might
- send invalid bencoding, discard those, don't try recover.
- send truncated messages. not recoverable unless happens last
eof root dictionary. - omit mandatory keys. can either ignore messages or return error message
- contain corrupted data
- include unknown keys beyond mandatory ones. not error, treat them if weren't there sake of forward-compatibility
- actually attackers trying fuzz implementation or use dos amplifier
i suspect shoddy implementations based on whatever string types programming language supports , incorrectly handle encoding instead of using arrays of uint8 bencoding demands. there's nothing can done those. ignore or send error message.
specified dictionary keys usually ascii-mappable, not requirement. e.g. there tracker response types use random binary data dictionary keys.
here few examples of junk i'm seeing[1] fails bdecoding:
d1:ad2:id20:�w)��-��t����=?�������i�&�i!94h�#7u���p�)�x��f��ymle���p:q9q�etjy��r7�:t�5�����n��h�|1�s� d1:e�����������������h# d1:ad2:id20:�����:��m�e��2~�����9>inm�_hash20:x�j�d��ny��-������x�6:noseedi1ee1:q9:get_peers1:t2:�=1:v4:lt��1:y1:qe d1:ad2:id20:�����:��m�e��2~�����9=inl�_hash20:x�j�d��ny���������x�6:noseedi1ee1:q9:get_peers1:t2:�=1:v4:lt��1:y1:qe d1:ad2:id20:�����:��m�e��2~�����9?ino�_hash20:x�j�d��ny���������x�6:noseedi1ee1:q9:get_peers1:t2:�=1:v4:lt��1:y1:qe [1] preserved char count. replaced non-printable, ascii-incompatible bytes unicode replacement character.
Comments
Post a Comment