有人可以了解一下这种奇怪的DHT响应的含义吗? [英] Can somebody shed a light what this strange DHT response means?

问题描述

有时我会收到其他节点的奇怪回应.交易ID与我的请求交易ID以及远程IP都匹配，因此我倾向于认为节点对此进行了响应，但它看起来像是响应和请求的组合

Sometimes I receive this strange responses from other nodes. Transaction id match to my request transaction id as well as the remote IP so I tend to believe that node responded with this but it looks like sort of a mix of response and request

d1:q9:find_node1:rd2:id20:.éV0özý.?tj­N.?.!2:ip4:DÄ.^7:nodes.v26:.ï?M.:iSµLW.Ðä¸úzDÄ.^æCe1:t2:..1:y1:re

最糟糕的是它格式不正确.看7:nodes.v，这意味着我将node.v添加到字典中.应该是5:nodes.所以，我迷路了.什么事?

Worst of all is that it is malformed. Look at 7:nodes.v it means that I add nodes.v to the dictionary. It is supposed to be 5:nodes. So, I'm lost. What is it?

推荐答案

Internet和远程节点不可靠或有故障.您必须进行防御性编码.不要以为您收到的所有东西都是有效的.

The internet and remote nodes is unreliable or buggy. You have to code defensively. Do not assume that everything you receive will be valid.

远程同龄人可能

• 发送无效的bencoding，将其丢弃，甚至不要尝试恢复.
• 发送截断的消息.通常无法恢复，除非它恰好是根字典的最后一个e.
• 省略强制性密钥.您可以忽略这些消息或返回错误消息
• 包含损坏的数据
• 包括除强制性密钥以外的未知密钥.这不是错误，只是为了向前兼容就将它们视为不存在
• 实际上是攻击者试图模糊您的实施或将您用作DoS放大器

• send invalid bencoding, discard those, don't even try to recover.
• send truncated messages. usually not recoverable unless it happens to be the very last e of the root dictionary.
• omit mandatory keys. you can either ignore those messages or return an error message
• contain corrupted data
• include unknown keys beyond the mandatory ones. this is not an error, just treat them as if they weren't there for the sake of forward-compatibility
• actually be attackers trying to fuzz your implementation or use you as DoS amplifier

我还怀疑某些真正伪劣的实现是基于其编程语言支持的任何string类型，并且会错误地处理编码，而不是根据bencoding的要求使用uint8数组.这些都无能为力.忽略或偶尔发送错误消息.

I also suspect that some really shoddy implementations are based on whatever string types their programming language supports and incorrectly handle encoding instead of using arrays of uint8 as bencoding demands. There's nothing that can be done about those. Ignore or occasionally send an error message.

通常 可以指定ASCII映射的字典键，但这不是必需的.例如.有些跟踪器响应类型实际上使用随机二进制数据作为字典键.

Specified dictionary keys are usually ASCII-mappable, but this is not a requirement. E.g. there are some tracker response types that actually use random binary data as dictionary keys.

以下是我看到的一些垃圾示例，其中 ^[1] 甚至无法bdecoding:

Here are a few examples of junk I'm seeing^[1] that even 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] 保留的字符数.用unicode替换字符替换了所有不可打印的，与ASCII不兼容的字节.

^[1] preserved char count. replaced all non-printable, ASCII-incompatible bytes with the unicode replacement character.

这篇关于有人可以了解一下这种奇怪的DHT响应的含义吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！