Hacked µTorrent

[luk32]

It's better can be done silently behind user's eyes, since i guess not every body wants to know this kind of stuff, like beginer users.

However, in my opinion it's just a partial solution, i don't like to repeat myself but i still think that you can fake any data, including hashes and everthing that you need to proove your identity.

Even though i don't like solving problems by handlig any special case in a different way, there's no complex solution. So if this would work against just some cheaters or make harder to do so, it's good. Of course as long as this won't produce any unimportant casualities, like with permanent ip banning.

Personally i was thinking about kick-on-chaitng-detection, to avoid ban, but some could try to reconnect very fast. Temp ban like 5minutes in client or 30minutes on tracker[i still feel unconfortable about "ban on tracker" idea], would do it's job, and not cause too much harm i my opinion, but it's highly unprofessional

[osm0sis]

on a download i'm running right now i'm seeing a number of users listed as µTorrent/1410 instead of µTorrent/141B are these people running the hacked version?

[splintax]

They might not be doing something ethical but it can't be illegal.

It may be (I'm not a lawyer or even an American) that under the DMCA's provisions regarding reverse engineering and such that this is illegal. But I doubt it. :/

and you know.. at the end of it all, someone can just write a proxy that modifies the response from the tracker so it looks like it's the tracker saying that DHT is allowed..

Specifying the private flag in the tracker URL is insecure. That's the method BC uses by default, IIRC, but most other clients specify it in the .torrent. Having said that, hex-editing out the "private flag" from the .torrent might be possible but wouldn't that change the hash of the torrent?

... also banning ip isn't good method of solving the problem, actually it's just poor work-around.

I think we were talking about a temp IP ban (like 4 or 5 hours or something). It's a pretty decent idea IMO.

How about an advanced feature:

Temp ban (like ban for bad hash) on fake id clients.

Great idea.

osmosis: They're probably just using the latest beta, IIRC the "hacked version" does not change the reported client ID at all, it just ignores the private flag.

[Firon]

it's not illegal, because there isn't any DRM or copy protection I think...

And yeah, taking out privatei1e from the torrent would change the infohash

[osm0sis]

weird. i would think the latest beta would report 141B like the others.

[splintax]

Firon: Does ludde not use the encrypt option in PECompact? I'd imagine that circumventing that and then hexediting the software would make it illegal under the DMCA (same thing applies, basically, pure speculation )? Maybe this would be an idea..

And that's something else I had always wondered about but never bothered to look up, the hash of the torrent (displayed at the bottom right in the general tab) is the hash of the actual .torrent then. I wasn't really sure. Thanks

edit: osmosis, what I said was just a random guess. I don't know if it's the beta or not, but it seems odd that someone would hack the client to give that ID.

[Firon]

No, he doesn't use it.

[Switeck]

I have another take on the subject.

Maybe it's not copyright infringement as certain companies (BSA/MPAA/RIAA) call it, but it might be something else...plagiarism.

This hacked client is making no efforts to state itself as anything other than what ludde made. That is morally wrong. It might also be a civil crime.

To do such in someone else's name is simply shameful.

However a temp ban for fake clients would have no effect on it, since remotely it is probably indistinguishable remotely from the real µTorrent v1.4.

Still, BitComets that masquerade as µTorrent or even Azureus are already detected by µTorrent as fakes. For awhile µTorrent got banned unfairly from a couple trackers because of BitComets faking µTorrent's client id. I think it would be fair and fitting if µTorrent bans them now, ...optional of course, but on by default.

If implimented, this would also be symbolic of what ludde thinks of hacked and fake id clients.

Should they be tolerated and treated equal in all regards to others who really do try to play fair?

[The Mighty Buzzard]

Just a short note to everyone who keeps suggesting making µTorrent unhackable; you can't. If it were possible you wouldn't be able to find no-cd cracks for your pirated and/or legit games because they do exactly the same thing. To crack a program you decompress, then decompile the executable into assembly language, alter the code, and recompile.

There are two things that make this difficult:

1) assembly is a bitch to work in

2) programers can make the important bits very complex if they have the skills/patience

In poker all you need is a chip and a chair. In cracking all you need is a debugger, vi, and nasm.

[splintax]

One thing I don't understand is how µT has been able to detect the fakes so far. Firon, you mentioned that in the client ID string there is something at the end (/udp0 or something like that). Isn't it a really stupid mistake for the client ID hackers to leave this in there?

I don't understand how we've been lucky enough to be able to detect all fake µT clients so far.. :/

[luk32]

How do you know if you detected all the fakes =D

or, how would you know if you didn't

[Firon]

The detection is far more compelx than that.

[z00z0]

You can't make it unhackable, but you can sure make it a bitch to hack, and it is not that difficult (you don't even need a tracker or an encryption):

- the trigger: do multiple checks from different places in the code, and run them (seemingly) randomly: like run a check after 1-3 hours of usage, run a check after 3-6 torrents in the list, run a check after there is letter 'x' in any of the rss feeds, run a check when there is 13-17 'i' letters in the loaded torrents name, run a check after 20-50 megabytes have written, run a check after minimized 5-10 times... lot of possibilities

- the check: besides the simple a crc: at first run create a torrent between the loaded torrent files which is actually a copy of the original exe and check random bytes between them, or into the resume.dat or settings.dat at first run put at least two values first a 20-30 bytes random range, then the actual 20-30 bytes data - you can even put a byte shift or a xor on them, but not really needed

- the punisment: after detection there must be some time: like 5*(number of torrents loaded) in minutes, or 6*(the last byte of the first torrent's size) in minutes, then you can do a silent update with restart (from a backup location - this is the best, like you split the aprox. 100 kbytes on first run to 4 parts and put the parts into resume.dat or settings.dat - or do it from the web)

This (not too difficult) mechanism would even protect a commercial program (from at least the 'hackerwannabes'), but sometimes when you want to defend your program it doesn't really matter if you get money for it. You want to defend your "creature", and the reputation of the program. Is this mechanism is really neccesary for µTorrent? You decide.

[Inf]

You forgot an important part, the check must not be a single function that does it, called from multiple places, or your "wannabe hacker" will simply patch it and thats all. Also, the code must be different in each and every place, placing multiple copies of the same code would be patchable by search and replace for a specific code seuquence.

In short, making it a bitch to hack can also be a bitch to code & debug, and may introduce more problems than it solves because of the bugs with the "hacker protection" stuff.

Also the punishment, it would get me REALLY mad if it downloaded ANY code and run in silently without my permission (hint - bugs happen) !!!

IMHO this is simply not worth it, just ignore those hackers, thats all.

[luk32]

[EDIT] It's of course a feeling after reading z00z0's post but inf replied earlier. But z00z0 is not the only one, who made me feel like some just don't get something.

Maybe i do not understand something, because i still don't see much more difficulty in disabling all those check procedures; at least not much more than manipulating in procedures.

So please anyone, correct me, or don't try to write another "easy but close to ideal checking procedure" with out thinking firstly.

My statements are:

1. You cannot "really" protect the program via internal checking. [by "really" i mean, that simple knowlegde on assembler debuging and hex editing is enough to disable ot bypass the checking].

2. It must be done by something external, like another process, the more independent from client the better it is.

3. You can easily bypass any procedure to do-nothing, only trouble would be keeping same checksums, but it's still in reach.

also...

4. it is easy to send fake checksum on external machine request, or the fake copy of "itself"

5. it is harder to cheat checking procedure when it's separate process on the same machine, but it's easier to "hit" the checker.

Sorry for being bit offensive, but i feel like many people, don't understand or don't read what was "said" earlier in the discussion.

I know that i'm don't know nor understand everything and I may be totally wrong.

So if anyone thinks i am wrong, tell me, explain it, make me wiser and i'll apologize

I know that there are some preety well-doing anti-hack systems.

I think only few can imagine how complex and huge they are.

Sorry for my english and thx for reading, Luk32.

[The Mighty Buzzard]

One more quick bit because it's been mentioned so many times. Hex editing is to hacking what nose-hair scissors are to industrial chainsaws. That is to say it's pansy-assed and you can't actually do anything fun.

luk32, you can make it hard enough to find everything that it'll make the code monkey who's trying to figure it out in his debugger want to kick children and puppys.

z00z0, to get it that difficult you'll have to spend more time on security than on the actual client, and you'll have to continue doing it because it will keep getting cracked. Difficult protection schemes are more likely to be looked at as a thrown gauntlet than as an actual deterrent by the kind of people who screw with assembly for fun between dinner and Southpark.

[z00z0]

You forgot an important part, the check must not be a single function that does it, called from multiple places, or your "wannabe hacker" will simply patch it and thats all.

I see you know this stuff, maybe more than me Actually I didn't forget it, i just thought it as default, like the no messagebox saying "bad crc, quitting", or putting in the faq that "don't worry, the program checks crc every 15 minutes"

Also the punishment, it would get me REALLY mad if it downloaded ANY code and run in silently without my permission (hint - bugs happen) !!!

If someone deserves punishment, than this is the minimum, but i think you were thinking about what if the checking code is buggy. Well, i think update from a backup place is always better, and with approx. 100 kbytes you can hide it anywhere. Although with silent update i wanted to say update to the same version as before - like from patched to unpatched. Also this method would fix the spreading of the patched versions.

Maybe i do not understand something, because i still don't see much more difficulty in disabling all those check procedures; at least not much more than manipulating in procedures.

Beleive me, if you have similar routines coded inside, it is a bitch to crack. Btw. the another process idea is very nice, i like it! Maybe i will use it the next time i code. May i?

@The Mighty Buzzard:

You've got point there, it is really a cat mouse chase, and sometimes very much time is needed to create a good protection. Creating a heavy protection sometimes also involves creating a decoy protection for kiddies to patch, and an hour later the application patches itself back to the original In this case i can barely guess if protection is needed, or if it is needed than how much. I don't really know and i won't be the one to decide. But if it would be my application i would spend a lot of time on it, and more if the hacking would gather disadvantages (like if µTorrent is banned because it doesn't respect the private flag because of patching).

[Inf]

Well, i think update from a backup place is always better, and with approx. 100 kbytes you can hide it anywhere.

Btw. the another process idea is very nice...

... the application patches itself back to the original

Hide a code somwhere on my PC ?! Use another process just for antihacking monitoring ?! Patch itself without my explicit permission ?!

At the moment uT does all or some of that, i am not using it anymore, and i bet i am not the only one. All those things IMHO are worse than the little patch that idiot just made.

Come on, open your eyes !!! Your medicine is much worse than disease !!!

[z00z0]

@Inf:

Don't worry, i'm sure µTorrent don't do any of those

Hide a code somwhere on my PC ?! Use another process just for antihacking monitoring ?! Patch itself without my explicit permission ?!

These are the things sometimes needed, and maybe some of your currently owned apps do the same thing:

- apps sometimes do hide some stuff somewhere in your hard drive especially if they are the 30 day and not more type apps. They can't be reinstalled, only after a Windows reinstall, or sometimes not even then. Where do you think they keep your 30 day ticket?

- some of the packed exe protection shemes just do the same thing: unpack to a new process, and keep the original (or originals) for checking crc/decoy/whatever

- again some packed exe schemes do patch the main process runtime, also some shareware programs do the same patching themselfs where a cracker would crack them

As i know if you ever installed a VBox protected app, you got all the three. Earlier i helped a fellow team in creating a copy protection system - the project failed, but i'm glad, that i did some research in the topic. These are the things, that the normal user won't ever spot (if it is coded well), and you won't ever get any disadvantages of the protection itself. It is like sausage making - if you don't know what's in it it won't hurt

[Inf]

Don't worry, i'm sure µTorrent don't do any of those

I know, and i dont want it to start now.

Where do you think they keep your 30 day ticket?

In registry sowmhere near some system settings, or using some keys with \0 inside. In a file at some place i'll never be able to find easily. In NTFS alt. data stream. etc etc etc

Wherever it is, first - i DON'T like it, second - there is a difference between hiding an instalation date and hiding a code, even a backup code !

some of the packed exe protection shemes just do the same thing: unpack to a new process, and keep the original (or originals) for checking crc/decoy/whatever

again some packed exe schemes do patch the main process runtime, also some shareware programs do the same patching themselfs where a cracker would crack them

And ? If others also do that kind of crap, it doesnt make it any less evil.

As i know if you ever installed a VBox protected app, you got all the three. Earlier i helped a fellow team in creating a copy protection system - the project failed, but i'm glad, that i did some research in the topic. These are the things, that the normal user won't ever spot (if it is coded well), and you won't ever get any disadvantages of the protection itself. It is like sausage making - if you don't know what's in it it won't hurt

I am all against this approach. This way you will sooner or later suggest things like integrating a root-kit with some antidebugging crap and some nasty payload hiding under it to punish someone that attempts to debug it.

Again, at the moment i find out that a software i use using this kind of stuff, i would just find a way to clean out the junk and would simply switch to an alternative. Feel free to disagree with me on this, but thats my opinion, and it is not going to change.

[Switeck]

µTorrent could rehash itself and combine that hash with the hash of whatever torrent it's downloading and transmit that value to other µTorrent clients. They would all have the torrent in question to compare the hashcodes. Since the hashcode for µTorrent is generated on-the-fly and the hashcode actually sent is based on a combo of that and a torrent hash, at least that side is pretty good. The problem is the "solution" hash value would have to be stored in µTorrent...which a really determined hacker could find. But they might be harder-pressed to know how to combine that with the torrent hash to pass the "secret handshake".

...at the least it might defeat the casual "hacker" with a hex editor.

Also, this could be done so µTorrent could tell if it was corrupted by a virus as well.

The compression scheme µTorrent uses simply has to be combined with some sort of "armoring" encryption to fight these kinds of hacks.

Either that, or just accept your program is likely to get hacked regardless of what you do...and instead don't waste time trying to fight it.

[luk32]

LOL, i know that hexediting and any reverse enginering can be ... umm.. how to put this well, like masochistic plays with used toilet uncloger. [Not that i've tried, but i think i can imagine how it would feel like]. I've spent enough hours trying to "hack" my around 50-byte com [not to push myslef, if anyone ever compiled someything with any assebler on PC you know it's the pure code and nothing extra, so easiest to alter] which was bouncing the '*' of the screen edges

I was just talking about possibilities, I know that in fact, even to change some text, in even pure assembler "Hello World" com, is hard, at least when you want something longer . I wouldn't risk my sanity to do such thing, especially if the data was on the begining of the file and there was some extra procedures, like line printing.

You need to change every address... omg, i think those who uderstand this, know it...

When I was speaking of easiness of something, i meant, like " I imagine, that compared to altering some procedures, or to what was done it is..." easy, or would be hard.

Not that every one who finds himself well-oriented in comupters [like programming, servicing, helping folks to reinstall systems you know, wide meant common knowledge] could pass such checking. I know it very well.

But you know, i like really nasty complex solutions.

You may say that one vaccine will not cure all the illnesses, true... but i'm not so easy to change my mind.

Personally think, that folks who tried some hacking and antihacking, know which ideas are really nasty.

Anyway i think, my statemenst are true, even if the inside checking can be coded such way, that half of folks would choose death on a toilet that to hack this, but still there would be some, that would pass it with a finger in their nose.

Why not to make competition to them instead of splashing the water to scare some guppys

Any bad, beside's coding it could be, like summoning a wolf, e.g. when someone really good, would just crack it for teasing, only because he given a challenge.

@z00zo: I am sorry for not showing you respect at first, and the idea of creating a guardian process is kind of known i think...

@inf: I belive that all of us are just theorizing. I don't think even, if we suggested something like that, would be placed in uTorrent. Don't forget who's in charge, i think "our" developers are well-thinking and feel responsible enough not to code every insane idea, we are talking about

[z00z0]

Again, at the moment i find out that a software i use using this kind of stuff, i would just find a way to clean out the junk and would simply switch to an alternative. Feel free to disagree with me on this, but thats my opinion, and it is not going to change.

Maybe i'm wrong, but as i remember (it was a long time ago) even Adobe Photoshop CS2 demo used vbox protection. Although i agree with you, sometimes you just can't find a good alternative, and you have to "swallow the frog", and live with it. Just remember the Sony CD copy rootkit stuff. Certianly it wasn't a good idea, and i'm against this effort, but it is a well balanced weapon against the tools of illegality. But now we are far offtopic.

[z00z0]

... splashing the water to scare some guppys

Nice Cracking guppys!

[splintax]

The detection is far more compelx than that.

Oh, okay, good to know. I won't ask how it works, then.. (especially since that could help hackers improve their patches :/)

Well, I'm finding all these suggestions interesting, but I really don't think that µTorrent should do any more than just encrypting the executable with PECompact. More and debugging gets ridiculous.