some torrents are calced wrong info_hash

[hanbing0715]

hello everyone
i found some inestering torrent that deluge calcs a wrong info_hash compared with utorrent
i also use winhex to calc info_hash,it prove utorrent is right
my deluge is 1.3.9 and libtorrnet is 0.16.17
transmission on my pc also calcs same wrong info_hash
i think it's a bug in deluge or libtorrent
here is some torrent in attachment

[Cas]

If Transmission and Deluge both calculate the same infohash then you are jumping to the wrong conclusion as they use different libraries. Either there is something wrong with utorrent, the torrent files are bad or you have made a mistake in the calculation, can you specify the infohashes you are seeing.

The one thing of note is that these are private flagged torrents without trackers which means they are essentially useless until a tracker is added.

[hanbing0715]

If Transmission and Deluge both calculate the same infohash then you are jumping to the wrong conclusion as they use different libraries. Either there is something wrong with utorrent, the torrent files are bad or you have made a mistake in the calculation, can you specify the infohashes you are seeing.

The one thing of note is that these are private flagged torrents without trackers which means they are essentially useless until a tracker is added.

i have remove the tracker because they are torrents of a private site,you know tracker do not change info_hash
torrent X-Men'.Day...Wiki info_hash is F9DEEA9D2DEDFFDFDDBEF7821E8B0B4861C17F80 (i also use winhex to calcs sha1 of the dictionary "info" make sure utorrent calcs right)
deluge calcs 67d42bdafb54159ca240b08804799ed1fb11aaa7
torrent The.Chart...Wiki info_hash is F1FE7F46774C9C64F6866E9EB1FF8956A141CC98
deluge calcs 7161626e54a0e7623a6990e442eb12649576357c
torrent CCTV1...NGB info_hash is 5BCABDF71C47306CBA65EAB46DA7F53426A3712F
deluge calcs 7b852f8c23e59ba00fc403a741988e33e39b23df

[Cas]

How exactly are you calculating this infohash with winhex because the only alternative here is that there is a problem with implementations of bencode (or sha1 hash).

Code: Select all

#!/usr/bin/env python
import hashlib
import bencode

with open('CCTV1.Da.Guo.Zhong.Qi.Complete.720p.HDTV.x264-NGB.torrent') as _file:
    torrent_info = bencode.bdecode(_file.read())['info']

print(hashlib.sha1(bencode.bencode(torrent_info)).hexdigest())

The bencode can be any module, pypi, deluge one, `from deluge import bencode` or libtorrent one `libtorrent.bencode`.

[hanbing0715]

i have use you way to calc and get the same result as deluge does
and i find why deluge calc this info_hash
i use

print(torrent_info)

rather then

print(hashlib.sha1(bencode.bencode(torrent_info)).hexdigest())

then i find a item called 'name' jump to the end of dictionary and then sha1 change

xa5+\x05\x92\x1a\x1f', 'source': '\xe6\x9e\x81\xe9\x80\x9f\xe4\xb9\x8b\xe6\x98\x9f(http://bitpt.cn)', 'name': 'CCTV1.Da.Guo.Zhong.Qi.Complete.720p.HDTV.x264-NGB'}

as we can see in the originally torrent source is the last item in the dictionary
and then other torrent this situation do not happen

[Cas]

as we can see in the originally torrent source is the last item in the dictionary
and then other torrent this situation do not happen

That is irrelevant as a python dictionary by it's nature is unordered so that is not an issue here. You can use the sorted() function and see that it does not affect the hash once bencoded again.

As I suggested at the beginning, this is a problem with your torrent files.

From the bittorrent specs http://www.bittorrent.org/beps/bep_0003.html

bencoding
Dictionaries are encoded as a 'd' followed by a list of alternating keys and their corresponding values followed by an 'e'. For example, d3:cow3:moo4:spam4:eggse corresponds to {'cow': 'moo', 'spam': 'eggs'} and d4:spaml1:a1:bee corresponds to {'spam': ['a', 'b']}. Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics).

So you can see that when bencoding a (python unordered) dict it will end up sorted and when looking at the raw torrent file I can now see that it is actually out of order. Further evidence is while looking at other bencode python modules I found that using bzrlib.bencode.bdecode resulted in 'ValueError: dict keys disordered'.

The problem therefore lies with utorrent badly bencoding when creating the torrent file.