bittorrent-dht bruteforce散列發現問題

所以，我是node.js的新手，我選擇了它的必要性來使用bittorrent-dht，這似乎有我需要的所有想法。bittorrent-dht bruteforce散列發現問題

我的想法基本上是生成隨機的十六進制字符串，並在DHT上進行查找，保留足夠的同行，以便後來在適當的torrent客戶端（在我的情況下，我使用Tixati）進行檢查。

爲此目的我寫了下面的代碼位，這是不優雅，我是新來的node.js，記住這一點......

const crypto = require('crypto'); 

function rand_string(n) { 
    if (n <= 0) { 
      return ''; 
     } 
     var rs = ''; 
     try { 
      rs = crypto.randomBytes(n); 
     rs = rs.toString('hex').slice(0,n); 
      /* note: could do this non-blocking, but still might fail */ 
     } 
     catch(ex) { 
     console.log("cannot genhash");  
    } 
     return rs; 
} 

const min_peers = 100; 
var DHT = require('bittorrent-dht'); 
var dht = new DHT(); 
var hash = []; 
var abort_lookup_0; 
var abort_lookup_1; 
var abort_lookup_2; 
var abort_lookup_3; 
var peers = []; 
dht.listen(63112, function() { 
    console.log('DHT started'); 
    // 
    hash[0] = rand_string(40); 
    peers[0] = 0; 
    abort_lookup_0 = dht.lookup(hash[0]); 
    // 
    hash[1] = rand_string(40); 
    peers[1] = 0; 
    abort_lookup_1 = dht.lookup(hash[1]); 
    // 
    hash[2] = rand_string(40); 
     peers[2] = 0; 
     abort_lookup_2 = dht.lookup(hash[2]); 
    // 
    hash[3] = rand_string(40); 
     peers[3] = 0; 
     abort_lookup_3 = dht.lookup(hash[3]); 
}); 

// this is horrible but it will probably save headaches with loops 
dht.on('peer', function (peer, infoHash, from) { 
    if (infoHash.toString('hex') == hash[0]) peers[0]++; 
    if (infoHash.toString('hex') == hash[1]) peers[1]++; 
    if (infoHash.toString('hex') == hash[2]) peers[2]++; 
    if (infoHash.toString('hex') == hash[3]) peers[3]++; 
    // 
    if (peers[0] > min_peers) { 
     abort_lookup_0(); 
     console.log(hash[0]); 
     peers[0] = 0; 
     hash[0] = rand_string(40); 
     abort_lookup_0 = dht.lookup(hash[0]); 
    } 
    // 
    if (peers[1] > min_peers) { 
     abort_lookup_1(); 
     console.log(hash[1]); 
     peers[1] = 0; 
     hash[1] = rand_string(40); 
     abort_lookup_1 = dht.lookup(hash[1]); 
    } 
    // 
    if (peers[2] > min_peers) { 
       abort_lookup_2(); 
       console.log(hash[2]); 
       peers[2] = 0; 
       hash[2] = rand_string(40); 
       abort_lookup_2 = dht.lookup(hash[2]); 
     } 
    // 
    if (peers[3] > min_peers) { 
       abort_lookup_3(); 
       console.log(hash[3]); 
       peers[3] = 0; 
       hash[3] = rand_string(40); 
       abort_lookup_3 = dht.lookup(hash[3]); 
     } 
}) 

function failedHash() { 
    abort_lookup_0(); 
    hash[0] = rand_string(40); 
    peers[0] = 0; 
    abort_lookup_0 = dht.lookup(hash[0]); 
    // 
    abort_lookup_1(); 
    hash[1] = rand_string(40); 
    peers[1] = 0; 
    abort_lookup_1 = dht.lookup(hash[1]); 
    // 
     abort_lookup_2(); 
     hash[2] = rand_string(40); 
     peers[2] = 0; 
     abort_lookup_2 = dht.lookup(hash[2]); 
    // 
     abort_lookup_3(); 
     hash[3] = rand_string(40); 
     peers[3] = 0; 
     abort_lookup_3 = dht.lookup(hash[3]); 
} 

setInterval(failedHash, 15000);

所以，我跑4個不同的查找並保持與> 100個同行。顯然這很少發生什麼，現在...如果我降低我的期望，說50個同行或更低，我顯然會得到更多的點擊，但喂哈希到Tixati導致要麼找不到同齡人或找到同齡人，但未能連接給他們（超時）。

我的問題如下：

這段代碼理智？我並不是說它是優雅的，但是有真正明顯的錯誤或者我忽略的東西嗎？
爲什麼我的torrent客戶端無法連接到似乎有對等設備的哈希對等體？（注意：我的torrent客戶端功能非常完善等）。我是否碰到一些奇怪的私人/阻止同伴？
什麼是最低數量的同齡人尋找？

我現在就離開這個跑在我的樹莓上，但我不期待太多;或者至少不是很長一段時間之前...

來源

2016-10-14 Franz René Kruhm

您的方法有缺陷。生成一個真正的info_hash的160位隨機數的機會是非常微小的，這是不可能的。你看到的命中是來自惡意節點，給你假同伴。 – Encombe

我知道這個可能性並不大，但是這就是爲什麼我通過設置最小數量的同伴過濾「噪音」。 –

的勝算並不大

這是輕描淡寫。僅僅將一個cpu寄存器從0增加到2 1-1將會是require more energy than it takes to boil all of earth's oceans。

對於人類目前可用的技術，DHT密鑰的暴力枚舉是不可能的。

目前，從DHT收集信息的唯一方法是監聽傳入的請求。這是相當低效和嘈雜，並不是人們想要在常規最終用戶機器上做的事情。在一臺服務器上，最好使用多個IP地址，您可以使用my implementation，它可以完成所有必要的繁重工作。

來源

2016-10-16 17:48:12 the8472

bittorrent-dht bruteforce散列發現問題

回答

相關問題