Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

[Feature Request] identify and filter some fake clients

by Guest on 2021/04/16 10:11:35 AM    
Hi, dear developers.

I got a peer who has made a fake client name:
Client name: Folx 5.24.13966
Peer ID: -LT10B0-????????????

As I know, Folx's peer ID is starts with -FL, -LT10B0- used by libtorrent (Rasterbar). Can you provide methods to ban them?

Thanks a lot.
by Guest on 2021/04/17 04:16:51 AM    
I'm sorry, above example is a mistake. I searched the Folx binary, it is true that Folx use libtorrent (Rasterbar), and can't found out any -FL string.

But the featrue request is true, I want ban fake clients. Thanks a lot, again.
by Guest on 2021/04/17 12:46:45 PM    
I'm not familiar with that client. Are they seeding back or only leeching? If you still want to ban it, add "-LT10B0-*" to the peer ID blacklist.
by Guest on 2021/04/17 02:11:08 PM    
this methode already exist, search in tixati setting, and in forum about Blacklist
by Guest on 2021/04/17 10:59:46 PM    
If you still want to ban it, add "-LT10B0-*" to the peer ID blacklist.
this methode already exist, search in tixati setting, and in forum about Blacklist
I know there is a blacklist, but it can not identify fake clients, if I set it to ban all "-LT10B0-*" peer IDs, most of bannd peer are not fakers.
by Guest on 2021/04/18 02:36:52 PM    
There are a lot of P2P spybot networks out there (in my opinion)

I would like to have a good discussion about this if possible?


THESE ARE 100% MY OWN FINDINGS. If you agree/disagree, please explain why, as I'd be delighted to explain my findings.


I have experienced and witnessed all of this myself using Tixati 2.81 - This isn't just copy-n-paste from anywhere else.



Possible TORRENT P2P SpyBot Snooping Networks/
BotNet  Host Provider   Bad Peer Client        BotNet type
======  =============   =====================  ================================================================
(01)    Amazon AWS      libtorrent 0.13.6      Clever setup and absolutely EXTENSIVE 150+ instances minimum
(02)    Contabo #1      MonoTorrent 0.0.0.8    Total giveaway very lazy setup
(03)    Contabo #2      Azureus 2.0.6          Utterly incompetent programmers (Terrible understanding of P2P)
(04)    FASTHOSTS UK    DelugeTorrent 1.3.6    < Fasthosts and NFOrce seemingly combined network
(05)    NFOrce    NL    DelugeTorrent 1.3.6    < Fasthosts and NFOrce seemingly combined network
(06)    DTEC-Softlayer  libtorrent/1.1.9.0     Self Declared AntiP2P company (Very obvious Peers)
(07)    COMFORTEL (RU)  Limewire 2.1.0         < joint network trading as SimpleCloud Russia
(08)    AirISP    (RU)  Limewire 2.1.0         < joint network trading as SimpleCloud Russia


All of the above AntiP2P implementations each have certain flawed 'characteristics' which enables them to be very easily spotted.

Is there anyone on here who can add anything to this?
by Guest on 2021/04/19 05:32:21 AM    
There are a lot of P2P spybot networks out there (in my opinion)
...
Is there anyone on here who can add anything to this?
I think most of P2P spybots were hosted on set network, ipfilter can process them.

My request is focus on fake clients leech.
by Guest on 2021/04/20 07:32:08 AM    
I'm pretty sure the fake clients already fake their peer id too.
by Guest on 2021/04/20 09:06:37 PM    
I'm pretty sure the fake clients already fake their peer id too.
Sure. But not all of them did that. And is there a good method to identify them?
by Guest on 2021/04/22 09:32:24 AM    
Sure. But not all of them did that. And is there a good method to identify them?

No. There isn't an absolute definitive way to identify fake clients like a binary 1 or 0.

I could easily fake my PEER-ID if I wanted to, even using Tixati this is easy, but I still participate in P2P so I am a good peer.
I've discovered multiple ways of identifying Spybots, as my other posts on this forum have shown P2P is being monitored by the increasingly desperate overlords.

Many spybots are easy to find because the muppets who send 'infringement notices' MUST contain an exact UTC time/date/IP/PORT of the alleged P2P activity.
All you have to do is run a few queries on the network and it reveals each connection logs in extensive detail including the SpyBot IP. We then block that /24 range to stop it happening again.


Anyway, peoples view on "fake clients" has to be clearly defined...

What IS a "bad peer" in your opinion? What behavior are you seeing exactly? - Since you've concluded it's not a SpyBot?
by Guest on 2021/04/22 01:04:00 PM    
So, we can not identify bad clients by ID. How about check their bad behavior?
by Guest on 2021/04/23 08:29:02 AM    
I have suggested several ways Tixati could identify bad and automatically deal with unwanted behavior.

I'm making a wish-list and if devs implement anything, some regular donations will be forthcoming haha! It's only fair?
Although this is only a hobby for me as I guess it always has been for the devs?

One of the main things i'd like is slightly more info in the "Event Log" tab on level 5+.
-Port numbers for DHT/tracker responses.
-Protocol TCP/UDP
-Encrypted or Plain
-Initial Bitmap pieces of LOCAL and PEER.
-Peer Client id and peer id

Maybe there can be another option level excluding 'pieces'  "6 - Max Info (minus piece transfer)"


I'd consider myself an expert at identifying bad peers. I've found 8 Snoop networks this year including what I think is "m_a_v_e_r_i_c e_y_e"
Some of these Snoopbot networks consist of 150 instances minimum PER bot. Some are so predictable and poorly implemented it's actually helped me identify their tactics.

I know this might sound 'sad' but I enjoy weeding out bad peers on Tixati nowadays far more than downloading any 'content'. If that makes sense. It's a challenge.

Tixati is an incredibly powerful if you know how to use the features.
My previous Feature Requests on the forum would all help identify the P2P abusers.




Tixati only really needs fine tuned to temporary ban or deprioritise some of the weird behavior I'm seeing.
I have Tixati logs, network logs, local WireShark logs. Everything possible to catch the unwanted behavior.

I've even broken down the protocol to byte level to understand this stuff. I've put a lot of effort in. I think I know what I'm doing and I'm getting the results I wanted.

100% Confirmed P2P SnoopBot - small scale
*** 23/04/2021 ***
[01:04:19]  created from incoming connection         <--- P2P connects to me. I have open ports on this 'bait' machine.
[01:04:19]  starting
[01:04:19]  receiving incoming connection
[01:04:19]  logged in
[01:04:19]  sent bitfield                            <--- He now knows I have 100.0% completion (REQUIRED to send me a 'notice')
[01:04:29]  error: Remote disconnected
[01:04:29]  stopping
[01:04:52]  starting
[01:04:52]  initiating connection                    <--- Tixati can't contact him back. He has closed/firewalled ports
[01:04:59]  stopping
[01:04:59]  starting
[01:04:59]  receiving incoming connection            <--- He comes back a second time.
[01:04:59]  logged in
[01:04:59]  sent bitfield                            <--- He now knows I have 100.0% completion (REQUIRED to send me a 'notice')
[01:05:09]  error: Remote disconnected
[01:05:09]  stopping
[01:05:31]  starting
[01:05:31]  initiating connection                    <--- Tixati tries to return connection to P2P snoopbot but he is deliberately firewalled.
[01:05:47]  error: Timed out connecting
[01:05:47]  stopping
[01:06:16]  starting
[01:06:16]  initiating connection
[01:06:33]  error: Timed out connecting
[01:06:33]  stopping
[01:07:04]  starting
[01:07:04]  initiating connection
[01:07:20]  error: Timed out connecting
[01:07:20]  stopping
[01:07:58]  starting
[01:07:58]  initiating connection
[01:08:14]  error: Timed out connecting
[01:08:14]  stopping
[01:09:19]  starting
[01:09:19]  initiating connection
[01:09:35]  error: Timed out connecting
[01:09:35]  stopping
[01:11:09]  starting
[01:11:09]  initiating connection
[01:11:25]  error: Timed out connecting
[01:11:25]  stopping
[01:15:27]  starting
[01:15:27]  initiating connection
[01:15:43]  error: Timed out connecting
[01:15:43]  stopping
[01:19:46]  starting
[01:19:46]  initiating connection
[01:19:58]  ignored
[01:19:58]  stopping, ignored                     <---Manual ignore in Tixati

WireShark:

37439382021-04-23 01:04:21.46561310.10.0.8x.x.x.196BitTorrent356Extended  Bitfield, Len:0x78  
37443222021-04-23 01:05:02.22023710.10.0.8x.x.x.196BitTorrent356Extended  Bitfield, Len:0x78  


37443012021-04-23 00:04:59.927830x.x.x.19610.10.0.8BitTorrent122Handshake 
 
0000   13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74   .BitTorrent prot       <--- 0x13 = 19 decimal bytes, starting '42' ending before InfoHash
0010   6f 63 6f 6c 00 00 00 00 00 15 00 00 IN FO HA SH   ocol............       <--- InfoHash edited out by me
0020   XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX   ................
0030   2d 4c 57 30 32 31 30 2d 35 38 63 36 66 39 39 30   -LW0210-58c6f990       <--- Spybot PEER ID (Identifying as LimeWire 2.1.0)
0040   XX XX XX XX                                       ....



Spybot networks are NOT in the same category as fakers.

Professional Spybots will NEVER have any files. They monitor 1,000,000+ torrents. They'd need PetaBytes of storage if they stored files or even partials.
I've NEVER witnessed a mainstream P2P Spybot transfer files (any direction) and I have a setup to capture everything from these people.

A Spybot network's purpose is ONLY this:

1) CONFIRM you're a real P2P client, Test your incoming port for instance (DHT or Tracker participation alone is absolutely worthless)
2) CONFIRM your CLIENT ID and PEER ID (handshake)
3) CONFIRM you're holding files - THEY check OUR Torrent bitfield (IE: "received bitfield, 1,234 of 1,234 pieces" = complete peer)
4) IF you PASS the 3 tests above you might get a boring infringement notice from the SpyBot owner.
5) In addition, TIXATI connects outbound proactively TO the Spybot which is an alternative PASS for check (1) above

HOWEVER:

If Tixati had a 'cautious' mode and we were a COMPLETE peer, we would RESPOND to new incoming connections OR initiate outgoing connections and declare our bitfield as either "0 of 1,000" or random "365 of 1,000"

This means the Spybot cannot complete their checklist above to issue you with a P2P notice.

TIXATI then checks the PEERs bitfield which Spybots are always 0 of 1,000 (etc)

IF the PEER has nothing (bitfield less than equivalent to 3% perhaps) TIXATI should be cautious and disconnect

IF that PEER we shunned was a Spybot - We didn't fall in the 'trap'
IF that PEER we shunned was a REAL PEER it will obtain initial pieces elsewhere, then come back with say "bitfield 123 of 1,000" and TIXATI says OK yeah I know you're real now, start upload/download.


I note from Tixati & WireShark Logs the peer NEVER sent his bitfield at all. Perhaps no need if we are "complete peer", hence Tixati must pretend to be a "partial" to obtain the peers bitfield first



FAKE PEERS / NUISANCE PEERS / TIMEWASTER PEERS
I'll post some logs about that strange behavior next time.

-Example where Tixati handled it well
-Another where it happened for 3-4 hours
by Guest on 2021/04/26 03:07:22 PM    
Very interesting. Thank you for sharing all of this.
by notaLamer on 2021/05/06 07:30:24 PM    
Possible TORRENT P2P SpyBot Snooping Networks/
Interesting discovery!
I too know about the MonoTorrent and AWS surveillance nodes invading upon privacy. In fact, the single MonoTorrent node creates as much DHT traffic as the entire AWS botnet (I have the entire AWS ASN banned).
The AWS guys are known to operate world-wide. I don't know who MonoTorrent belongs to, but due to German hosting their probably residing in Germany.

Guest, I would like you to contact me in Tixati User Group channel for further research. Anyone else can request the current AWS and other blocklists to somewhat up the privacy.
by Guest on 2021/05/13 06:14:22 AM    
I like the idea of blocking Amazon AWS as I think it's completely plausible that governments are using their services to track/snoop on torrents.
Conveniently, Amazon publish their always-up-to-date IP address ranges just as many other hosting providers do. If a hosting provider does not make public their IP ranges you could use BGP routing data made available by APNIC: http://thyme.apnic.net/. This data could also be used those DoD IP ranges that recently became announced.

Here is some code to fetch, parse and output Amazon IP ranges: https://paste.ubuntu.com/p/s6hCGmPhdB/
And here is the output of the above code: the contents of amazon-ip-ranges.txt when the program is executed: https://paste.ubuntu.com/p/9sfrH3nnyW/

After running this Amazon filter for around thirty minutes, it became clear that the filter was working as the addresses it was blocking weren't normal peers, but instead non-responsive addresses (they do not and have never responded to any connection requests) which I've noticed keep appearing from DHT for certain (possibly politically/police sensitive) torrents I have in my client.
Example of blocked addresses: https://i.imgur.com/kWki4Z8.png
After running the filter for thirty minutes: https://i.imgur.com/4wXLuV4.png




This web site is powered by Super Simple Server