[victorxstc]

Maybe 90% of 200+ megabyte archives are corrupt, regardless of their type (RAR / ZIP), according to the latest versions of Winzip, Winrar, and 7Zip (2015). HashCalc shows that all the HASH values are identical to those originally reported by eMule.

Any help?

I noticed this line for a downloaded 493-meg archive: MPEG Audio (Verified) - Invalid file extension: RAR... However, media player could not render it when I changed the extension to MPEG. Maybe this info might help, I thought.

This post has been edited by victorxstc: 13 September 2015 - 12:00 PM

[Zangune]

victorxstc, on 13 September 2015 - 01:57 PM, said:

Maybe 90% of 200+ megabyte archives are corrupt, regardless of their type (RAR / ZIP), according to the latest versions of Winzip, Winrar, and 7Zip (2015).

I do not believe the fakes' percentage is that high.

victorxstc, on 13 September 2015 - 01:57 PM, said:

HashCalc shows that all the HASH values are identical to those originally reported by eMule.

Sure, that check is not necessary.

victorxstc, on 13 September 2015 - 01:57 PM, said:

Any help?

Fix your server configuration: in eMule Options - Server, untick first 3 options and the number six: Auto-update server list at startup, Update server list when connecting to a server, Update server list when a client connects and Autoconnect to servers in static list only, add a tick to other options if necessary.
In 'Servers' select all servers, right click on a server and choose, if possible 'Remove From Static List'.
Right click on a server, choose 'Remove all', click in the space under 'Update server.met from URL' and press Ctrl and Del, then paste one of the following:

http://gruk.org/server.met.gz
http://peerates.net/servers.php
http://shortypower.org/server.met
http://upd.emule-security.org/server.met

right click on PEERATES.NET, choose Priority - Low, repeat for PeerBooter, click Disconnect and then Connect.

[coluche]

My % for corrupt files when (searching in eMule/ Kademlia itself and then) downloading big archives is zero.*

However I do have encountered these strange misnamed mpeg-audiofiles a few times - maybe 3 or 4 - when I was searching for videos.

VLC would "play" them, but it seems they were "empty" audiofiles, at least I could not hear any sound.
I have no idea what is the purpose of sharing these misnamed files. odd.

btw - file extension for mpeg audiofiles should be either .mpa (mpeg-1 video) or .mp3 (mpeg-2 video) or .mp4a for newer stuff. NOT : mpeg.
In Windows XP, with "file inspection" on (forgot the correct term), having a misnamed >1-GB .wav <-> .mpa file lying in the folder to be displayed in windows-explorer was responsible for my old computer coming to a grinding halt. after 20 minutes or so I had enough and pulled the plug.

------------------

*
Well, I once did download a big archive (software), that then turned out it was saved/ created using a wrong codepage, so all the stuff inside was named in "mojibake" - you know, sth. like : £.exe or such.
So of course that software would not work in such state.

But that was very, very likely a genuine error - nothing malicious.

This post has been edited by coluche: 13 September 2015 - 11:31 PM

[fox88]

coluche, on 14 September 2015 - 02:17 AM, said:

I have no idea what is the purpose of sharing these misnamed files. odd.

The purpose might be trivial: users spend their time, bandwidth (and sometimes money) to get nothing (or even malicious contents); and thus discourage further use of the program.

coluche, on 14 September 2015 - 02:17 AM, said:

btw - file extension for mpeg audiofiles should be either .mpa (mpeg-1 video) or .mp3 (mpeg-2 video) or .mp4a for newer stuff. NOT : mpeg.

The .mpeg extension is legit; you might see it in your Windows registry.
However, certain file extensions give higher chances of getting fake files.

coluche, on 14 September 2015 - 02:17 AM, said:

But that was very, very likely a genuine error - nothing malicious.

Hanging a program or OS is one of the ways to disrupt normal usage and thus is a successful attack. Luckily, it did not have any complications.

This post has been edited by fox88: 14 September 2015 - 05:30 PM

[victorxstc]

Zangune, on 13 September 2015 - 01:50 PM, said:

victorxstc, on 13 September 2015 - 01:57 PM, said:

Maybe 90% of 200+ megabyte archives are corrupt, regardless of their type (RAR / ZIP), according to the latest versions of Winzip, Winrar, and 7Zip (2015).

I do not believe the fakes' percentage is that high.

victorxstc, on 13 September 2015 - 01:57 PM, said:

HashCalc shows that all the HASH values are identical to those originally reported by eMule.

Sure, that check is not necessary.

victorxstc, on 13 September 2015 - 01:57 PM, said:

Any help?

Fix your server configuration: in eMule Options - Server, untick first 3 options and the number six: Auto-update server list at startup, Update server list when connecting to a server, Update server list when a client connects and Autoconnect to servers in static list only, add a tick to other options if necessary.
In 'Servers' select all servers, right click on a server and choose, if possible 'Remove From Static List'.
Right click on a server, choose 'Remove all', click in the space under 'Update server.met from URL' and press Ctrl and Del, then paste one of the following:

http://gruk.org/server.met.gz
http://peerates.net/servers.php
http://shortypower.org/server.met
http://upd.emule-security.org/server.met

right click on PEERATES.NET, choose Priority - Low, repeat for PeerBooter, click Disconnect and then Connect.

Thanks a lot. In my eMule, 1st and 2nd options were ticked, but the rest were as you said. My previous list of servers in use was:

http://www.emule.com/server.met
http://www.peerates.net/servers
http://shortypower.dyndns.org/server.met
http://en.emulehelp.com/server.met (from irc channel: #emule-english)
http://serveurs.emule-french.org (from irc channel: #emule-french)
http://sites.google.com/site/ircemulespanish/descargas-2/server.met (from irc channel: #emule-spanish)

I revised all options as you said (and changed the server list). Then changed the priority of "Peerates" and "Peerbooter" to low. I will download the same previously-corrupt files to see what happens.

UPDATE: I searched for the same file using the new server list and server options. The previously corrupt file did not even appear! I hope the problem is going to be solved. So thankful.

---------

About the percentage I said, I really feel so. Recently almost all archives downloaded happened to be corrupt.

---------

Regarding the HASH check, I did it to see if the source file was originally corrupt, or a corrupt version of an originally-fine file reached me (because UDP is enabled in my eMule, and I thought perhaps some bits might get lost in UDP transmission, without eMule noticing and re-downloading them).

This post has been edited by victorxstc: 14 September 2015 - 08:44 AM

[victorxstc]

coluche, on 13 September 2015 - 11:17 PM, said:

My % for corrupt files when (searching in eMule/ Kademlia itself and then) downloading big archives is zero.*

Years ago, the same applied to my downloads. But now they are full of corrupt archives. I hope I can revert it.

Quote

However I do have encountered these strange misnamed mpeg-audiofiles a few times - maybe 3 or 4 - when I was searching for videos.

I am not sure if this applies to my case. I was not searching for videos (but archives), nor the extension was misnamed. I think it was a real archive file, however with a modified file header (in the binary file structure itself, not in the extension).

Quote

VLC would "play" them, but it seems they were "empty" audiofiles, at least I could not hear any sound.
I have no idea what is the purpose of sharing these misnamed files. odd.

btw - file extension for mpeg audiofiles should be either .mpa (mpeg-1 video) or .mp3 (mpeg-2 video) or .mp4a for newer stuff. NOT : mpeg.

Thanks a lot. I changed the name extension to all those you said. MP3 and MPA worked. The result (of both extensions) was a high-frequency high-pitched noise, which made me think the file was anything but a media file.


------------------

Quote

Well, I once did download a big archive (software), that then turned out it was saved/ created using a wrong codepage, so all the stuff inside was named in "mojibake" - you know, sth. like : £.exe or such.
So of course that software would not work in such state.

But that was very, very likely a genuine error - nothing malicious.

Thanks. If one or two archives were corrupt, maybe encoding of file names could be the culprit, but in my case, only 1 archive out of about 15 archives was OK.

This post has been edited by victorxstc: 14 September 2015 - 08:43 AM

[fox88]

victorxstc, on 14 September 2015 - 11:06 AM, said:

I will download the same previously-corrupt files to see what happens.

Useless exercise; because server do not store files.
If eMule successfully completed a file, then it is an exact copy of the original.

victorxstc, on 14 September 2015 - 11:06 AM, said:

The previously corrupt file did not even appear! I hope the problem is going to be solved.

Clean servers list lowers probablility of fake/corrupt files; but does not make it impossible to find or download.

victorxstc, on 14 September 2015 - 11:06 AM, said:

Regarding the HASH check, I did it to see if the source file was originally corrupt, or a corrupt version of an originally-fine file reached me (because UDP is enabled in my eMule, and I thought perhaps some bits might get lost in UDP transmission, without eMule noticing and re-downloading them).

Your guesses are quite unrealistic.
If you really want to learn something about eMule, then start reading Docs (find the button at top of the page).

victorxstc, on 14 September 2015 - 11:21 AM, said:

I changed the name extension to all those you said. MP3 and MPA worked. The result (of both extensions) was a high-frequency high-pitched noise, which made me think the file was anything but a media file.

Incorrect. Media file can be a recording of any kind of noise or even silence.

victorxstc, on 14 September 2015 - 11:21 AM, said:

If one or two archives were corrupt, maybe encoding of file names could be the culprit

No way. Contents does not depend on file name; the same is true about ED2K hash.

[victorxstc]

@fox88, thank you very much for your time. I think you misunderstood most of my lines (perhaps because of my English), for example I never implied that "servers store files", or never implied that "a clean servers list makes it impossible to find or download fake files". I also did not suggest that a media file cannot be a recorded silence or noise, but I simply said "made me think the file was anything but a media file". I guessed so because I had never downloaded such a media file before, ever. Regarding the encoding, I meant that some bad file names might be in a healthy archive file, which disallow certain archivers to unzip the archive (but some archivers can unzip it). I was not saying anything about HASH.

Finally, if a successful download is always exactly the original file, what would be the purpose of HASH values reported by eMule? Aren't HASH values for the users to compare the HASH of the downloaded file against the HASH of the original file (and avoid hacked or corrupted downloads)? What other purpose a HASH report can have?

But any ways, I am utterly glad that the problem is now solved (thanks to Zangune, you, and Coluche).

This post has been edited by victorxstc: 14 September 2015 - 09:52 PM

[fox88]

victorxstc, on 15 September 2015 - 12:38 AM, said:

I think you misunderstood most of my lines

Well, I guess the lines were understood correctly. That would be a different issue if your wording differs from your thoughts.

victorxstc, on 15 September 2015 - 12:38 AM, said:

I was not saying anything about HASH.

Because you do not know yet about file hash.
Hash is used as a unique file identifier.
That is, different hash - different files; same hash - same file.
Hash is automatically verified when file is completed.

[victorxstc]

fox88, on 15 September 2015 - 07:41 AM, said:

victorxstc, on 15 September 2015 - 12:38 AM, said:

I think you misunderstood most of my lines

Well, I guess the lines were understood correctly. That would be a different issue if your wording differs from your thoughts.

No, my thoughts were exactly my words and you did misunderstand.

fox88, on 15 September 2015 - 07:41 AM, said:

victorxstc, on 15 September 2015 - 12:38 AM, said:

I was not saying anything about HASH.

Because you do not know yet about file hash.
Hash is used as a unique file identifier.
That is, different hash - different files; same hash - same file.
Hash is automatically verified when file is completed.

Seriously? I thought hash stands for "how to acquire and spread herpes"! Thanks for enlightening me (sarcasm).

This post has been edited by victorxstc: 15 September 2015 - 08:08 AM

[Zangune]

victorxstc, on 14 September 2015 - 11:38 PM, said:

if a successful download is always exactly the original file, what would be the purpose of HASH values reported by eMule?

Information.
A normal user should not care about hashes at all.

victorxstc, on 14 September 2015 - 11:38 PM, said:

Aren't HASH values for the users to compare the HASH of the downloaded file against the HASH of the original file (and avoid hacked or corrupted downloads)?

eMule does this automatically.

victorxstc, on 14 September 2015 - 11:38 PM, said:

What other purpose a HASH report can have?

An advanced user can use that string in funny ways like searching on a *server* by using the hash. Check Meta Data Search Attributes.
In example:

ed2k::45ABE5D6070F94D0A95EE51070E7194E

[victorxstc]

Thanks Zangune I thought it is reported to make sure there was no man-in-the-middle hack attack or any UDP corruption. If eMule already re-calculates the hash of a downloaded file and verifies it by comparing against the hash of the original file, then reporting it is moot (unless for the advanced purposes you mentioned).
Thanks again

[Zangune]

You are welcome

[fox88]

victorxstc, on 15 September 2015 - 02:25 PM, said:

any UDP corruption.

In file data transfers?
Now I am really and truly enlightened by your thoughts.
Thanks and bye.

[victorxstc]

fox88, on 15 September 2015 - 05:26 PM, said:

victorxstc, on 15 September 2015 - 02:25 PM, said:

any UDP corruption.

In file data transfers?
Now I am really and truly enlightened by your thoughts.
Thanks and bye.

lol you were waiting to see something from me to return my word to me?!
a typical copycat.

Now you are enlightened! You are welcome!

----------

But for any future reader, this is what UDP is (Wikipedia):

UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes any unreliability of the underlying network protocol to the user's program. There is no guarantee of delivery, ordering, or duplicate protection. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram.

With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without prior communications to set up special transmission channels or data paths. UDP is suitable for purposes where error checking and correction is either not necessary or is performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.[1] If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

This post has been edited by victorxstc: 16 September 2015 - 06:20 AM

[coluche]

victorxstc, on 14 September 2015 - 10:21 AM, said:

Thanks a lot. I changed the name extension to all those you said. MP3 and MPA worked. The result (of both extensions) was a high-frequency high-pitched noise, which made me think the file was anything but a media file

Ah, ok, so I think it actually were mpg audio files. Maybe recordings of alien signals within white noise, or such. Of course these must be hidden by misnaming the files.

Or just some bad conversion 44,1 <-> 48kHz.

Anyways, good to hear you have better search results now. Zangune!

----------------------------
offtopic

Quote

The .mpeg extension is legit; you might see it in your Windows registry.

Well, yes, but typically for mpg containers.
At least on my old PC (win xP), to have mpg-1 audio files being properly recognised and handled, also test-hearing in winamp, I better had them named .mpa .

Quote

Hanging a program or OS is one of the ways to disrupt normal usage and thus is a successful attack.

You could of course compare it's effect to an "attack", but for the intention imo. user-created errors are more likely than some malicious conspiracy.
Even more so if it is about a software that requires codepage tricks to run on computers with locale not set to Japanese.

Zangune, on 15 September 2015 - 11:01 AM, said:

An advanced user can use that string in funny ways like searching on a *server* by using the hash. Check Meta Data Search Attributes.

Haha, yes, I sometimes use that : when a downloaded file is not what I think it would be, but still a somewhat legit file - I then use this, but with servers (global) to see what are the available filenames - most times I get a correct filename this way.
(sometimes files download so fast that I practically have no chance of checking them before they finish downloading.)

victorxstc, on 15 September 2015 - 09:55 AM, said:

Seriously? I thought hash stands for "how to acquire and spread herpes"! Thanks for enlightening me (sarcasm).

I did not know this one.

[Zangune]

coluche

coluche, on 16 September 2015 - 03:24 PM, said:

You could of course compare it's effect to an "attack", but for the intention imo. user-created errors are more likely than some malicious conspiracy.

I agree with you.
Hanlon's razor

Quote

Never attribute to malice that which is adequately explained by stupidity.

[victorxstc]

@Coluche, Zangune rocks for sure, so do you.

[fox88]

victorxstc, on 16 September 2015 - 09:13 AM, said:

But for any future reader

What words! So nice and humble teacher: for any future reader.

There is a problem though. Namely, the teacher is clueless.
eMule does not use UDP to tranfer file data; hence talks about UDP corruption would be nonsense.

[victorxstc]

fox88, on 16 September 2015 - 08:30 PM, said:

victorxstc, on 16 September 2015 - 09:13 AM, said:

But for any future reader

What words! So nice and humble teacher: for any future reader.

There is a problem though. Namely, the teacher is clueless.
eMule does not use UDP to tranfer file data; hence talks about UDP corruption would be nonsense.

Nobody ever claimed to be a teacher, either humble or not.