Kenois (http://kenosis.sourceforge.net/) is a project based on Kademlia and already has a modified bittorent client running on it so kenosis maybe used for the engine for this kind of project .This would make the client cross paltform and open source and probably gain the respect of the file sharing community if done in the correct manner and could be a good launching point for a up and coming developer.

Bram Cohen works for Valve where he works on Steam that goes unpubliced and it is said Bittorent was his resume’ .Bram also makes indusrtry appaerances as a guest speaker on a regualr basis .

Heres a interseting post from /. regarding reverse engineering the current exceem protocol done with a bit of packet sniffing and hex editing .

“A look at eXeem.exe and client.dll show that eXeem uses the C++ Boost library, as well as the Crypto++ library. It also includes cydoor, and references CyberGold.

As far as the eXeem protocol, when eXeem first tries to connect to the network (by doing a search, refreshing for new files or whatnot), it bootstraps. It does a lookup on 4 DNS names, all of which point to the same IP address. The eXeem client program (TCP) connects to port 1026 of this host and sends an eXeem protocol packet.

The eXeem protocol packet from client to server or SuperNode is of the following format – a 0, followed by a one byte function code, followed by an optional payload, filed by 8 seemingly random generated bytes which are suspected to be a Blowfish key (thus the Crypto++ calls in eXeem). In the case of the bootstrap, there is no optional payload and the function code is 6. Thus the packet sent is 0-6-X-X-X-X-X-X-X-X, with the 8 bytes being what is guessed to be a randomly generated Blowfish key. The bootstrap server responds with a number of Superpeers. It is thought that the response is encrypted with the possible Blowfish key sent by the client.

Another eXeem packet is new files refresh. When one does this, eXeem connects to the roughly 20 SuperPeers it knows (which should be in your registry), usually on port 4000 (although 4001 has been seen). The function code is 8. As I said, the last 8 bytes of the packet vary, so only the first two bytes will always match in this example of a search packet (in hex): 00 08 f8 a6 16 39 4a 0a 96 eb.

Search packets have a function code of 22 (in hex, 16). They always carry at least 16 bytes of the optional payload. The first 8 bytes of the optional payload are thought to be search parameters (language, categories, file size etc.) The end of the optional payload is thought to be the actual word(s) being searched. For names 8 bytes and under, the end of the optional payload is 8 bytes, for names 9-16 bytes the optional payload is 16 bytes, and so forth, in increments of 8 bytes. The search is thought to not be encrypted by the possible 8 byte key at the end of the packet. Thus a search may look like this (in hex): 00-16-8e-94-58-40-af-c2-08-39-2a-55-16-53-c4-0a-75 -4b.

There are other parts of the protocol as well which won’t be gone into here…request for file comments which is function code 25 (19 in hex) from client to superpeer, and the function code response code varying on what the answer is and so forth.

With Crypto++ in use, which possibly calls Blowfish, the protocol seems to be encrypted (why else would they include Crypto++?), and whether it is easy or difficult to figure out is unknown. It depends on whether people who know crypto, specifically Crypto++ and possibly Blowfish, and/or who are good at loading these programs into hex editors or assemblers or whatever and figuring them out. Winedbg doesn’t seem to be cutting it.

By the way, eXeem lite’s web page lists it’s IRC channel. As usual, most of the people on it are clueless people trying to get eXeem lite working, but people who have been examining eXeem and understand it someone pop in from time to time. “