[Nissenice]

Enig123, on 22 September 2012 - 06:45 AM, said:

Is it possible that it was caused by flawed clients?

I have observed log lines like this:

Quote

9/21/2012 9:42:07 PM: Ignored source (IP=112.80.xxx.xxx) received via source exchange - IP filter (CHN_Kad_Attack)

It looks like a real client.

Hi

Well, it's hard to say what goes for that particular client you have encountered. As I see it it's either a client used by the abusers to do some stuff related to a particular file, like checking sources, uploading and downloading status etc. Or it's simply a normal peer with an IP in a same IP range used by the abusers.

Personally I have these IP ranges blocked in PG2 so I haven't noticed that kind of statement myself. But all hits I have had from 112.80.132.0 - 112.80.139.255 the last days originate from the abusers attacking particular node IDs. They are not that many ([Edit] that is from IPs starting with 112.80 [/Edit]), but here are a few examples on attacked IDs found during searches:

2012-09-20 22:33:28: Kad: Out request for opcode 0x21 from IP 222.94.6x.127:14603  ID = CB2DEFA46F0074F386963B9A6156xxxx  v = 8
2012-09-20 22:33:28: Kad: Out request for opcode 0x21 from IP 112.80.13x.69:14605  ID = CB2DEFA46527E1F3994CFD5CA98Axxxx  v = 8
2012-09-20 22:33:31: Kad: Out request for opcode 0x21 from IP 122.96.12x.16:14602  ID = CB2DEFA4070D08E0636737229419xxxx  v = 8
2012-09-20 22:33:34: Kad: Out request for opcode 0x21 from IP 222.94.5x.83:14603  ID = CB2DEFA4144F703272C397946E78xxxx  v = 8

2012-09-20 23:11:18: Kad: Out request for opcode 0x21 from IP 114.97.7x.184:14660  ID = DFE539FFDBED67B9EBAF47EC6AA0xxxx  v = 8
2012-09-20 23:11:18: Kad: Out request for opcode 0x21 from IP 112.80.13x.58:14617  ID = DFE539FFD1BB4492A731A86DBB91xxxx  v = 8
2012-09-20 23:11:18: Kad: Out request for opcode 0x21 from IP 125.80.24x.65:14622  ID = DFE539FFF8F006C0EB890FFE301Bxxxx  v = 8
2012-09-20 23:11:24: Kad: Out request for opcode 0x21 from IP 112.80.13x.65:14606  ID = DFE539FF9910BCD4F93EE59F5951xxxx  v = 8
2012-09-20 23:11:26: Kad: Out request for opcode 0x21 from IP 114.97.7x.212:14634  ID = DFE539FFA5E6B99AF546380C7432xxxx  v = 8

2012-09-21 01:29:40: Kad: Out request for opcode 0x21 from IP 112.80.13x.84:14605  ID = 86BA02DAC830A4E08390534A6348xxxx  v = 8
2012-09-21 01:29:40: Kad: Out request for opcode 0x21 from IP 112.80.13x.221:14611  ID = 86BA02DAF85F4D863580A7F35192xxxx  v = 8
2012-09-21 01:29:44: Kad: Out request for opcode 0x21 from IP 117.14.15x.41:14609  ID = 86BA02DAF42F7581D9770895342Bxxxx  v = 8

2012-09-21 14:47:21: Kad: Out request for opcode 0x21 from IP 120.1.11x.235:14602  ID = 331893962FD17B28547D5D7FD719xxxx  v = 8
2012-09-21 14:47:21: Kad: Out request for opcode 0x21 from IP 222.94.5x.39:14683  ID = 331893966D31F7340EB562F13A26xxxx  v = 8
2012-09-21 14:47:17: Kad: Out request for opcode 0x21 from IP 183.128.21x.146:14601  ID = 3318939653BC1A43EA3833E3A924xxxx  v = 8
2012-09-21 14:47:28: Kad: Out request for opcode 0x21 from IP 110.240.15x.245:14601  ID = 331893965D36D33676BAD4FBBA05xxxx  v = 8
2012-09-21 14:47:42: Kad: Out request for opcode 0x21 from IP 123.117.18x.31:14623  ID = 331893965439FAE4BA3551FE7B75xxxx  v = 8
2012-09-21 14:47:44: Kad: Out request for opcode 0x21 from IP 112.80.133.1x:14840  ID = 331893962C8BC624CA4E9B37853Axxxx  v = 8

It is clear that IDs starting with CB2DEFA4, DFE539FF, 86BA02DA and 33189396 are attacked. I can't say if the IDs represent words or files yet, but I have seen many source requests for other IDs so it's possible that the attackers now are focusing more on specific files than keywords.

So generally speaking, I don't think this is caused by flawed clients, but your example may be a normal peer. But if I would make a guess based on the hits I've got from the ranges I have blocked I would estimate it that it's a 95% chance that it's a bad peer.

If you could find a way to match such a client you are mentioning to a file ID then it would be possible to check if that ID seems to be attacked. Only the first 4-5 first hex digits in the ID are needed to make a check if the ID may be guarded and attacked. The more digits the better, but on the other hand it also may reveal what file that would be, I mean if you would be thinking of posting about it..

This post has been edited by Nissenice: 23 September 2012 - 10:48 PM

[Nissenice]

Hi again!

I've updated the list with newly found IP subnets which the attackers have gain access to.
http://forum.emule-p...dpost&p=1074192

Also down below is a list with IP ranges they have been reported using in the past which also are used at the current. The list has been merged from hits found during the last days so there is a chance that other older reported ranges have been used a week or so ago too. I need to check older logs to find out whether or not that's the case... when I get time.

58.212.0.0 - 58.212.3.255

58.212.32.0 - 58.212.35.255

117.88.128.0 - 117.88.131.255

119.85.96.0 - 119.85.111.255		/* 23-Oct */

121.229.28.0 - 121.229.31.255		/* 23-Oct */

121.229.60.0 - 121.229.63.255		/* 23-Oct */

123.116.144.0 - 123.116.159.255

123.117.160.0 - 123.117.191.255

123.121.168.0 - 123.121.175.255

123.144.160.0 - 123.144.175.255

123.145.160.0 - 123.145.199.255

125.80.224.0 - 125.80.255.255		/* 23-Oct */

125.82.28.0 - 125.82.31.255		/* 23-Oct */

125.84.176.0 - 125.84.191.255		/* 23-Oct */

222.94.48.0 - 222.94.63.255

222.94.236.0 - 222.94.239.255		/* 23-Oct */

So far I've found approximately 130 attacked node IDs all over the Kad ID space [0000..0 - FFFF..F]. And I estimate that around 300-1000 IDs are attacked in total at the moment. Probably not less and probably not more.


A few examples of found attacked IDs starting with a zero and followed by 7 hex known digits matching the attacking nodes IDs first 8 digits. The rest of the IDs are unknown until we can find what file or keyword the ID corresponds to.

0286B728...
02D48473...
041DF07A...
0929E8ED...
0AA00275...
0AA32E4B...
0B2CF439...
0BC65E9F...
0CA5C055...


Edit: Added more ranges of IPs used in the past by the attackers and still in use from time to time. Marked '23-Oct'. (23 October 2012)

This post has been edited by Nissenice: 23 October 2012 - 09:19 PM

[Nissenice]

Enig123, on 22 September 2012 - 06:45 AM, said:

Is it possible that it was caused by flawed clients?

I hope you got the answer you asked for. Just to make myself clear: There simply is no chance that the behavior described in this thread is caused by flawed clients. The probability for that is zero! Nonexistent! All this is done on purpose by an opponent with huge resources and I guess there is no longer much doubt who stands behind it. Not to me anyway.





Another thing - a feature request. Perhaps not for the official client but maybe for mods.. A second IPfilter, a Kad IPfilter with the property that nodes with IPs in the list are not trusted by other kad clients for publishing and searching nor trusted to be added to their routing tables. Clients assigned to such untrusted IPs would still be able to search and publish information on Kad but they would not take part in the network. Nor trusted to be buddies. But still able to share files.

In the current situation the IPs already reported could be added to such a list and it would not harm normal users assigned to any of those IPs.

In the worst case all IPs in China could be included in the filter and then the Kad abusers can use as many IPs as they want to no avail - for them.

This post has been edited by Nissenice: 24 September 2012 - 02:13 AM

[Nissenice]

37 more /22 subnets found and added to the list of subnets used to attack words and fileIDs in the Kad network.
http://forum.emule-p...dpost&p=1074192

Nissenice, on 24 September 2012 - 12:06 AM, said:

So far I've found approximately 130 attacked node IDs all over the Kad ID space [0000..0 - FFFF..F]. And I estimate that around 300-1000 IDs are attacked in total at the moment. Probably not less and probably not more.

These figures were probably a bit too pessimistic. It's more likely that somewhere between 250 and 400 IDs are attacked at the same time.



I was asked about a week ago if the word Chinese word for Tiananmen was attacked. Afaik it wasn't, but I think it has been in the past.
A few days later I found that '六四' and '江泽民' were attacked and they still are. '六四' means 64 and alludes to the june fourth massacre on Tiananmen square. '江泽民' is the name in Chinese of Jiang Zemin. He became the general secretary just after the massacre.

Just a few hours ago '六四' was attacked by at least 6 nodes. Most of the time 4 nodes are found during a normal search, but sometimes there are only 2 and other times 8 or 10, but that is not so common.

六四 = 64. Key = 96C7ACF573FE7B0321B52FF8B0DA77A8

IP = 125.118.7.219:14661 ID = 96C7ACF5B5EB4FDDC38D2B58CF7D3012 v = 8
IP = 115.192.212.111:14674 ID = 96C7ACF5A3E97FFFBA838CC78403089D v = 8
IP = 112.66.3.123:14611 ID = 96C7ACF5BBE2F4931C5E3B5C3ABAEB9B v = 8
IP = 112.66.32.87:14610 ID = 96C7ACF596843660731BD29F0355178D v = 8
IP = 121.29.186.51:14701 ID = 96C7ACF5BE51E5B69E31F52BC4B18B0E v = 8
IP = 221.192.52.50:14706 ID = 96C7ACF5B66B34FA201228869B06A7D7 v = 8

And surprisingly '江泽民' was also attacked by at least 6 nodes.

江泽民 = Jiang Zemin. Key = 434DCAD88D209D696C5F2F0F3CD4448A

IP = 115.200.237.234:14609 ID = 434DCAD851FB609C30A16CBA37829A69 v = 8
IP = 112.66.50.138:14601 ID = 434DCAD8234550156F099104427C8265 v = 8
IP = 110.228.28.126:14602 ID = 434DCAD85A70C4BD39652F19E6006B58 v = 8
IP = 110.228.28.125:14604 ID = 434DCAD87D9C960E502C6160AD79F445 v = 8
IP = 112.66.11.72:14601 ID = 434DCAD87C7AF6DCE68C2E651EC4ABB2 v = 8
IP = 125.118.1.70:14611 ID = 434DCAD872C1BB48EC103088C11B257F v = 8

The IPs and IDs change over time. For example the second word was attacked by different IPs and IDs a few days ago. As can be seen here:

IP = 117.14.145.127:14605 ID = 434DCAD82516E7DCE79E71C73D80F9F0 v = 8
IP = 111.162.140.114:14604 ID = 434DCAD84A112CD569B5E551ECF50AE7 v = 8
IP = 111.113.94.113:14611 ID = 434DCAD83069E5E8B1EFF4C5D838E898 v = 8
IP = 111.113.231.101:14603 ID = 434DCAD872D6F82380F3C967A1F9A2D3 v = 8

This post has been edited by Nissenice: 05 October 2012 - 01:38 AM

[Nissenice]

More blocked Chinese keywords:

法轮大法 = Falun Dafa. Key = 1353B07318C27E27E4143FA87C572C5B

法轮功 = Falun Gong. Key = 6250DF719F76C704A81211F2F656860B

新唐人 = Tang Dynasti. Key = 24C9AF97F233BDD559E6A7A049D5F9BB

大纪元 = The Epoch Times. Key = 64B5BFF371233E48EDEEFC09FFBC3439

李洪志 = Li Hongzhi. Key = FA106D07B205E9020ACD431E65218367

李长春 = Li Changchun. Key = 70808800A9E4E390AD71C66D2E85F651

Sources:
https://docs.google....&hl=en_US#gid=0
http://www.conceptdo...g/badwords.html
http://en.wikipedia....public_of_China

[Enig123]

That's exactly what they are really trying to do, instead of those so called porn keywords.

[Nissenice]

Enig123, on 06 October 2012 - 04:50 AM, said:

That's exactly what they are really trying to do, instead of those so called porn keywords.

Yep, the dragon is showing its true face. I've found a few more blocked words and none has to my knowledge anything to do with porn. I suspect though that most blocked IDs represent files. One of those files contained the Chinese word for sixty-four in the title and it seemed to be some documentary or news about the events at Tiananmen square.

The list with newly found IPs used by those attackers has been updated with 73! subnets. http://forum.emule-p...dpost&p=1074192

They get new IPs faster than I can type them down...

This post has been edited by Nissenice: 17 October 2012 - 11:52 PM

[Nissenice]

The list with subnets containing newly found IPs used by the attackers has been updated:

http://forum.emule-p...dpost&p=1074192


And so has the list with subnets with old IPs found almost a year ago or earlier which are still used.

http://forum.emule-p...dpost&p=1074287


And some bad news.. Looks like the attackers have started to position nodes all over the network. Not sure what this is all about yet, but maybe they are trying to intervene in the searches at an early stage. Or maybe its purpose is about logging?

These have been found during 10-20 random searches. In other words these nodes are in other peers routing tables. I would have had at least one myself if it wasn't for the fact that I have these IPs blocked...

IP = 175.17.197.212:31651  ID = 8544C400000000000000000000000000  v = 8
IP = 221.207.34.134:31651  ID = 64E49C00000000000000000000000000  v = 8
IP = 175.184.163.215:31651  ID = 66E63E00000000000000000000000000  v = 8
IP = 123.144.162.189:31651  ID = 1FBF1600000000000000000000000000  v = 8
IP = 123.144.162.180:31651  ID = 1FBF1A00000000000000000000000000  v = 8
IP = 123.145.196.140:31651  ID = 1FBF4200000000000000000000000000  v = 8
IP = 175.184.161.64:31651  ID = 60806600000000000000000000000000  v = 8
IP = 182.119.231.86:31651  ID = CB778000000000000000000000000000  v = 8
IP = 175.184.160.44:31651  ID = 60807A00000000000000000000000000  v = 8
IP = 218.10.63.51:31651  ID = 7265FA00000000000000000000000000  v = 8
IP = 182.119.230.229:31651  ID = CD9E7400000000000000000000000000  v = 8
IP = 111.162.139.198:31651  ID = 94DC6600000000000000000000000000  v = 8
IP = 124.88.55.54:31651  ID = AC43EA00000000000000000000000000  v = 8
IP = 218.10.62.69:31651  ID = 72DE3C00000000000000000000000000  v = 8
IP = 218.10.63.200:31651  ID = 72DE5400000000000000000000000000  v = 8
IP = 218.10.62.203:31651  ID = 72DE1E00000000000000000000000000  v = 8
IP = 123.117.186.82:31651  ID = 0DF50000000000000000000000000000  v = 8
IP = 123.117.186.200:31651  ID = 0DF5B600000000000000000000000000  v = 8
IP = 115.200.237.201:31651  ID = EE00FE00000000000000000000000000  v = 8
IP = 183.184.27.229:31651  ID = 3D02E600000000000000000000000000  v = 8
IP = 115.204.89.73:31651  ID = EE00E800000000000000000000000000  v = 8
IP = 183.184.29.230:31651  ID = 3A153A00000000000000000000000000  v = 8
IP = 183.185.226.194:31651  ID = 3A150E00000000000000000000000000  v = 8
IP = 112.66.91.185:31651  ID = F57D4C00000000000000000000000000  v = 8
IP = 112.66.67.195:31651  ID = F25B2600000000000000000000000000  v = 8
IP = 183.184.30.155:31651  ID = 34C51400000000000000000000000000  v = 8
IP = 118.81.238.205:31651  ID = 34C56400000000000000000000000000  v = 8
IP = 221.207.32.10:31651  ID = 6D727400000000000000000000000000  v = 8
IP = 221.207.33.112:31651  ID = 6D720A00000000000000000000000000  v = 8

This post has been edited by Nissenice: 24 October 2012 - 03:47 PM

[Nissenice]

The list with IP-ranges which the attackers have access to has been updated and cleaned.

http://forum.emule-p...dpost&p=1074192


Me thinks they must have some screws loose.

[Nissenice]

The IP-list was updated yesterday.

http://forum.emule-p...dpost&p=1074192

[fox88]

Nissenice,
do you see unusually high number of banned clients during attacks?

[Nissenice]

fox88, on 21 December 2012 - 05:40 PM, said:

Nissenice,
do you see unusually high number of banned clients during attacks?

Well, no. I haven't noticed with the modified client I'm studying Kad with. Maybe because this eMule doesn't upload or download anything. It's only running Kad. The only new things I have spotted in its verbose log apart from statements related to the attacks is:
'Client UDP socket: prot=0xe4 opcode=0xde sizeaftercrypt=35 realsize=35 Unknown opcode de'
'Client UDP socket: prot=0xe4 opcode=0xdf sizeaftercrypt=35 realsize=35 Unknown opcode df'


I'll have a look at my wifes computer where the regular client is running under her supervision as soon as she can move her bum away from it.

Why are the clients you are mentioning banned? Aggressive behavior? Or is it related to Kad?


The attacks described in this thread basically have been running 24/7 for many months now. Sometimes with more intense so that about 10 attacking nodes are inserted in the network to block an ID compared to the more normal state when 4(-6) nodes are used.

This post has been edited by Nissenice: 22 December 2012 - 02:17 PM

[fox88]

Thanks for the answer. I already posted in other topic a while ago appalingly high numbers of banned clients in my eMule.
See here.
That was kind of "all time best".
It varies; sometimes very few, sometimes not quite so. At the time of my previous post I had 18 banned, 19 downloading, 0 in queue.

Nissenice, on 22 December 2012 - 05:09 PM, said:

Maybe because this eMule doesn't upload or download anything.

That means you see only part of the whole picture.

Nissenice, on 22 December 2012 - 05:09 PM, said:

Why are the clients you are mentioning banned? Aggressive behavior? Or is it related to Kad?

22.12.2012 19:08:04: Kad: Request flood detected for opcode 0x21 (0x21) from IP 119.118.164.* - Droping packets with this opcode
22.12.2012 19:08:04: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 119.118.164.* - Banning IP

22.12.2012 19:14:36: Kad: Request flood detected for opcode 0x21 (0x21) from IP 190.135.130.* - Droping packets with this opcode
22.12.2012 19:14:36: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 190.135.130.* - Banning IP

22.12.2012 19:17:35: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 37.11.72.* - Banning IP

I do not save logs all the time. Just turned the saving on and see what I got in less than 10 minutes: China, Uruguay and Spain.

This post has been edited by fox88: 22 December 2012 - 07:16 PM

[Enig123]

fox88,

These banning is related to a mod named VeryCD or easyMule, which has 'tweaked' kad a little bit to become more aggressive. I don't think it's related to the kad attack Nissenice have mentioned.

@Nissenice
Unknown opcode de & df may originated from a bad multi-protocol client named xunlei, I need to check to confirm though.

[Nissenice]

The list with IP-ranges used by the Chinese attackers has been updated.

In my next post I will present the attacked IDs I know of so far, nearly 300 of them. Last weekend starting at friday every one of these IDs was attacked by 15-20 attacking nodes. This means that not only searches for the attacked words and files was suffering. Also searches for words and files etc in the attacked IDs neighbourhood suffered as well.

IP-LIST: http://forum.emule-p...dpost&p=1074192

fox88, on 22 December 2012 - 04:40 PM, said:

Thanks for the answer. I already posted in other topic a while ago appalingly high numbers of banned clients in my eMule.
See here.
That was kind of "all time best".
It varies; sometimes very few, sometimes not quite so. At the time of my previous post I had 18 banned, 19 downloading, 0 in queue.

Yeah I've noticed those banned clients as well, but I think they are Xunlei clients.
First time I noticed them was a couple of years ago and to me it seems that the number of them depends on the files you are sharing. The more files you are sharing which they find interesting the worse it gets.
I also believe they have found (or they think they have) something in the eMule behavior which can be exploited to their own advantage. For example some, not all, of these Xunleis (xlbuilds) asks for another files quite so often. Sometimes up to 10 times per hour. I suspect they do this because they are trying to get advantages when other peers disconnects and connects their clients. Simply, they want to get ahead in those clients queues. They are not Chinese blodsucking vampire asses for nothing...

I belive the instructions for this type of client goes something like this:

Join a peer's waiting queue to download a wanted file.
Check with the vampire ass community if the peer is sharing another files.
If so use ask for another files every 6-10 minutes to check that the peer is still online.
If peer is offline increase the attempts to open a connection every 2-3 minutes until the peers get online or abort when a certain time has passed.
When the peers get online, enjoy position in either waiting or uploading queueu. (Eventually, report to vampire ass community (or part of) that peer is online again.)

One can actually see how aggressive some of these clients get when their IPs are blocked in filters.
It has gone a couple of years since I looked a little at this so I can't remember why they sometimes actually are banned for aggressive behavior

fox88 said:

22.12.2012 19:08:04: Kad: Request flood detected for opcode 0x21 (0x21) from IP 119.118.164.* - Droping packets with this opcode
22.12.2012 19:08:04: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 119.118.164.* - Banning IP

22.12.2012 19:14:36: Kad: Request flood detected for opcode 0x21 (0x21) from IP 190.135.130.* - Droping packets with this opcode
22.12.2012 19:14:36: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 190.135.130.* - Banning IP

22.12.2012 19:17:35: Kad: Massive request flood detected for opcode 0x21 (0x21) from IP 37.11.72.* - Banning IP

I do not save logs all the time. Just turned the saving on and see what I got in less than 10 minutes: China, Uruguay and Spain.

When it comes to request floods I agree with Enig123. These are 'normal' Chinese clients spread all over the world, but mostly used in China. I wouldn't be surprised if its Xunlei - Thunder - xlbuild in this case also. But it might be another client as well. There are more than one vampire ass.

What these clients do is intentional, well perhaps not the banning part... As it seems to me, what they are doing, is sweeping the neighbourhood for the closest nodes to a target ID. I've seen a couple of different variants of this theme. One variant goes about like this: The first kademlia request ask for the closest nodes to a target T' relatively close to the real target T and then for every request thereafter T' is closing in to T like that T' is converging towards the real T. The effect of this when it comes to the official client is that the responsing node responses with the same closest nodes over and over again. Well, maybe if one exclude the first two requests which may return different nodes.
After 10 such rapid requests the official client starts to drop (not responding) to those reguests and after 50 the requesting node's IP gets banned.

As far as I can remember this behavior could be seen long before the current Kad attacks started. So, no, I haven't related this to the attacks. I think it's merely a vampire ass behavior. (They want the best and as they are cheating themselves they treat everyone else like they are likewise cheaters.)

Enig123, on 22 December 2012 - 07:29 PM, said:

@Nissenice
Unknown opcode de & df may originated from a bad multi-protocol client named xunlei, I need to check to confirm though.

Ok, thanks! Must be a new release then as these statements haven't been around for long in the verbose.

This post has been edited by Nissenice: 15 January 2013 - 07:13 PM

[Nissenice]

Continued from post above.

Ok here are 288 IDs which are under attack. I guess this is at least 90% of the IDs which have been attacked for a while. There are 20-30 more IDs which have been attacked as well, but not for the last 2 months or so. I believe those belongs to another attacking group - Chinese of course. The difference has been that this 2nd group has acted more strict and always used 4 attacking nodes for each target. Also, they have been faithful to a few IP-ranges and not jumping around like maniacs all over the place.

The list down below shows the initial 8 hex digits in each attacked ID. It also matches the initial 8 digits in the attacking nodes IDs for the same attacked ID. In those cases the full attacked ID is known its presented as well along with the Chinese word and its translation if the attacked ID represent a keyword. If it is a file then the ID, extension and blocked word in title are presented. (There might be more words in the title.)

I have no other information about the files so about the content I can say nothing. It could be anything. But, I believe many of them are videos showing what happened on Tiananmen square 1989.

I have found more keywords and files than these so this list will be updated... in time...

ID=022203CE
ID=0286B728
ID=041DF07A
ID=0587F13C
ID=05BF449E
ID=0929E8ED		0929E8EDE43952954590417660BE07B0	file: .rmvb,	title: 九评
ID=0AA00275
ID=0AA32E4B
ID=0B2CF439
ID=0B907214
ID=0BC65E9F
ID=0D147903
ID=0DF86882
ID=0F9A9E4C
ID=0FAB26CC
ID=10E64C2D		10E64C2D3A7BAB160E55D93B6FFC53F1,	file: .rm,	title: 六四
ID=10F9E4DB
ID=122A9B28
ID=1345707D		1353B07318C27E27E4143FA87C572C5B	word: 法轮大法 = Falun Dafa
ID=1353B073
ID=16E62A0B
ID=17427BE0
ID=1968504F
ID=1A3B89EA
ID=1DD7441C
ID=1E4B6FBF
ID=1E5AC982
ID=1E7B593F		1E7B593FE40ABB43EF5C264150E2234F	file: .flv, 	title: 六四 温家宝 法轮功 江泽民 胡锦涛
ID=1EAA7827
ID=21447CFB
ID=2199AAB5
ID=21C713F0
ID=225D7798
ID=23D15ECA
ID=24C9AF97		24C9AF97F233BDD559E6A7A049D5F9BB,	word: 新唐人 = Tang Dynasti
ID=25C93ADC
ID=27A766FF
ID=284FE95E		284FE95E5074DF7FE09CC632F67F72D9	file: .rm,	title: 六四
ID=292013BF
ID=293E09C7
ID=2948B5F7
ID=2994849D
ID=2ABA079B
ID=2B4043C6
ID=2B532A88
ID=2B8656B2
ID=2BA4AD9D
ID=2C191DFF
ID=2D29953D
ID=2E13E885
ID=2E3C4A5D
ID=304D9A9D
ID=311EC1CE
ID=33189396		3318939687E131C9FB9EA09AA00B4CC7,	word: 胡锦涛 = Hu Jintao
ID=34834378
ID=348DD4E9
ID=349F7128
ID=3544BB0E
ID=35701938
ID=367C2DA9
ID=38393581		38393581E487A8FDD91741B2058EA04C,	file: .avi,	title: 六四 温家宝 法轮功 江泽民 胡锦涛
ID=3853CD83
ID=390A8A49
ID=39FD0B82
ID=3AC8E8BE
ID=3C859D5B
ID=3CF1733F
ID=3D52BAAF
ID=3D7ED869		3D7ED86901AA7631C1A357EA5FF28C3D	file: .rmvb,	title: 六四
ID=3EEA2026
ID=3F0AD24E
ID=3F1071D8		3F1071D864C113B32CB5A53389248408,	file: .rm,	title: 六四
ID=3F1479B5
ID=3FA4F8F6		3FA4F8F6D1026D696B0E3EB619FDFD00,	word: 温影帝 = Climax (??)
ID=3FA78C67
ID=3FC15DC0
ID=40A664C0		40A664C0D5F86D20DABC16E4F9D998B0,	word: 九评 = Nine Commentaries
ID=40C243DF
ID=418AC9C3		418AC9C37D0530C2F2FF3B98E55400EE,	file: .rm,	title: 六四
ID=41CDC5AB
ID=4262D044
ID=43282814
ID=4328F0C9
ID=4329D75B
ID=434DCAD8		434DCAD88D209D696C5F2F0F3CD4448A,	word: 江泽民 = Jiang Zemin
ID=47AE98B5		47AE98B5F53D9DA36B04F7A1C98946CC,	word:	团派 = Tuanpai
ID=47C413AF
ID=47DF972C
ID=48D29F93
ID=4A7871C5
ID=4A86F3AC
ID=4ABB6135
ID=4BFECFAB
ID=4C65179B
ID=4D004C7B
ID=4D2D50EF
ID=4F34E1E8
ID=50B1BCE9
ID=50B69009
ID=5110FACA		5110FACA3B1DFE7A218A6F065924FFB7,	file: .mpg,  title: 六四
ID=51BD298C
ID=522620DA
ID=52681449		526814495D7C1423CA49F2D5D3ADE5CD,	word: 迫害 = Persecution
ID=5346B80D
ID=536FEFB2
ID=53AC03C7
ID=545E172E
ID=545F5C59
ID=54FBCD32
ID=57294ECA
ID=594ED7ED
ID=599ACB56
ID=5A3B2446
ID=5FBAE444
ID=5FF68546
ID=5FFC218D
ID=612E0AB2
ID=61D04F89
ID=6250DF71		6250DF719F76C704A81211F2F656860B,	word: 法轮功 = Falun Gong
ID=63A9BC7C
ID=643919E0
ID=64B5BFF3		64B5BFF371233E48EDEEFC09FFBC3439,	word: 大纪元 = The Epoch Times
ID=64F6F1F8
ID=66538C5D
ID=669FB8EF
ID=66B7DE23
ID=6701AE97
ID=68FCD421
ID=695C70B9
ID=697B5415
ID=69A41F5B		69A41F5B4C3DD44297613DE7B892FD3B	file: .rmvb,	title: 六四 
ID=69D2D7C0
ID=6A115138
ID=6AE889B7
ID=6CC6F439
ID=6CD57C0C
ID=6E9CB825
ID=6F06F5BA
ID=6FB3FDA0
ID=70221EE8
ID=70808800		70808800A9E4E390AD71C66D2E85F651,	word: 李长春 = Li Changchun
ID=72911734
ID=729A9389
ID=72CDD0EA
ID=73A708CD
ID=7502FB9A
ID=758A44F2
ID=75B0ADD6
ID=771DCDDE
ID=777B6971
ID=79418FB5
ID=7B57C177
ID=7B780F02
ID=7D78B6CB
ID=7DC34A53
ID=7EFE91E9
ID=808B3F82
ID=823046B0
ID=841BBBBF
ID=844120EE
ID=85EBA2B6
ID=86BA02DA
ID=87CEEE81		87CEEE8157983BF51072F6C3F6311DC1	file: .rmvb,	title: 六四 温家宝 法轮功 江泽民 胡锦涛
ID=87FAD8CB
ID=880210FF
ID=88C4BC71
ID=89F1AE15
ID=8BF1D6E8
ID=8E53632F
ID=8F8BE558
ID=9099DC23
ID=91CA3554
ID=91EA672A
ID=9225B67C
ID=935FC045
ID=940A4451		940A44515AADF89FAE316057A3BB8AD1,	word: 温家宝 = Wen Jiabao
ID=96B63E67		96B63E6783B19B72B1B79D2C690FDB0F	file: .wmv,	title: 六四 温家宝 法轮功 江泽民 胡锦涛
ID=96C7ACF5		96C7ACF573FE7B0321B52FF8B0DA77A8, 	word: 六四 = 64
ID=97C80A28
ID=98AA04AB
ID=9946115A
ID=99E11151
ID=9A6AA947
ID=9AF1A713
ID=9B3E6E87
ID=9CD0226D
ID=9D6A53B9
ID=9EC4DEAE
ID=9EF70DBA
ID=9F2228E5
ID=A0BC3A5B		A0BC3A5BE4D408F4A535987E9FDECEB5	file: .mp4,	title: 六四
ID=A1EEBECB
ID=A3892AC4
ID=A3EC01E8
ID=A403C253
ID=A42C736D
ID=A42ED606
ID=A5998FD5		A5998FD5A8FAFA88EA9CC95772B5398D,	word: 习近平 = Xi Jinping
ID=A5D1F79F
ID=A727B833
ID=A876978D
ID=AABFBDFE
ID=ABFBA492
ID=AEEADD03
ID=AEFCA270
ID=B0966C24		B0966C24D0AA3F37B4B84B598ACD7C3D,	file: .rm,	  title: 六四
ID=B09BB187
ID=B349F855
ID=B45E560D
ID=B572FAD1
ID=B6D6D980
ID=B87B613C
ID=B87D0691
ID=B8CA0C17
ID=B9059557
ID=B90733CC
ID=B939D579
ID=BAFEF073
ID=BB9ACD8B
ID=BCC75242
ID=BF795BF4
ID=C2968D27
ID=C2B0E3DB
ID=C3516312
ID=C813F0F8
ID=C8FA9F9C
ID=C96ADBD5
ID=C9C6607F
ID=CB2DEFA4
ID=CC2697E1
ID=CC909A69
ID=CEC3EF97
ID=CEE89255
ID=D209304F
ID=D26B8EA5
ID=D3574F5F
ID=D38C2E0F
ID=D3C14AF2
ID=D57A49A6		D57A49A633EB00FDB4455FA832F4C91C,	file: .rm,  title: 六四
ID=D6CD48B5
ID=D70FC487
ID=D77BAB27
ID=D9C30699
ID=DA17B466
ID=DBA0A950
ID=DC1573E1
ID=DC41FBD6
ID=DCB76E93
ID=DCF4164A
ID=DD451E48
ID=DFB02D09		DFB02D09801F9A2B96579FA18BA9F12A,	word: 退党 = Quit the party
ID=DFE539FF
ID=E0E2FF97
ID=E1BABD2A
ID=E2007B81
ID=E20FF11A
ID=E27C493A
ID=E423350B		E423350B55C4C9228D582CE8386A2686,	file: .avi,	 title: 六四
ID=E5D4B20C
ID=E5DB9010
ID=E64680E3
ID=E6F7FDDE
ID=E76EB721
ID=E874438D
ID=E8A4DDA5
ID=E9554583
ID=E96EE2F2
ID=EB51F361
ID=EC1A7F71
ID=F066493F
ID=F11AC707
ID=F16CBB56
ID=F26CF957
ID=F4725FD1
ID=F50530BB
ID=F535EB8F
ID=F5755FF6
ID=F6912A8E
ID=F94414AB		F94414AB13F966F5320F00DEF42EEDF3,	word: 李克强 = Li Keqiang
ID=F94DCB5D
ID=FA106D07		FA106D07B205E9020ACD431E65218367,	word: 李洪志 = Li Hongzhi
ID=FA11C935
ID=FAA6A307
ID=FB2B26B7
ID=FB9FCD2D
ID=FDD0C115		FDD0C115918623C585B5001AFB0918BC,	file: .rmvb,	title: 六四
ID=FFD2220E
ID=FFF422F2

EDIT: Updated with several words and files.




Now anyone who wants to can check these IDs against their list of Kad contacts. Just go to Kad page and sort the contacts by IDs and compare. The closer your KadID is to an attacked ID the higher is the risk that some attacking nodes have managed to find their way into your contactlist. Likewise if you are running 24/7 with same IP and port. Likewise if sharing or searching files whose ID are under attack and probably most definitely if you live in China.

In fact, some Kad peers have 10 of these bastards in just one bin. That is, if they look at their sorted list of contacts they will find 10 consecutive contacts under and above each other with IDs starting with the exact same first eight hex digits. Some of them are using the latest official client.


PS. There is a slight mathematical chance that a single normal and honest peer's ID starts with the same ID as an attacked ID, though the chance isn't big. Well, more than one then? No way!

This post has been edited by Nissenice: 22 January 2013 - 03:00 AM

[Ejack79]

Apparently it's a politics-oriented attack.
The gunverment doesn't want the shitizens to know too much.
So in a forseeable future, the attack will be sure to continue...

[Enig123]

Is there a way to minimize this kind of attack aside for ipfiltering the corresponded ips? Any ideas?

[Nissenice]

Ejack79, on 17 January 2013 - 02:29 AM, said:

Apparently it's a politics-oriented attack.
The gunverment doesn't want the shitizens to know too much.
So in a forseeable future, the attack will be sure to continue...

Yep, that's my opinion as well. They will not go away voluntarily, no matter how long we are holding our breaths or how deep we digging our heads down into the ground. I even doubt we have seen the attack in its full scale yet. Feels more like they are beating the grass to startle the snake.
Most probably they will try to strike against every unwanted P2P network reachable from China.

Enig123, on 17 January 2013 - 02:36 AM, said:

Is there a way to minimize this kind of attack aside for ipfiltering the corresponded ips? Any ideas?

Yes, there are, but personally I think Some_Supports idea about excluding Chinese IPs (or maybe a subset?) from routing and indexing dutys. That is, Chinese peers are only allowed to search and publish in the network. Thus they are not trusted to route requests nor indexing files and keywords.

Other things that can be done is for example:

Not using the true ID, but an obscured ID while sending Kademlia2 requests. Any ID sufficiently closed to the true ID can be used. Of course the true ID is used when the search/publish request is sent.
Last time when I looked the attacking nodes only responded to true IDs. But I'm afraid the gain would turn out to be shortlived as these nodes most probably start to respond to all or sufficiently close requests.

Another idea is to calculate where the expected closest normal node could be found and then using this node's expected ID while searching. And then again the true ID is used when search/publish requests are sent. This would actually be devastating against their current strategy, because most of the time their attacking nodes are no longer the closest nodes to searched ID.
Basically they can say goodbye to 100% effectiveness in their attack and they need a lot more resources. The drawback is that their attackaing nodes have to mingle among the normal nodes... So they must start to interact in every search in the neighborhood and this may have a serious effect on other searches. But on the other hand they have to act as normal nodes as much as possible. Otherwise it might look suspiscious.

Generally one can say that there is a no win / no win situation here. As soon we start with countermeasure their system will loose in effectivity and they will need more nodes which in turn will affect Kad network and so on.

Finally, one can wonder how safe their own system is against attacks. Judging from their bahavior so far I doubt they have given it a single thought.
But hey, we are the good guys. Arent we?

[Nissenice]

The ID-list has been updated with more complete IDs and what they represent.
http://forum.emule-p...dpost&p=1076657


The IP-list has likewise been updated.
http://forum.emule-p...dpost&p=1074192