Official eMule-Board: Emule: Machine Identification / Tracking / Tracking - Law Enforcement - Official eMule-Board

Jump to content


Page 1 of 1

Emule: Machine Identification / Tracking / Tracking - Law Enforcement Tracking Emule Traffic To A Particular Machine

#1 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 05 November 2016 - 07:59 PM

A building was subject to a law enforcement raid into illegal downloads using P2P software. During the actual raid the machine responsible was identified (from other machines analysed at the time of the raid). (the machine was not sharing any fully downloaded files, but had many partial downloads, that it had for many months. The view other shared files feature was disabled)

Anyone know how this was achieved?


When Downloading & Searching for files and using eMule in general (using AllServers & KAD Network, + anything else) what information does eMule provide that can be used to trace the request back to the physical destination & especially identify a particular machine?

For example, I see it requires to send out its machine's IP Address, when receiving & sending files. This allows tracking back to a physical location. Once the physical location has been determined, is there any information that allows the machine in the location to be uniquely (or kind of uniquely) identified (if the machine was inspected) ?.

Does Emule send out:

  • the network adaptor's MAC Address? (in any form, whether separate or integrated within a value)?
  • operating system user account name, or version, unique ID, or other datails?
  • Serial Numbers or Volume Names of Hard Disks or other hardware?
  • A unique eMule identifier (e.g. for a particular eMule installation)?
  • other files a user is downloading? (when viewing shared files is turned off)
  • anything else?

This post has been edited by retsmah: 05 November 2016 - 08:00 PM

0

#2 User is offline   xSTHNSx 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 150
  • Joined: 01-December 15

Posted 06 November 2016 - 12:33 AM

Which side of the team are you with? Are you with law enforcement asking for help regarding our file sharing scheme or were you subject of targeted raid trying to understand? Regardless I will try to explain in simple terms but if you need details in technical post back for forensic analysis.

First thing you need to understand is we have 2G-P2P decentralized network which is server based known as eD2K along with our 3G-P2P DHT based network known as KAD. So in this case let say user port installs the client and deploys it. Now they can search/download and share/upload. Now let say the user has no files shared in library so this user search for Movie.avi (32MB) starts to download it. This user is not downloading the file from the server but from the uploader. The server will return the downloader all available sources of the file. So he starts to download it which is broken down in chunks in our case 9.28MB so this file will be broke into 4 chunks (3x9.28MB + 1x4.16MB).

Once downloader gets the first chunk from uploader even when file is not fully finished downloading the user will also become partial source. So point of this is to spread chunks faster between multiple users who are missing chunks via source exchange. So in this case let say he user gets 3 chunks and pause the download so its never complete as its missing the 4th chunk. Now when user connects to the server this user shares that file also regardless he/she has full file.

When you connect to eD2K server it publish all shared files to them and then its propagated. So in this case let say Movie.avi is hashed to (ABC123) which is located in ./Incoming so regardless if you rename the file HomeMovie.avi it will still generate same hash (ABC123) this way server can identify same file with multiple filenames. Now you may ask how can it be if the file is not fully downloaded. Well when you downloaded the file the server returned you root hash of the file which then looked for sources so it can download it. Each chunks that you downloaded is broken down to its own hash so once its complete those are shared with others.


View PostxSTHNSx, on 27 December 2015 - 01:29 PM, said:

Once the part/chunk (9.28MB) is downloaded its hashed (sha1 verifying hash of string block hash (chunk is divided in 53x parts (52 180KB + 1 140KB))) for it to be known and verified for sharing to match until file is fully completed as original root hash is matched. Now upon result of corruption of chunk the client would redownload the chunk in order of divided parts to get it correctly so whole chunk is avoided for redownloading as it will download 180KB of the part of the chunk and next so forth. Since the block hash are considered reliable the each 180KB part which is corrupted will be hashed in order to compare the resulting hash with the received block hash. So if they are same the part is okay and there is no need to download it again. But if the hash is different the part is corrupted and it will redownload it again. The purpose of it is to make client know if recivoed block hashs are fake or corrupted.

Posted Image
0

#3 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 06 November 2016 - 05:43 PM

View PostxSTHNSx, on 06 November 2016 - 12:33 AM, said:

Which side of the team are you with? Are you with law enforcement asking for help regarding our file sharing scheme or were you subject of targeted raid trying to understand? Regardless I will try to explain in simple terms but if you need details in technical post back for forensic analysis.

First thing you need to understand is we have 2G-P2P decentralized network which is server based known as eD2K along with our 3G-P2P DHT based network known as KAD. So in this case let say user port installs the client and deploys it. Now they can search/download and share/upload. Now let say the user has no files shared in library so this user search for Movie.avi (32MB) starts to download it. This user is not downloading the file from the server but from the uploader. The server will return the downloader all available sources of the file. So he starts to download it which is broken down in chunks in our case 9.28MB so this file will be broke into 4 chunks (3x9.28MB + 1x4.16MB).

Once downloader gets the first chunk from uploader even when file is not fully finished downloading the user will also become partial source. So point of this is to spread chunks faster between multiple users who are missing chunks via source exchange. So in this case let say he user gets 3 chunks and pause the download so its never complete as its missing the 4th chunk. Now when user connects to the server this user shares that file also regardless he/she has full file.

When you connect to eD2K server it publish all shared files to them and then its propagated. So in this case let say Movie.avi is hashed to (ABC123) which is located in ./Incoming so regardless if you rename the file HomeMovie.avi it will still generate same hash (ABC123) this way server can identify same file with multiple filenames. Now you may ask how can it be if the file is not fully downloaded. Well when you downloaded the file the server returned you root hash of the file which then looked for sources so it can download it. Each chunks that you downloaded is broken down to its own hash so once its complete those are shared with others.


View PostxSTHNSx, on 27 December 2015 - 01:29 PM, said:

Once the part/chunk (9.28MB) is downloaded its hashed (sha1 verifying hash of string block hash (chunk is divided in 53x parts (52 180KB + 1 140KB))) for it to be known and verified for sharing to match until file is fully completed as original root hash is matched. Now upon result of corruption of chunk the client would redownload the chunk in order of divided parts to get it correctly so whole chunk is avoided for redownloading as it will download 180KB of the part of the chunk and next so forth. Since the block hash are considered reliable the each 180KB part which is corrupted will be hashed in order to compare the resulting hash with the received block hash. So if they are same the part is okay and there is no need to download it again. But if the hash is different the part is corrupted and it will redownload it again. The purpose of it is to make client know if recivoed block hashs are fake or corrupted.



Yes, you have explained how eMule file transfer technology works (I was aware of the process). But what I wanted to know and asked was how can a user/installation be traced and identified.

(I am not with law enforcement. I was subject of a raid)
0

#4 User is offline   xSTHNSx 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 150
  • Joined: 01-December 15

Posted 06 November 2016 - 08:27 PM

Well that part is very simple, since file transfers takes place between client (download) to client (uploader) even with server (LowID). So when you requested the file let say in this case same example Movie.avi (32MB). Now if that file is already honeypot to catch you then they are using modified client to record audit of all incoming transmission request. As in this case let say the source was propagated by Law Enforcement or Anti-P2P corp to identify copyright infringement.

So when you searched for Movie.avi the ED2K server returned you with all current available sources. So when you requested the chunk they could see your basic informations like IP:Port, UserHash, Server, ClientID, TimeStamp. Now in this case let say they subpoena the ISP who allocated the IP address to you thus got your location. Now they find the machine with eMule on it they can still identify it you since UserHash (cryptkey.dat). Now let say you downloaded other files which will hash thus its already placed in (known.met/known2_64.met) and all cancelled downloads (canceled.met).

As you can see there was digital footprint that you requested those files thus your IP with TimeStamp was recorded. Now that is not enough so they did the raid to find the evidence and they identified machines who using ~Mule. Now they can match it based on UserHash so they know which machine it is. Even if you downloaded or cancelled it by mistake trace of it still exists. In this case they have actual evidence in ./Incoming where parts/chunks of actual file exists.

If you were to delete the file once it was complete depending on how you delete it it can still be recovered that is another thread of its own and still meta data may already be generated for it like thumbnails, screens, ect. Which can still be used as evidence based on the type of contents. Was this anything related to cP?
Posted Image
0

#5 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 07 November 2016 - 05:37 AM

View PostxSTHNSx, on 06 November 2016 - 08:27 PM, said:

Well that part is very simple, since file transfers takes place between client (download) to client (uploader) even with server (LowID). So when you requested the file let say in this case same example Movie.avi (32MB). Now if that file is already honeypot to catch you then they are using modified client to record audit of all incoming transmission request. As in this case let say the source was propagated by Law Enforcement or Anti-P2P corp to identify copyright infringement.

So when you searched for Movie.avi the ED2K server returned you with all current available sources. So when you requested the chunk they could see your basic informations like IP:Port, UserHash, Server, ClientID, TimeStamp. Now in this case let say they subpoena the ISP who allocated the IP address to you thus got your location. Now they find the machine with eMule on it they can still identify it you since UserHash (cryptkey.dat). Now let say you downloaded other files which will hash thus its already placed in (known.met/known2_64.met) and all cancelled downloads (canceled.met).

As you can see there was digital footprint that you requested those files thus your IP with TimeStamp was recorded. Now that is not enough so they did the raid to find the evidence and they identified machines who using ~Mule. Now they can match it based on UserHash so they know which machine it is. Even if you downloaded or cancelled it by mistake trace of it still exists. In this case they have actual evidence in ./Incoming where parts/chunks of actual file exists.

If you were to delete the file once it was complete depending on how you delete it it can still be recovered that is another thread of its own and still meta data may already be generated for it like thumbnails, screens, ect. Which can still be used as evidence based on the type of contents. Was this anything related to cP?


Yes, all true.

But is the UserHash (cryptkey.dat) not encrypted?, and how can the UserHash be verified onsite in a raid (in little time), is there an automated procedure & tool ?.

It was related to CP.

This post has been edited by retsmah: 07 November 2016 - 05:39 AM

0

#6 User is offline   xilolee 

  • eMule 0.50b BETA1 user
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 7983
  • Joined: 20-August 08

Posted 07 November 2016 - 02:25 PM

We can just click on the uploading client and we'll see the userhash.
The IP can be seen in verbose log.
But there are mod(ified) emule versions that can show ip and userhash in a row...
Hence it can be also modified to get automatically IP and userhash of the uploading client.
INCONCEIVABLE! - You keep using that word. I do not think it means what you think it means.
come ottenere aiuto italian guides - guide della sezione italiana
italian support - sezione italiana scaricare la lista server
ottenere id alto impostare le porte nel router
recuperare file corrotti i filtri ip
Sembra talco ma non č serve a darti l'allegrIa! Se lo lanci e poi lo respiri ti dā subito l'allegrIa! Immagine Postata
0

#7 User is offline   xSTHNSx 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 150
  • Joined: 01-December 15

Posted 07 November 2016 - 02:27 PM

What country are you in? It won't matter how any more as the incrementing evidence is already found on ./Incoming which count as possession of cP which in majority of western world far as I know is all they need to wrap up the case. Not only is that they will also charge you with distribution of cP. As they have already verified it and can easily now prove intent.
Posted Image
0

#8 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 07 November 2016 - 06:23 PM

View PostxSTHNSx, on 07 November 2016 - 02:27 PM, said:

What country are you in? It won't matter how any more as the incrementing evidence is already found on ./Incoming which count as possession of cP which in majority of western world far as I know is all they need to wrap up the case. Not only is that they will also charge you with distribution of cP. As they have already verified it and can easily now prove intent.


I am in Europe. But I know for sure that there was no completed downloads at the time, and no known (filename title identifiable) bad files in the partial downloads. (Any info for the raid was probably from some time before)
0

#9 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 07 November 2016 - 06:25 PM

View PostxSTHNSx, on 06 November 2016 - 08:27 PM, said:

Well that part is very simple, since file transfers takes place between client (download) to client (uploader) even with server (LowID). So when you requested the file let say in this case same example Movie.avi (32MB). Now if that file is already honeypot to catch you then they are using modified client to record audit of all incoming transmission request. As in this case let say the source was propagated by Law Enforcement or Anti-P2P corp to identify copyright infringement.

So when you searched for Movie.avi the ED2K server returned you with all current available sources. So when you requested the chunk they could see your basic informations like IP:Port, UserHash, Server, ClientID, TimeStamp. Now in this case let say they subpoena the ISP who allocated the IP address to you thus got your location. Now they find the machine with eMule on it they can still identify it you since UserHash (cryptkey.dat). Now let say you downloaded other files which will hash thus its already placed in (known.met/known2_64.met) and all cancelled downloads (canceled.met).

As you can see there was digital footprint that you requested those files thus your IP with TimeStamp was recorded. Now that is not enough so they did the raid to find the evidence and they identified machines who using ~Mule. Now they can match it based on UserHash so they know which machine it is. Even if you downloaded or cancelled it by mistake trace of it still exists. In this case they have actual evidence in ./Incoming where parts/chunks of actual file exists.

If you were to delete the file once it was complete depending on how you delete it it can still be recovered that is another thread of its own and still meta data may already be generated for it like thumbnails, screens, ect. Which can still be used as evidence based on the type of contents. Was this anything related to cP?


Did you know all this (internal files used by eMule and other info) naturally or did you research it for me question?

But is the UserHash (cryptkey.dat) not encrypted?, and how can the UserHash be verified onsite in a raid (in little time), is there an automated procedure & tool ?
0

#10 User is offline   xSTHNSx 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 150
  • Joined: 01-December 15

Posted 07 November 2016 - 08:16 PM

View Postretsmah, on 07 November 2016 - 06:23 PM, said:

I am in Europe. But I know for sure that there was no completed downloads at the time, and no known (filename title identifiable) bad files in the partial downloads. (Any info for the raid was probably from some time before)


It would not matter if the contents in question is fully completed or still partial. What does matter is "possession" and the fact you did not delete it when discovered thus left it as partial proves "intent" to download. As you were also sharing by default also proves "distribution". Regardless did they take your electronic equipments? like PC/ExtHD/ect? If so are there any incrementing evidence on it? It does not matter if its encrypted or not as majority of EU nation are funny and can jail you if you refuse to hand over your passphrase.

Now normally the biggest problem with our network is the authenticity of the file. So if the movie said WordOfGod.avi it can still be fake cP movie. This is the exact reason majority of us use ShortyPower or Peerates to lookup the hash. If there is no other cP no images/videos/ect located anywhere they can find as evidence then get a good lawyer and prove that the filename in this case was misleading. Which would be hard if the filename itself contains label which describe the content. Only you can be the judge as you know what you did as you have all the details regarding this matter. But as I said if you were in USA thats all DA would need to send you in federal prison for next 10-15years. They would prove intent, possession and distribution.

View Postretsmah, on 07 November 2016 - 06:25 PM, said:

Did you know all this (internal files used by eMule and other info) naturally or did you research it for me question?

But is the UserHash (cryptkey.dat) not encrypted?, and how can the UserHash be verified onsite in a raid (in little time), is there an automated procedure & tool ?


Yes I was part of eDonkey-BlackNET project for Shareaza. I don't use eMule never used it but I was using xMule and now using aMule and been part of ED2K/KAD community for over decade+. You're also focusing on the wrong things, as UserHash does not matter. There are old clients which changes UserHash or used same community based UserHash. What matters is that IP which is how they tracked and raided you and then search yield eD2K/KAD client on the PC with actual evidence.
Posted Image
0

#11 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 07 November 2016 - 11:56 PM

View PostxSTHNSx, on 07 November 2016 - 08:16 PM, said:

View Postretsmah, on 07 November 2016 - 06:23 PM, said:

I am in Europe. But I know for sure that there was no completed downloads at the time, and no known (filename title identifiable) bad files in the partial downloads. (Any info for the raid was probably from some time before)


It would not matter if the contents in question is fully completed or still partial. What does matter is "possession" and the fact you did not delete it when discovered thus left it as partial proves "intent" to download. As you were also sharing by default also proves "distribution". Regardless did they take your electronic equipments? like PC/ExtHD/ect? If so are there any incrementing evidence on it? It does not matter if its encrypted or not as majority of EU nation are funny and can jail you if you refuse to hand over your passphrase.

Now normally the biggest problem with our network is the authenticity of the file. So if the movie said WordOfGod.avi it can still be fake cP movie. This is the exact reason majority of us use ShortyPower or Peerates to lookup the hash. If there is no other cP no images/videos/ect located anywhere they can find as evidence then get a good lawyer and prove that the filename in this case was misleading. Which would be hard if the filename itself contains label which describe the content. Only you can be the judge as you know what you did as you have all the details regarding this matter. But as I said if you were in USA thats all DA would need to send you in federal prison for next 10-15years. They would prove intent, possession and distribution.

View Postretsmah, on 07 November 2016 - 06:25 PM, said:

Did you know all this (internal files used by eMule and other info) naturally or did you research it for me question?

But is the UserHash (cryptkey.dat) not encrypted?, and how can the UserHash be verified onsite in a raid (in little time), is there an automated procedure & tool ?


Yes I was part of eDonkey-BlackNET project for Shareaza. I don't use eMule never used it but I was using xMule and now using aMule and been part of ED2K/KAD community for over decade+. You're also focusing on the wrong things, as UserHash does not matter. There are old clients which changes UserHash or used same community based UserHash. What matters is that IP which is how they tracked and raided you and then search yield eD2K/KAD client on the PC with actual evidence.



So xMule and aMule use the same configuration files as eMule? (you referred to eMule configuration files)?

I was asking about UserHash and other things as during the raid, the Law Enforcement narrowed down the machine of interest to a particular machine, I wanted to know how they would narrow it down to a particular machine in the building. That's why I ask about the UserHash and questions about its encrypted form: But is the UserHash (cryptkey.dat) not encrypted?, and how can the UserHash be verified onsite in a raid (in little time), is there an automated procedure & tool ?

I do not recall any cP being shared or in a download queue (recognisable as cP by files names) at time of raid.

Where I am, on internet news it can be seen that all time everyday there are people who are found with possession of hundreds of cP and are not actually jailed (maybe suspended jail or other things), but extreme possessors are jailed but usually for a few years maximum.

Yes they took all equipment also, no cP stores on them, I am very certain. I am not a user of cP.

What is the 'eDonkey-BlackNET project for Shareaza'?

Have you ever accidently downloaded cP ?

This post has been edited by retsmah: 08 November 2016 - 12:02 AM

0

#12 User is offline   xSTHNSx 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 150
  • Joined: 01-December 15

Posted 08 November 2016 - 12:56 AM

xMule was fork from lMule which was intended for Linux distributions, which is now defunct and replaced with multi platform aMule which was fork of xMule. eDonkey-BlackNET was just mod of Shareaza with extended work in ED2K/KAD since Shareaza also supported multi network like GT1/GT2/Torrent/KAD/ED2K which is also almost extinct now.

I don't see whats so hard to understand as you keep saying how they narrowed it down as its very simple. Do you share internet with everyone in the building? Or do you have internet tier package with local ISP? Look they don't care nor identify UserHash. What they did was found your IP which came from you downloading cP or sharing cP after it was downloaded. Once they had the IP address they subpoena the ISP and got your location. Then with search warrant collected all digital equipments for forensic data analysis. The UserHash does NOT matter so let say if their audit log say IP 10.0.0.1 (UserHash: ABC123) was distributing cP you can't tell the judge as defence that the UserHash does not match. As there are leecher mods which shares collective community UserHash or generate new UserHash everytime. What they care about is IP address and when they look at the PC if they find ED2K/KAD client then they have vehicle method of delivery.

Now lets be very clear on this. Did they find cP on your ./Incoming? yes or no? as you said it was partial download. If it was found was it single file or multiple files? The laws regarding cP depends on Country but in USA we take it very serious and if you're convicted of it basically your life is over as when you do come out of federal prison they will register you as sex offender. You won't be able to live anywhere without majority consent of the community. You're not allowed near local school zone, public park, play ground where they might have kids.
Posted Image
0

#13 User is offline   retsmah 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 05-November 16

Posted 08 November 2016 - 04:18 PM

View PostxSTHNSx, on 08 November 2016 - 12:56 AM, said:

I don't see whats so hard to understand as you keep saying how they narrowed it down as its very simple. Do you share internet with everyone in the building? Or do you have internet tier package with local ISP? Look they don't care nor identify UserHash. What they did was found your IP which came from you downloading cP or sharing cP after it was downloaded. Once they had the IP address they subpoena the ISP and got your location. Then with search warrant collected all digital equipments for forensic data analysis. The UserHash does NOT matter so let say if their audit log say IP 10.0.0.1 (UserHash: ABC123) was distributing cP you can't tell the judge as defence that the UserHash does not match. As there are leecher mods which shares collective community UserHash or generate new UserHash everytime. What they care about is IP address and when they look at the PC if they find ED2K/KAD client then they have vehicle method of delivery.


Local ISP provide internet. I know the process up to the building. I was asking in detail as I wanted to know how, during the raid, they examined several devices (quickly), and determined that a particular one required to be seized (that is the question)

View PostxSTHNSx, on 08 November 2016 - 12:56 AM, said:

Now lets be very clear on this. Did they find cP on your ./Incoming? yes or no? as you said it was partial download. If it was found was it single file or multiple files? The laws regarding cP depends on Country but in USA we take it very serious and if you're convicted of it basically your life is over as when you do come out of federal prison they will register you as sex offender. You won't be able to live anywhere without majority consent of the community. You're not allowed near local school zone, public park, play ground where they might have kids.


Items have not been officially analysed, so unknown what has been found (yet). (I do not foresee having any cP as full or partial downloads, at the of seizure).
0

  • Member Options

Page 1 of 1

Fast Reply

  

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users