Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   LimeWire+WireShare Tips and Tricks (https://www.gnutellaforums.com/limewire-wireshare-tips-tricks/)
-   -   Security packages for LimeWire (help block out the spam and evil hosts) (https://www.gnutellaforums.com/limewire-wireshare-tips-tricks/101885-security-packages-limewire-help-block-out-spam-evil-hosts.html)

Lord of the Rings February 21st, 2013 03:09 AM

Security packages for LimeWire (help block out the spam and evil hosts)
 
Rather than split the thread, I've decided to simply point to the posts in the thread that are related to the topic. :)

Security packages for LimeWire (help block out the spam and evil hosts)


Download links for the LimeWire Security Updaters: (choose appropriate version for your system and your choice of security from the folders. Feel free to Bookmark any of these links to periodically check for updates):

* LimeWire Security Updater installers via MediaFire *

* LimeWire Security Updater installers via SaberCat *

Do not choose the Full-Japanese block version unless you really have a need to. Otherwise you will be restricting your connection and download/sharing options. ie: Choose the Standard version instead (NJ).



So hopefully more people become aware of what hostile hosts really are and make some effort to protect and block from them. These hostile hosts and spammers break so many laws in most countries in the world. So who is going to send them all to 25 years in jail for their premeditated and well planned assault on the world for spreading of dangerous virus, DDoS attacks, trying to prevent people using the internet at all, trying to prevent your freedoms in life in any way they can. Even when no copyright material is concerned.


Like Oscar Pistorius, shoot first, second and last and get a good excuse later. Seems the DDoS attacks are like the bloodied cricket bat (heavier than a baseball bat) Pistorius used to smash Steenkamp's skull (Steenkamp’s skull was “crushed” .) Hello Hostiles and spammers, DDoS attackers of the innocent 10 year olds, innocent 75 year olds, do you really feel good smashing their life? Does it make you feel good? Get paid well for doing this?

Lord of the Rings March 26th, 2013 09:39 AM

I have not heard from the Phex dev for a very long time. So I am making my own call here.

If you see a Phex version specifically Phex 3.2.0.102 then boot it off your connection list. I have seen far too many of these over very recent past. Absolutely no reason for anybody to be using such an old Phex version below 3.4, so to see so many of them with identical version reminds me of these: Spam sample 1, . . Spam sample 2, . . Spam sample 3, . . Spam sample 4, . . Spam sample 5, . . Spam sample 6.

Edit: 4 April:
Came across a few files of spam by same person. Browsed them and they were sharing over 700 legitimate files with 6 pieces of spam. I am not going to add this host to the block list. It seems to me this is a fairly new user to the network who has downloaded the spam by accident, both audio and video spam and one spam document. Perhaps some might disagree with my decision but I do try to find out if hosts are deliberate spammers or accidental. I have come across accidental downloaders and sharers of spam before, so I need to keep making this kind of decision. I thought I should give an example to show a part of my approach. I can understand how this person was duped.
Had they been using LW 5 / LPE then perhaps some of those files might have been auto-deleted after they finished downloading them if any of those files were on the LW 5's known virus spam file list. (I just never understood why this in-built tool of LW 5 did not make the decision to stop and delete the file very early on in the download process instead of when the file had totally 'finished' downloading.)

Lord of the Rings May 1st, 2013 02:23 AM

1 Attachment(s)
From the next update of the security list:

Since the USA Government refuses to take any action against the illegal actions of the DDoS or Virus spreading companies and turn a total blind-eye on these "illegal" actions despite it contravening USA's own laws let alone international laws, I have decided to ban a freshly discovered USA criminal investigation group. The Gnutella network has been under enough pressure in recent years and does not need this unnecessary crap. And any results of theirs would be used purely for propaganda as history has shown. Fining grannies for downloading something for their grandchildren. I hope you lot (the riaa, etc.) get a high on doing that kind of thing. jerks! Oink! Oink Oink; When Pigs Fly: The Death of Oink, the Birth of Dissent, and a Brief History of Record Industry Suicide. :D

Until the USA Government wakes up and steps aside from the Mafia influences of high paying businesses (ie: their secret donations to the government parties), and until they stop blackmailing other countries to change their laws to suit these businesses with country to country trade at stake, I will continue to ban such groups. There are too many hypocrisies involved when it comes to the USA Government.



(Since when would the rest of the world want USA laws, a country where 'innocent' people whom are not of white descent be keenly hammered to the ground by their police simply because the police were prejudiced. A country where the rich turn a blind eye to the poor without offering a single cent to help and let them starve to death or die due to no chances of medical assistance when needed. Wake up USA, the rest of the world does NOT need your hypocritical laws. A close look at the USA shows a horrible, ugly hypocrisy.)

(If not added already, I will also add some of the recognised anti-torrent attackers. Fresh downloaders of L versions will already have 'some' of these updates including the above.)

Lord of the Rings December 5th, 2015 03:32 AM

I've released an update to the LimeWire Security hostiles. This update fixes many errors that existed when I first converted the BearShare equivalent to CIDR format to use for LimeWire. The only effect the errors had was LimeWire would ignore those listings. Many thanks to ale5000 (a GWebC developer) for researching and finding these errors. :xirokrotima:
There's also been both additions and removals of hosts. Some ranges have not seen hostile hosts for 5 or more years.

h4x5h17 December 5th, 2015 10:50 AM

Cool as hell, Lord'o'rings!

h4x5h17 December 5th, 2015 10:52 AM

Can this list be used with Phex and Frostwire(4.21)?

ale5000 December 5th, 2015 11:33 AM

For those that do NOT already know I will add the distribution of the blocklists directly from the Skulls GWC, and it will work with all P2P app (not from the start but I will add support for other apps from time to time); I have taken the idea from the unofficial mod at 4octets.co.uk.
If someone have a decent server it could help by hosting it and report bugs.

ale5000 December 5th, 2015 04:54 PM

I have checked the strong list without full Japanese block and I have found 2 errors:

1) 200.19.192.0//19

2) Start IP do not match.
CIDR Range: 58.13.232.40/28
Wildcard Bits: 0.0.0.15
Start IP: 58.13.232.32
End IP: 58.13.232.47

Lord of the Rings December 6th, 2015 01:04 AM

Quote:

Originally Posted by ale5000 (Post 376975)
I have checked the strong list without full Japanese block and I have found 2 errors:

1) 200.19.192.0//19

2) Start IP do not match.
CIDR Range: 58.13.232.40/28
Wildcard Bits: 0.0.0.15
Start IP: 58.13.232.32
End IP: 58.13.232.47

Thanks. I'll re-update asap.

Lord of the Rings December 6th, 2015 01:11 AM

Quote:

Originally Posted by h4x5h17 (Post 376973)
Can this list be used with Phex and Frostwire(4.21)?

It appears this is not possible for FrostWire. The program is hard-coded to create a special file called hostiles.dat that forces the program to check the hash of the hostiles, if it does not match the one downloaded then it will re-download it (via torrent) & replace the one you put into place. The hostiles FrostWire would download has not been updated for some years (not sure how many years, perhaps between 4 to 5.)
Edit: it appears the hostiles torrent has now become inactive, which means you are left with zero hostiles.
I can't remember when FW started using this approach but the hostiles should work with the earlier versions. I did test this some years ago but cannot recall the latest FW version a standard hostiles file can be used.

Using any of the hostiles I linked to above should definitely put less load on the FW program.

Phex? I've never been able to get the hostiles (even the BearShare version) to work with Phex, though a few years ago GregorK said it was possible. :confused:

h4x5h17 December 6th, 2015 04:17 AM

I think Phex has a couple of lists stored in the jar file. I'm not sure just yet how it is working with them.

Frostwire looks like it needs to be stripped down and cleaned up before it is tweaked too much.

Thanks for the input!

ale5000 December 6th, 2015 08:26 AM

Maybe it can be tricked in some way, I suppose.
Maybe using read-only attribute or modifying the dns of the site that it use to check the hash.
Currently I don't have time but when I have more time I can create a modified Frostwire if it is possible.

I have also the intention to create modified installers of many died P2P apps with support for one click update of the hostiles from GWC link without any executable.
For live P2P apps they can add support themselves if they want once the "standard" is finalized.

ale5000 December 6th, 2015 10:15 AM

I have also tested the other blocklists and unfortunately they have more errors.
Sorry to bring you more work.

Lite without Japan block:
Code:

Start IP do not match.
CIDR Range: 1.116.0.0/13
Wildcard Bits: 0.7.255.255
Start IP: 1.112.0.0
End IP: 1.119.255.255

Start IP do not match.
CIDR Range: 58.138.131/24
Wildcard Bits: 0.0.0.255
Start IP: 58.138.0.0
End IP: 58.138.0.255

Invalid CIDR range: 59.144.8./24

Start IP do not match.
CIDR Range: 99.169.180.0/21
Wildcard Bits: 0.0.7.255
Start IP: 99.169.176.0
End IP: 99.169.183.255

Start IP do not match.
CIDR Range: 115.163.31.116/29
Wildcard Bits: 0.0.0.7
Start IP: 115.163.31.112
End IP: 115.163.31.119

Invalid CIDR range: 115.163.107.128/

Start IP do not match.
CIDR Range: 118.22.7.92/26
Wildcard Bits: 0.0.0.63
Start IP: 118.22.7.64
End IP: 118.22.7.127

Start IP do not match.
CIDR Range: 125.194.9.90/24
Wildcard Bits: 0.0.0.255
Start IP: 125.194.9.0
End IP: 125.194.9.255

Start IP do not match.
CIDR Range: 192.41.178.0/20
Wildcard Bits: 0.0.15.255
Start IP: 192.41.176.0
End IP: 192.41.191.255

Start IP do not match.
CIDR Range: 192.52.180.0/20
Wildcard Bits: 0.0.15.255
Start IP: 192.52.176.0
End IP: 192.52.191.255

Start IP do not match.
CIDR Range: 192.54.81.0/21
Wildcard Bits: 0.0.7.255
Start IP: 192.54.80.0
End IP: 192.54.87.255

Start IP do not match.
CIDR Range: 196.3.140.0/21
Wildcard Bits: 0.0.7.255
Start IP: 196.3.136.0
End IP: 196.3.143.255

Start IP do not match.
CIDR Range: 203.141.200.0/20
Wildcard Bits: 0.0.15.255
Start IP: 203.141.192.0
End IP: 203.141.207.255

Start IP do not match.
CIDR Range: 208.191.92.0/19
Wildcard Bits: 0.0.31.255
Start IP: 208.191.64.0
End IP: 208.191.95.255

Lite with Japan block:
Code:

Start IP do not match.
CIDR Range: 27.100.28.0/21
Wildcard Bits: 0.0.7.255
Start IP: 27.100.24.0
End IP: 27.100.31.255

Start IP do not match.
CIDR Range: 27.126.143.0/20
Wildcard Bits: 0.0.15.255
Start IP: 27.126.128.0
End IP: 27.126.143.255

Start IP do not match.
CIDR Range: 27.132.0.0/13
Wildcard Bits: 0.7.255.255
Start IP: 27.128.0.0
End IP: 27.135.255.255

Start IP do not match.
CIDR Range: 49.156.4.0/21
Wildcard Bits: 0.0.7.255
Start IP: 49.156.0.0
End IP: 49.156.7.255

Start IP do not match.
CIDR Range: 61.213.186.0/22
Wildcard Bits: 0.0.3.255
Start IP: 61.213.184.0
End IP: 61.213.187.255

Start IP do not match.
CIDR Range: 99.169.180.0/21
Wildcard Bits: 0.0.7.255
Start IP: 99.169.176.0
End IP: 99.169.183.255

Start IP do not match.
CIDR Range: 103.2.124.0/21
Wildcard Bits: 0.0.7.255
Start IP: 103.2.120.0
End IP: 103.2.127.255

Start IP do not match.
CIDR Range: 103.3.180.0/20
Wildcard Bits: 0.0.15.255
Start IP: 103.3.176.0
End IP: 103.3.191.255

Start IP do not match.
CIDR Range: 103.4.76.0/21
Wildcard Bits: 0.0.7.255
Start IP: 103.4.72.0
End IP: 103.4.79.255

Start IP do not match.
CIDR Range: 103.246.68.0/21
Wildcard Bits: 0.0.7.255
Start IP: 103.246.64.0
End IP: 103.246.71.255

Start IP do not match.
CIDR Range: 110.232.120.0/20
Wildcard Bits: 0.0.15.255
Start IP: 110.232.112.0
End IP: 110.232.127.255

Start IP do not match.
CIDR Range: 119.161.104.0/20
Wildcard Bits: 0.0.15.255
Start IP: 119.161.96.0
End IP: 119.161.111.255

Start IP do not match.
CIDR Range: 180.222.72.0/20
Wildcard Bits: 0.0.15.255
Start IP: 180.222.64.0
End IP: 180.222.79.255

Start IP do not match.
CIDR Range: 180.233.132.0/21
Wildcard Bits: 0.0.7.255
Start IP: 180.233.128.0
End IP: 180.233.135.255

Start IP do not match.
CIDR Range: 192.41.178.0/20
Wildcard Bits: 0.0.15.255
Start IP: 192.41.176.0
End IP: 192.41.191.255

Start IP do not match.
CIDR Range: 192.41.194.0/22
Wildcard Bits: 0.0.3.255
Start IP: 192.41.192.0
End IP: 192.41.195.255

Start IP do not match.
CIDR Range: 192.52.180.0/20
Wildcard Bits: 0.0.15.255
Start IP: 192.52.176.0
End IP: 192.52.191.255

Start IP do not match.
CIDR Range: 192.54.81.0/21
Wildcard Bits: 0.0.7.255
Start IP: 192.54.80.0
End IP: 192.54.87.255

Start IP do not match.
CIDR Range: 196.3.140.0/21
Wildcard Bits: 0.0.7.255
Start IP: 196.3.136.0
End IP: 196.3.143.255

Start IP do not match.
CIDR Range: 202.86.240/21
Wildcard Bits: 0.0.7.255
Start IP: 202.86.0.0
End IP: 202.86.7.255

Start IP do not match.
CIDR Range: 208.191.92.0/19
Wildcard Bits: 0.0.31.255
Start IP: 208.191.64.0
End IP: 208.191.95.255

Start IP do not match.
CIDR Range: 223.27.68.0/21
Wildcard Bits: 0.0.7.255
Start IP: 223.27.64.0
End IP: 223.27.71.255

Strong with Japan block:
Code:

Start IP do not match.
CIDR Range: 27.100.28.0/21
Wildcard Bits: 0.0.7.255
Start IP: 27.100.24.0
End IP: 27.100.31.255

Start IP do not match.
CIDR Range: 27.126.143.0/20
Wildcard Bits: 0.0.15.255
Start IP: 27.126.128.0
End IP: 27.126.143.255

Start IP do not match.
CIDR Range: 27.132.0.0/13
Wildcard Bits: 0.7.255.255
Start IP: 27.128.0.0
End IP: 27.135.255.255

Start IP do not match.
CIDR Range: 49.156.4.0/21
Wildcard Bits: 0.0.7.255
Start IP: 49.156.0.0
End IP: 49.156.7.255

Start IP do not match.
CIDR Range: 62.243.238.128/19
Wildcard Bits: 0.0.31.255
Start IP: 62.243.224.0
End IP: 62.243.255.255

Start IP do not match.
CIDR Range: 103.2.124.0/21
Wildcard Bits: 0.0.7.255
Start IP: 103.2.120.0
End IP: 103.2.127.255

Start IP do not match.
CIDR Range: 103.3.180.0/20
Wildcard Bits: 0.0.15.255
Start IP: 103.3.176.0
End IP: 103.3.191.255

Start IP do not match.
CIDR Range: 103.4.76.0/21
Wildcard Bits: 0.0.7.255
Start IP: 103.4.72.0
End IP: 103.4.79.255

Start IP do not match.
CIDR Range: 103.246.68.0/21
Wildcard Bits: 0.0.7.255
Start IP: 103.246.64.0
End IP: 103.246.71.255

Start IP do not match.
CIDR Range: 119.161.104.0/20
Wildcard Bits: 0.0.15.255
Start IP: 119.161.96.0
End IP: 119.161.111.255

Start IP do not match.
CIDR Range: 122.54.238.0/3
Wildcard Bits: 31.255.255.255
Start IP: 96.0.0.0
End IP: 127.255.255.255

Start IP do not match.
CIDR Range: 180.222.72.0/20
Wildcard Bits: 0.0.15.255
Start IP: 180.222.64.0
End IP: 180.222.79.255

Start IP do not match.
CIDR Range: 180.233.132.0/21
Wildcard Bits: 0.0.7.255
Start IP: 180.233.128.0
End IP: 180.233.135.255

Start IP do not match.
CIDR Range: 192.41.178.0/20
Wildcard Bits: 0.0.15.255
Start IP: 192.41.176.0
End IP: 192.41.191.255

Start IP do not match.
CIDR Range: 192.41.194.0/22
Wildcard Bits: 0.0.3.255
Start IP: 192.41.192.0
End IP: 192.41.195.255

Start IP do not match.
CIDR Range: 193.51.198.0/22
Wildcard Bits: 0.0.3.255
Start IP: 193.51.196.0
End IP: 193.51.199.255

Start IP do not match.
CIDR Range: 193.95.145.80/24
Wildcard Bits: 0.0.0.255
Start IP: 193.95.145.0
End IP: 193.95.145.255

Invalid CIDR range: 200.19.192.0//19

Start IP do not match.
CIDR Range: 202.86.240/21
Wildcard Bits: 0.0.7.255
Start IP: 202.86.0.0
End IP: 202.86.7.255

Start IP do not match.
CIDR Range: 202.150.82.0/3
Wildcard Bits: 31.255.255.255
Start IP: 192.0.0.0
End IP: 223.255.255.255

Start IP do not match.
CIDR Range: 204.15.196.0/21
Wildcard Bits: 0.0.7.255
Start IP: 204.15.192.0
End IP: 204.15.199.255

Start IP do not match.
CIDR Range: 209.78.56.60/23
Wildcard Bits: 0.0.1.255
Start IP: 209.78.56.0
End IP: 209.78.57.255

Start IP do not match.
CIDR Range: 209.232.186.40/24
Wildcard Bits: 0.0.0.255
Start IP: 209.232.186.0
End IP: 209.232.186.255

Start IP do not match.
CIDR Range: 223.27.68.0/21
Wildcard Bits: 0.0.7.255
Start IP: 223.27.64.0
End IP: 223.27.71.255


h4x5h17 December 6th, 2015 11:28 AM

The lists have the MS newline character (^M) after every entry , but are missing the unix newline character (\n) after some entries.

Maybe java doesn't care and the (^M) newline character is enough. Then the only problem would be non-java and non-MS systems/apps (Gtk-G on Unix) unless they have it coded to accept the MS newline on Unix builds.

It is a real easy fix. If you need any help with that let me know.

Just replace all "^M" with "\n" then all "\n\n" with "\n" then all "\n" with "\n^M" or "^M\n" (or something like that). I'm not sure it there is a standard for which one is to preceed the other.

ale5000 December 6th, 2015 11:35 AM

Well, if you use Notepad++ it have a function that do line-ending conversion in one click.

I'm not sure what do you mean with "^M", but it is "\r" (the Mac line-ending).

There are:
Windows (\r\n)
Linux (\n)
Mac (\r)

h4x5h17 December 6th, 2015 11:38 AM

Quote:

Originally Posted by ale5000 (Post 376983)
Well, if you use Notepad++ it have a function that do line-ending conversion in one click.

I like it :)

I noticed that everytime it has a one newline character it is missing the other. So some entries are also missing the MS newline.

ale5000 December 6th, 2015 06:58 PM

The files contain both Mac and Linux newlines (they are both single); only Windows has double newline for every line.

Lord of the Rings December 6th, 2015 10:13 PM

1 Attachment(s)
Many thanks for people to point out errors. Embarrassing how many I've made over time including recently. :o

The 192.52.x.x range I felt it might be best to get heavy with. 192.52.128.0/17 since all ranges are either Corporate Business or Government allocated. That range has had a bad history. Only possible ill-effect I could see is a College falls within that range. :p

So which EOL format should I use?
I vaguely recall reading 'somewhere' in gnutella docs (perhaps program commentary) about these differences & what you should probably choose to do to reduce possible problems.

I presume this is the operation in question:
Attachment 6863

It appeared to be taking a notable time to complete a test run of the operation on the full hostiles using the Unix/OSX format. Oops that seemed to cause problems.

ale5000 December 7th, 2015 03:57 AM

The Windows EOL (\r\n) should be avoided because it increase the size of the file.
The old Mac EOL (\r) is almost extinct nowadays I think.
I usually use the Unix EOL (\n), the most used I think.

But we should test if it work correctly in all clients.

ale5000 December 7th, 2015 04:26 AM

Quote:

Originally Posted by Lord of the Rings (Post 376987)
I presume this is the operation in question:
Attachment 6863

Yes.

Quote:

Originally Posted by Lord of the Rings (Post 376987)
It appeared to be taking a notable time to complete a test run of the operation on the full hostiles using the Unix/OSX format. Oops that seemed to cause problems.

While it convert EOL it seem freezed but it is just working, it take some time with big files.


Do not worry about errors, you work is impressive; with those big files it is normal to make mistakes.
I have noticed also that there are empty lines.

I have converted EOL to Unix and removed empty lines (other errors are still here):
https://www.mediafire.com/folder/gcjrm0cthd7qx/

h4x5h17 December 7th, 2015 06:51 AM

Awsome, you guys!

Lord of the Rings December 7th, 2015 08:01 AM

Quote:

Originally Posted by ale5000 (Post 376989)
I have noticed also that there are empty lines.

I first discovered empty lines when I copied some files worked with in Apple's TextEdit into an old 3rd party app called Tex-Edit Plus. This was when I first realised TextEdit causes problems. So for the connection files (when I remember) I usually copy into Tex-Edit Plus to find the empty lines & remove. I ended up doing this for the hostiles earlier.
Reason why:

When I used Notepad++ in Win 8 to convert to unix/osx, I noticed at the end of the large hostiles that the first array of the ip address ended up on the previous line with I think it was a (E) or something before it.

Example:
255.255.0/25255.
255.255.128/26255.
255.255.192/27255.
255.255.224/28255.
255.255.240/29255.
255.255.248/30255.
255.255.252/31255.
255.255.25522

This was the first time I ran the operation. An edited smaller version of the hostiles I did a few mins ago did not have the same issue. Converted from CR to LF.
First time, I Selected All before the operation. I suspect that might have caused the problem.
Quote:

Originally Posted by ale5000 (Post 376989)
I have converted EOL to Unix and removed empty lines (other errors are still here):
https://www.mediafire.com/folder/gcjrm0cthd7qx/

Thanks, I'll check it out.

Though my Tex-Edit Plus effort should also have removed the empty lines in the last update I did several hours ago called V3. (There was a chance I missed a blank line or two.) But it is still in CF & not LF.

ale5000 December 7th, 2015 08:36 AM

I don't know about the problem, it may have been just a rare problem (BWT you do NOT need to select, it operate on the entire file but you need to save after the conversion).

Once the EOL are fixed if you use only a good text editor it should preserve EOL as they are and it should NOT create empty lines in the first place.
Notepad++ always preserve EOL as they are, it will change them only if you request it.

Lord of the Rings December 7th, 2015 07:53 PM

1 Attachment(s)
Quote:

Originally Posted by ale5000 (Post 376992)
...Once the EOL are fixed if you use only a good text editor it should preserve EOL as they are and it should NOT create empty lines in the first place.
Notepad++ always preserve EOL as they are, it will change them only if you request it.

An AS forum recommended I use TextWrangler instead of TextEdit because it will not suffer the same problems & has far better applescript support & can run scripts directly (I'm guessing in similar way to how Notepad++ might be able to run script or program code.)

The other text program I started using occasionally from last year is called Sublime Text 2. It's advantages are that it preserves formatting & preserves MacOSX permissions of the file. But I normally use this for editing code (with exception of putting the host-file in reverse order. ie: some gnutella apps read the host-file from bottom-up due to the way it's loaded.) Edit: I have confirmed Sublime Text 2 is maintaining the original EOL.

Whilst using Notepad++, I again ran into issues with both the large hostiles but this time it was limited to the last two lines. Always the last array on last listing had lost a number or more. In the image example, 4 individual numbers are missing on the last line which includes the entire last array. This might be Win 8 related. I normally do my Win text work on XP after finding an anomaly with text handling either on Win 7 or 8 a few years ago.

Attachment 6864

I've released v.4 update.

Again, many thanks for your help. :Smilywais:

Lord of the Rings December 8th, 2015 09:50 AM

I've also packed the Hostiles_Light_NJ file separately. Unfortunately I made an error & accidentally zipped the larger version (around 2 MB instead of 103 KB) & someone downloaded it. I apologise to that person. The file has since been replaced, issue remedied.

The idea of the standalone 'Hostiles_Light_NJ' file is anyone can place it manually if you know where it should go for your particular program, be it LimeWire, WireShare, Cabos, Acqulite, GTK or even Phex. Unfortunately (I can't remember since which version) since at least FrostWire 4.20, the hostiles will be deleted when FW starts. Earlier FW versions should be fine.

ale5000 December 8th, 2015 06:13 PM

Sorry to say but your files are corrupted, there are many truncated IPs (not much in the light files but a lot in the full files).
I suggest to start with my fixed files.

Example:
Code:

4/30
85.114.17.96/28
208.0/22

Are you sure there isn't a virus on your PC?

Lord of the Rings December 8th, 2015 07:31 PM

Thanks again for finding the errors. I'm installing NotePad++ on XP this time. I recall Win 7/8 had problems handling the processing of hostiles a few years ago (odd things were happening.)
However since you already fixed the eol's I can continue. Thanks ale5000, many of the errors were fixed.
As for virus on Win 8 ... early in the year or last year I did have one of those web-page hijackers which took a lot of trouble to get rid of. The system had been scanned by a lot of 3rd party utilities of all types to find anything.

Edit: Finished a version 5 of the December update. (Crosses fingers all is ok now!)
I removed a couple of blocked ranges in a particular European country, I needed to back-track to find what I did yesterday. I had also done a few Russian removals, too difficult to determine now since I made no notes of those particular actions.

h4x5h17 December 9th, 2015 11:34 AM

Quote:

Originally Posted by ale5000 (Post 376974)
For those that do NOT already know I will add the distribution of the blocklists directly from the Skulls GWC, and it will work with all P2P app (not from the start but I will add support for other apps from time to time); I have taken the idea from the unofficial mod at 4octets.co.uk.
If someone have a decent server it could help by hosting it and report bugs.

Define decent :o What kinda load are we talking about?

ale5000 December 9th, 2015 07:21 PM

The major problem for a GWC is the number of requests.
A single request use low bandwidth but the number of request is considerable (and about 30% of the requests are from fake clients).
I'm not sure about the exact number but it may be like 1000 requests per hour (to serve both gnutella and gnutella2).

For the ones that want to try it I suggest to put it in a sub-domain (not the main domain) and if you want to disable it then change the sub-domain to point to 127.0.0.1

ale5000 May 11th, 2016 04:00 AM

For the ones interested I have released a new beta version with the code to distribute blocklists (I have released as beta because I have done many potentially breaking changes but if I don't discover any new bug it can be considered stable).
You need Skulls 0.3.4 Beta (or later) and Skulls Add-on 0.2 (or later) if you want to test it.


All times are GMT -7. The time now is 04:59 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.