eMule Plus Forums > Try to detect a fake server

Full Version: Try to detect a fake server

eMule Plus Forums > Development > Development

Pages: 1, 2

AraldoL

Dec 25 2006, 21:21

since some days I noticed on nearly every search I get one single fake search result (obviously a dangerous executable) with a very high number of sources so it's always on first position on the search results. The filename is always built of my search term and "_ShareAccelerator.exe", i.e. if I do a global search on "schafkopf" (a german cards game, there are several freeware versions floating around) I get "schafkopf_Shareaccelerator.exe" with about 6500 full sources. There must be at least one bogus server that builds this filename from my search term.

Of course I use a big and weekly updated ipfilter.dat! And I use a self compiled version of current CVS with an self made addition to prevent adding any servers which are located in the United States according to ip2country. So I have no US servers in my list.

To investigate which server it is I tried to find the location in source where the server results are added to the list. I wanted to write a debug line with the server's ip to the debug log to find out which server it is as a first step.

Can someone point me to the proper file and function in source where both server ip and filename from global search results are available?

Araldo

Aw3

Dec 25 2006, 22:50

CODE

        switch (uOpcode)
        {
            case OP_GLOBSEARCHRES:
            {
                CSafeMemFile    pckStream(pbytePacket, dwSize);
                uint32            dwLeft;
                uint16            uResults;
                byte            byteTmp;

#if 0
pServer->GetListName()
pServer->GetFullIP()
#endif
                if (g_App.m_pSearchList->AllowUDPSearchAnswer())
                {
...
                }

AraldoL

Dec 26 2006, 09:48

Thank you Aw3! Now I know I always searched in the wrong files (SearchList.cpp, SearchListCtrl.cpp, ...). Now I'll try to find out which server (or several servers?) is responsible to add it to ipfilter.

Another idea I had is to drop all search results with more than 2000 or 3000 full sources from a single server on global search. I never had a realistic result like this and such a file would still get enough sources from smaller servers too.

Araldo

Fuxie - DK

Dec 26 2006, 14:24

QUOTE(AraldoL @ Dec 26 2006, 10:48)

Another idea I had is to drop all search results with more than 2000 or 3000 full sources from a single server on global search. I never had a realistic result like this and such a file would still get enough sources from smaller servers too.

Some of the VERY popular movies (e.g. Lord of the Rings, when it was released) and games, does infact have 2000+ valid sources...

AraldoL

Dec 26 2006, 15:11

QUOTE(Fuxie - DK @ Dec 26 2006, 16:24)

Some of the VERY popular movies (e.g. Lord of the Rings, when it was released) and games, does infact have 2000+ valid sources...

In total, yes. But not so much complete sources on one single server, so if you do a global search for such a popular file you could even drop a 2000+ result of one or two of the biggest servers but you still get more than enough search results of the same file from smaller servers. If you start such a download the other sources are found by source exchange, of course.

Araldo

Vladimir (SV)

Dec 26 2006, 15:29

instead of dropping, have you considered the possibility of filtering results for strings?.

Let say an "result filter" with badwords or something like that. IMHO that will protect you just from undesired result, and to avoid the little probability of drop a real result from the search.

muleteer

Dec 26 2006, 17:09

QUOTE(Vladimir (SV) @ Dec 26 2006, 20:59)

instead of dropping, have you considered the possibility of filtering results for strings?.

No, because the fake result shows a filename that is made specially, based on the search string. No bad words are present.

I like this idea. So far we've been depending on publicly updated ipfilters for weeding out the bad servers. Time we got more proactive.

Vladimir (SV)

Dec 26 2006, 19:26

QUOTE(muleteer @ Dec 26 2006, 11:09)

QUOTE(Vladimir (SV) @ Dec 26 2006, 20:59)

instead of dropping, have you considered the possibility of filtering results for strings?.

No, because the fake result shows a filename that is made specially, based on the search string. No bad words are present.

It's like file name cleaner, it does not has to be the exact string to filter, let say you want to filter results with "_Shareaccelerator.exe" string present, which will be any string compossed with it, like "This is not fake_Shareaccelerator.exe", "Believe me_Shareaccelerator.exe", "this is the file_Shareaccelerator.exe", etc.

Anyway, any method to delete fake servers is welcome

AraldoL

Dec 27 2006, 10:22

Back again with results:

It's "BiG BanG 12" (IP: 80.239.200.111) that sends those bogus exe results, I added him to my ipfilter list. Didn't get such fake results from any other server in my list.

Araldo

muleteer

Dec 27 2006, 13:04

Thanks. Nice proof of concept, to show that it can be done.

Captain_Shiner

Dec 27 2006, 14:54

Mmm... I was interesting in this result about BigBang12... so I conncected eMule+ to BB12 and tried some searches using "server" method, but I didn't find such fakes called "...shareaccelerator.exe".

Can anybody test this server and report its behaviour?
Thanks.

Fuxie - DK

Dec 27 2006, 15:18

QUOTE(AraldoL @ Dec 27 2006, 11:22)

It's "BiG BanG 12" (IP: 80.239.200.111) that sends those bogus exe results, I added him to my ipfilter list. Didn't get such fake results from any other server in my list.

How can you be sure??

BiG BanG-servers have always been trusted servers, and they ALWAYS have IP 80.239.200.*, so it's pretty hard to fake the IP..

I tried to do your search on schafkopf, and with Global Search, I also got the virus file.. But when I switched to BB12-server and did a search more (this time only a server search), I didn't get the virus file, thus indicating, it must come from another server..

EDIT: Just saw Captain_Shiner reported the same thing before me

Vladimir (SV)

Dec 27 2006, 15:36

Captain_Shiner, sometimes, server behaviours are bases upon client country.

I don't get the fake file too with that server. Just three low sources files.

AraldoL

Dec 27 2006, 15:36

I was surprised too. To validate it without my code modifications:

- Have BiG BanG 12 in your server list, i.e. use following link
ed2k://|server|80.239.200.111|3000|/
- Connect to a different server
- Global search for "schafkopf" -> you get the bogus result
- Delete BiG BanG 12 from your server list (use settings that don't auto add servers otherwise this server will return into list)
- Global search again -> clean

BB12 was the only server my patch logged yet, none of the other BiG BanG did this. I didn't download this EXE to check what it does but I'm sure it's not healthy

Araldo

UPDATE: Hmm, currently I don't get this bogus result again from BB12 or any other server. I'll investigate if it returns ...

muleteer

Dec 27 2006, 16:27

Good move.

Downloading the dubious exe is asking for it.

AraldoL

Dec 27 2006, 18:34

Now I think BiG BanG 12 was a false alert. Seems like things are running asynchronous so my debug lines don't show the correct server

Now on an installation without BB12 I get a debug log that BB5 is sending this filename.

I need to take a deeper look into the code to get it working properly (in UDPSocket.cpp I get server name and IP as Aw3 showed me above and store it, in CSearchList::AddToList I check the filename and report the last stored server name but seems like this doesn't correspondend.

So I would say that BB12 is innocent and I have to search again which one it is. I'll be back when I get it working.

Araldo

AraldoL

Jan 7 2007, 18:29

Something new on the subject:

1. Dropping those bogus search results does work. I added the red code lines to SearchList.cpp function CSearchList::AddToList at line ~675:

CODE

                        delete pAddedFile;
                        return false;
                  }
            }
      }

      CString strServerFilename = pAddedFile->GetFileName();
      uint32 dwServerFullsources = pAddedFile->GetIntTagValue(FT_COMPLETE_SOURCES);
      if ((dwServerFullsources > 4000) && (strServerFilename.MakeLower().Find(".exe") > 0))
      {
            AddLogLine(false, RGB_LOG_ERROR_TXT _T("Bogus Server sends %u full sources for suspicious file %s - dropped!"),
               dwServerFullsources,strServerFilename);
            delete pAddedFile;
            return false;
      }

      CSearchFile            *pSearchFile;

      for (POSITION pos = list.GetHeadPosition(); pos != NULL; )

To allow logging I had to change SearchList.h as well at line 87:

CODE

class CSearchList : public CLoggable
{

As you see it's only dropped if it's an EXE file and server reports more than 4000 complete(!) sources. Now the file name changes, it's not only shareaccelerator any more. But it's always an EXE file with about 6500 full sources.

2. Detecting the server responsible for this results: Sorry, I wasn't able to find out the proper connection between server IPs and result packets, resulting in wrongly accusing a BigBang server. Perhaps someone can add it to the detection above to filter such a server.

Araldo

Fuxie - DK

Jan 8 2007, 05:14

QUOTE(AraldoL @ Jan 7 2007, 19:29)

Try doing a search for "exe" in the name-field and "4000" in availability-field..

I get two results:
eMule0.47c-Installer.exe <-- 12870 results...
ud.sarkilari_Web_Hottest_Videos_PersonalPlayer.exe <-- 4457 results...

So by excluding all exe-files simply because they have more than 4000 sources seems a bit dangerous for me...

Aw3

Jan 8 2007, 05:53

Just add the following guys to your ipfilter and delete them from the server list as well:
62.90.175.146
213.8.162.36
66.232.114.92

If you can see another Israel 17.10 server, it might be the same buddy as well...

AraldoL

Jan 8 2007, 08:38

QUOTE(Fuxie - DK @ Jan 8 2007, 07:14)

The search packet is only dropped if you get more than 4000 full sources from a single(!) server. So perhaps the first example is dropped from one or two biggest servers that really have 4000 complete sources connected. But even then your global search gets lots of additional results from servers with less than 4000 full sources which are not(!) dropped. It's unlikely that there are more than 4000 sources on a big server and none on the smaller ones. If one packet is dropped you would get 8000 instead of 12000 total sources, still enough I think. If such a download is started the remaining sources are found by source exchange.

Btw, the second example sounds exactly like those fake results! (currently I'm getting xxx_shareaccelerator.exe, xxx_web_hottest_videos_personalplayer.exe, xxx_direct_torrent_search_bar.exe, ...), you could download and launch it and tell me what it does

Araldo

Aw3

Jan 19 2007, 02:12

One more guy for the ipfilter: 069.046.023.148

AraldoL

Jan 19 2007, 10:52

Currently I'm not filtering the whole server but just drop those bogus results with the code posted above (drop level: > 9000 full sources!). No more problems with searching now

Araldo

Aw3

Jan 19 2007, 14:00

You don't know what those servers do -- better to avoid any transfers with them...

Aw3

Jan 25 2007, 02:14

One more: 212.025.103.162

muleteer

Jan 25 2007, 05:06

I think I'll start a thread listing these in the support forum - or should it be the Public info forum?

Aw3

Jan 25 2007, 05:29

There's a similar thread on eMule forum, those addresses will be a part of IPfilter soon (some of them are already there)...

MaxWilder

Jan 26 2007, 00:41

QUOTE(Aw3 @ Jan 25 2007, 05:29)

There's a similar thread on eMule forum, those addresses will be a part of IPfilter soon (some of them are already there)...

I looked at that thread, and it had no solution that I could find applicable to eMule Plus.

Though I am certainly not an expert, I have stopped the spam using the following method:

1. Select all current servers, right-click and select "Remove selected Server".
2. Go to Preferences -> Connection -> Server.
3. Check "Auto-update serverlist at startup"
4. Un-check "Update serverlist when connecting to servers and clients".
5. Restart eMule Plus -or- Manually "Update server.met from URL", available through a button on the top-right of the main "Servers" page. Use one of the servers which appears in the dropdown list such as "http://www.gruk.org/server.met.gz".

In my guesstimation, this should guarantee all your servers have been cleared by gruk.org or srv1000.com. I have no idea who they are, but other people seem to respect their lists.

However, this will disable the ability to find new servers through current servers. Meaning your searches may not find as many results. Sad, but now it seems to have become necessary.

Hopefully somebody will post a better long-term solution.

Araldo, the searches are now returning .zip files as well as .exe files. I'm sure they will keep adding more extensions and name permutations, so you might as well remove the .exe part of your code. And if your code becomes widely used, they will probably lower the number of complete sources until they mix with the normal hits. It's a good short-term solution, though.

LUCA TONI

Feb 1 2007, 20:16

to eliminate the problem of spy servers i exclusively use this server list: http://elboiler.p2pforum.it/server.met and i renew my ipfilter at this site: www.emulesecurity.net

WiZaRd

Feb 18 2007, 13:12

The problem cannot be solved by ipfiltering because UDP packets' source IP+Port can be easily faked.
Filtering by the number of sources is also a bad idea, they might just change it to another (high) number and in case of a very popular file you will lose good search results.

The only - proper - way to block them, as far as I am concerned, is to use a simple server search or not to use servers at all (best solution IMHO) but join the KAD network.
The might try to infiltrate it, too, earlier or later but for now we are safe

After all, using your brains to analyze the given search results isn't such a bad thing either...

muleteer

May 3 2007, 18:40

I have had reports of bad results from KAD searches too.

Friends using oMule report results with a whole heap of 'c's in them. Eg. Ccccccc.

Vladimir (SV)

Dec 20 2007, 13:09

I think there's a way to detect fake files on results. Fake servers does not respect "Max. File Size" either "Extension" (really, thet don't respect anything...)

I had tested diverse things, and found that it will be safe to drop results which extension differs from the expected ones, or which file size differs from the interval selected.

In any case those settings are not obligatory and therefore will not work 100%, but at least I thing it's better than nothing.

One case it could be special useful is when you search for movie types, server returning an "exe" it's likely to be fake.

I think this does not need so much heuristics nor parsing, nor anything more than simple double check if results meets the criteria of the search on client side.

I can post an screenshot of a situation where all fakes results can be identified by a patron, tell me if you like that I post it and to describe more the idea.

muleteer

Dec 20 2007, 15:14

What if the user does a global search without specifying any additional parameters except the keywords?

I do that sometimes when I'm not sure of the size or extension.

Eg. If I'm searching for a movie and its subtitles. I get the big movie (avi, mkv, mp4, iso, rar, whatever) and the small subtitles (srt, rar zip, sub, idx, whatever).

Aw3

Dec 20 2007, 15:41

What server version and capabilities (in server tooltips) they had?

Vladimir (SV)

Dec 20 2007, 16:30

QUOTE(muleteer @ Dec 20 2007, 09:14)

What if the user does a global search without specifying any additional parameters except the keywords?

QUOTE(Vladimir (SV) @ Dec 20 2007, 07:09)

In any case those settings are not obligatory and therefore will not work 100%, but at least I thing it's better than nothing.

I know it's not perfect, but it could avoid some fake results when the user do specify the parameters.

QUOTE(Aw3 @ Dec 20 2007, 09:41)

What server version and capabilities (in server tooltips) they had?

I don't understand, do you want that I post the version an capabilities of each server on my list?.

I'm proposing a method to drop the fakes results in some cases, but I think it's not possible to determine the server which produce them without modifications to the code (like logging the servers who throw the fake result)

muleteer

Dec 20 2007, 16:39

Basically, if the results returned by a server contains items that do not meet the search criteria, declare that server as a fake and discard all its results. Is that what you are suggesting?

Vladimir (SV)

Dec 20 2007, 17:09

No, if the results returned by a server contains items that do not meet the search criteria, just log that server as possible fake (to warn user) and discard only the results that do not match the criteria.

Some day I was thinking in the possibility of not simply discard the results, but to open two tabs per search result: usual tab with processed results and the other tab with the results that were received but did not match the criteria.

Like most mail systems, where you have a "spam" folder, that contains the suspicious mail, so you may review them in case of a erroneous behavior of the filtering system.

zegg

Feb 27 2008, 23:31

hi
my searches produces those crappy results too after a while(in general search)

there should be fake server list file in next emuleplus updated from an online database you are hosting IMO.fakeproducing servers should be added as noticed.an algorithm that is to notice those fake results is not hard imo.pattern that is occuring in every crappy result is that nearly 8-20 new result files appear in one time that generally coming from 1 server those filenames containing many exe results.(at least 1 exe).that server may be instantly submitted as a suspicious crapy server to your forum site (to a file maybe) by the new client.shouldnt be hard to do this...even to make the algorith better, if the client notices such thing, it could search a 1-2 more words in the background without interacting with the user(general search), and look if the new different random words produce pretty same named results with same crappy servers.(from same server until attackers also change their algorithm of handling searches of different range of words((say starting with a-h with crapy server1, h-z wth server2, 0-9 with server 3..or with ascii codes)).anyways dont look if coming from the same server then.rather look that server produced a matching result for a different word too in your algorithm

)

i need to sleep.i hope it is understood.i mean what i try to tell.

gnight everyone.life is good is guess.but i am not sure

muleteer

Feb 27 2008, 23:50

Ouch! Suggest you select them all and delete them, then update from http://www.peerates.net/servers.php

http://emuleplus.info/forum/index.php?show...indpost&p=83687

zegg

Feb 28 2008, 00:20

Lastwebpage

Feb 28 2008, 17:06

Sorry,
but I don't see the point why eMule should support any list or dedection of fake servers, can someone explain me the reason for it?

There are some good list with NOT fake servers like:
http://peerates.net and http://www.gruk.org/
Is this not enough?

Yes, I know, when I would enable the both options to automatic get new servers,
I would get a lot of fake serves too, but why should someone enable this options?

Peter

muleteer

Feb 28 2008, 18:44

Its a personal choice - zegg doesn't seem to mind them. Problem is, fake servers are capable of doing much more that just giving you garbage results. Some could even be data miners for the anti-piracy agencies. Don't forget that you reveal your entire list of shared files to the server you are connected to, plus whatever you are downloading is revealed to every server in the list.

Lastwebpage

Feb 29 2008, 14:52

last one should be catched from the IPFilter.dat, or not?

muleteer

Feb 29 2008, 16:30

QUOTE(Lastwebpage @ Feb 29 2008, 20:22)

last one should be catched from the IPFilter.dat, or not?

True, but ipfilters are not always up to date - a fake server has to be detected and reported to the ipfilter compilers, who will then independently verify the report. Only then does that server get put in. The really bad servers just keep changing their IP addresses - even if they change IPs once every two weeks, the ipfilter will never get them.

Lastwebpage

Mar 1 2008, 07:27

QUOTE

ed2k://|server|66.90.73.253|8899|/
ed2k://|server|193.138.221.214|4242|/
...
True, but ipfilters are not always up to date

This would assume that this fakeserver list get an update each day.

muleteer

Mar 1 2008, 07:57

QUOTE(zegg @ Feb 28 2008, 05:50)

the default autoupdate server list at startup also contains a bogus server which screws the search list in latest client1.2c

That is exactly what I have been trying to tell you. A lot of good servers bit the dust after eMule Plus v1.2c was released. We know it, you know it, everyone with any sense knows it, but until we release v1.2d you have to make the changes manually.

1. Select all the static servers and remove from static list. (otherwise they won't get deleted in the next step).
2. Select all the servers and delete them.
3. Click the button 'Update server.met from URL', paste the link http://www.peerates.net/servers.php the box and click 'update'.

And yes, disable 'autoupdate server list at startup', and also other vehicles for getting fake servers, eg. 'Update server list on server connection' and Update server list when client connects'. If you like, you can also disable 'remove dead server after n retries', or your server list will get smaller and smaller over time as dropped servers have no way of coming back.

Latwebpage: you've lost me.

Please give the 'for dummies' version of whatever point you were trying to make.

Lastwebpage

Mar 1 2008, 12:02

You said "The Ipfilter.dat is nice, but it's not up to date because the fakers change the IP very often"

zegg said "A list of fake servers would be nice" and give a list of ed2k links, which contains IP-addresses too.

So, if both lists contains IP-Addresses, which change quicker as an updated for the lists, what's the benefit?

If the list of fakeservers contains names, not IPs, yes, maybe, but this way?

Peter

muleteer

Mar 1 2008, 13:21

If the list of servers contained names, we'd have to create a Domain Name Server (DNS) for ed2k servers. LOL

But seriously, names can change too. So either you limit yourself to servers that you know are good, or you risk being exposed to a fake server.

So far fake servers haven't been able to do much harm except giving garbage results when they are in your servers list, or not giving you sources when you are connected to them. Don't know how relevant the data collection activities are to you, but I don't see them coming to my country looking for me.

zegg

Mar 3 2008, 12:56

here i am quoting the thing i had wrote in the chat also correcting little write mistakes so that it stays even after i am dead

(corrected*)

QUOTE

okay.i hope you add an algorithm instead of only replacing server list file to catch those servers and remove them from the active server list.because disabling the adding new server options really lowers the sources and download.so we better be able to let them stay open, so need an algorithm to filter those crappy ones.shouldnt be hard to make the client to send a few random general searches in the background and filter out the servers with many matching patterns for different files while also no response for that files from other servers.that responding servers having low user and file OR many new results (not received results((files)) from other servers) from 1 server may be treated as an additional heuristic pattern for those crappy servers but just for suspection as a side algorithm , and maybe ask for the user to remove or not, and let it stay until user comfirms* the removal.clear results from the main* algorithm may not require* user approval for server removal..

QUOTE

muleteer: Sat. Mar. 01st, 2008 10:52 PM
zegg: Yes, that is a good idea. We do have countermeasures for clients who do not behave properly; it would be interesting to do something for detecting and filtering fake servers. Problem is, servers don't like unnecessary traffic, and when you consider hundreds of thousands of clients automatically doing useless searches just to find out whether or not a server is bad... well, you get the picture.

the repeatance of such server detection processes are not necesarrily have to be so frequent imo that it would irritate the server..because i dont think they add up or change IP s of fake servers so frequently that when we are to catch up their interval so would irritate the servers..say, it does a 3-4 searches when at the client start, and does renews this process after 3-5hours later again..because the server list size doesnt change get more bigger then a limit size after a certain amount of time because our client does not encounter any more new server existance from connected clients and servers(enabled through options)..so one exeptional process can be put after hmm say 1 hour or half the clients initiliztion(start), assuming it would reach that limit until that time, incase the clients server list was too low at begin or maybe was cleared before closed last time)..and of course if so, "clearing the server list" from the options should reset the time counter as if the clients was reopened.

zegg

Mar 3 2008, 13:10

like
*search* (at client start)
*search* (1 hour later after client start counter)<EXCEPTIONAL
*search* (3 hour later after client start counter)
*search* (6 hour later after client start counter)
*search* (9 hour later after client start counter)
*search* (12hour later after client start counter)
....
when the server list happens to be containing less than say 50 server(by deleting servers or by clearing server list from options), the client interprets this incident of detection the lowering and queues <EXCEPTIONAL search for to be processed after 1 hour..

zegg

Mar 3 2008, 13:20

*search* means 3-5 different searches each like "adfadffadsfsdfıuor" "asdjhuipajhgda78" etc..and see if matching results comes from a shity server for these random searches..

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.