The continuing battle between people who offer a service and others who want to hack into the service


In the history of the Internet, there have been many cases of one company providing a service, and others trying to piggyback off the service through a nonstandard client. The result is usually a back-and-forth where the provider changes the interface, the piggybacker reverse-engineers the interface, back and forth, until one side finally gives up.

Once upon a time, there was one company with a well-known service, and another company that was piggybacking off it. (I first heard this story from somebody who worked at the piggybacking company.) The back-and-forth continued for several rounds, until the provider made a change to the interface that ended the game: They exploited a buffer overflow bug in their own client. The server sent an intentional buffer overflow to the client, resulting in the client being pwned by the server. I'm not sure what happened next, but presumably the server sent some exploit code to the client and waited for the client to respond in a manner that confirmed that the exploit had executed.

With that discovery, the people from the piggybacking company gave up. They weren't going to introduce an intentional security flaw into their application. The service provider could send not only the exploit but also some code to detect and disable the rogue client.

By an amazing stroke of good fortune, I happened to also hear the story of this battle from somebody who worked at the provider. He said that they had a lot of fun fighting this particular battle and particularly enjoyed timing the releases so they caused maximum inconvenience for their adversaries, like, for example, 2am on Saturday.

Reminder: The ground rules prohibit "trying to guess the identity of a program whose name I did not reveal."

Comments (32)
  1. Antonio Rodríguez says:

    It would have been fun to sit both parties at the same table, preferably with a few pints of beer between them. It surely would have spawn a few memorable stories :-) .

  2. Zarat says:

    Nice concept, and it actually doesn't need a security hole to implement, by making the "client identification" touring complete. The server could send a script which has read-only access to the clients memory space. Let the script compute some hash of the client memory and send it back and you can identify if the client was 'real'. Randomize some aspects of the script so it can't be precomputed. Also can execute any amount of detection logic to find 'hostile' code loaded into the clients process.

    Anyone wanting to fake such a login process would need to provide a scripting environment mirroring most of the memory state of the original client. Minor changes in the real client or detection scripts can cause huge work for the fake client creators.

  3. Joshua Ganes says:

    Did the piggybacking company try to exact their revenge by exploiting the same buffer overflow for evil?

    With all the work to reverse-engineer and consume someone else's service, wouldn't it have been simpler to just create their own? Perhaps this service was more complex than I am imagining.

  4. R. Bemrose says:

    Is it OK to guess completely nonsensical choices?

    If so, I'm guessing the product was Jif Smooth Peanut Butter being used by Hersheys in their peanut butter cups.

  5. Yuri Khan says:

    You are saying this as if providing an alternate client were a bad thing.

  6. Mark says:

    This story reminded me of the Black Sunday kill, which is worth reading if you haven't already: http://www.codinghorror.com/…/revisiting-the-black-sunday-hack.html

  7. Ian says:

    "Once upon a time, there was one company with a well-known service that used a non-standard protocol, and another company that was trying to reverse engineer the protocol in order to provide an alternative client."

    Which version of the story you prefer depends on your perspective.

    Of course, if the company trying to provide an alternative client was doing so to avoid paying for the service then my sympathies would be with the service provider. Otherwise, it's hard to make the case for non-standard protocols.

    [The types of services people try to hack into tend not to be standardized in the first place. It's not like there's an RFC for "World of Warcraft client/server protocol." -Raymond]
  8. alegr1 says:

    They needed to use HTTPS on the wire. Good luck snooping on that.

  9. Kevin says:

    They needed to use HTTPS on the wire. Good luck snooping on that.

    Um, how is that supposed to help with anything?  HTTPS is a standard protocol that anyone can implement.  Just because microsoft.com uses HTTPS for some things doesn't mean I can't use Firefox instead of IE.

  10. alegr1 says:

    Um, how is that supposed to help with anything?  HTTPS is a standard protocol that anyone can implement.  Just because microsoft.com uses HTTPS for some things doesn't mean I can't use Firefox instead of IE.

    HTTPS can be a transport for an application-specific format of data. If you need to reverse-engineer that data, you need to snoop on it. But how?

  11. skSdnW says:

    @alegr1 HTTPS protects data from A to B, not so much when there is a debugger/sniffer/whatever at one of the endpoints.

  12. Hmm, a company who discovers a buffer overflow and, instead of plugging it, uses it to gain a competitive advantage while leaving the software on my machine vulnerable…

    That kind of thing would make me seek out an alternative client and not want to use the service no alternative was available. :)

    [But the official client connects only to the service provider. And the client is also under the service provider's control. So either way, your machine is pwned by the service provider. (You'd have a problem if the client connected to third party service providers, but it doesn't.) The service provider essentially created a "execute arbitrary code" opcode. -Raymond]
  13. JM says:

    Reminds me of Achilles and the Tortoise: "I cannot be played on Record Player X." Except that in this case, the record player blowing up is the desired effect.

    If I'd been the other party, I wouldn't have given up at the buffer overflow maneuver. No way. Detect the overflow and start emulating the code the server sends over. If I have to emulate a copy of the entire OS to fool the server, by God I will.

    However, I think the other side has a winning strategy in implementing a zero-knowledge proof protocol that verifies the client is byte-for-byte exactly what we expect it to be. The only way the other side can keep up with this is by actually having a copy of the client, at which point you can nail them for copyright violation. That is, if you could explain in court why your adversary has necessarily broken copyright law.

  14. Mike Dunn says:

    An alternate look at the internet: http://www.youtube.com/watch

  15. voo says:

    @Zarat Instead of just giving up, you could obviously ignore the request sent by the server and let your client always answer with the expected message.

    Nobody stopped them from doing exactly the same in this case as well, but I assume it just got too time consuming playing this game.

  16. Anonymous Coward says:

    Voo, the problem is that the server may send a different bit of software any time, and if the client has to give the right answer every time you want to log on, the server devs can generate lots of little puzzles really fast. Since reverse engineering is harder than writing simple puzzles, they could basically DOS the alternate client devs.

  17. voo says:

    @Anonymous Coward: Simple solution there: Send the request of the server to the real client and intercept its answer. Obviously then you'd either have to remove checks done by the client to see if your program is running or hide your own program better. Yes it's an arms race and it's certainly more work for the reverse engineers, but it's still doable.

  18. Gogolkj says:

    Doesn't this violate antitrust laws as being an " predatory innovation?"

  19. cheong00 says:

    @voo: Except that the expected answer can be "salted", and the damage trigger can be hidding in the "answer creation algorithm update". With today's internet connection, a 1-2 MB package can be transmitted in no time. Go luck trying to strip off all suspicious code in that. They can even supply a custom made codec that you must use the salted "reply" to decode the data stream, instead of requiring you to send the reply back.

    In the case of "internet connected service" with client updatable, the service provider aren't likely to fail if they try hard enough. At some point the hackers attempt to create their own replica will give up.

  20. Medinoc says:

    I do see an "easy" counter to this maneuver: Leak to the world that the standard client has an unpatched buffer overflow bug. If the initial client outcry doesn't force the provider to correct the flaw, the first actual malicious use by a third party will.

  21. Anonymous Coward says:

    Medinoc, I know of three cases where something like this happened, two if we disregard BluRay since that isn't really a bug, one if we disregard cases where the connection was not an internet connection. So, for that case…

    What happened was that a rumour was started by someone (I don't believe we know who, and at first the post didn't look legit) and a software analyst verified it. Then there was a big uproar (on internet forums full of geeks, I don't think anyone else cared). The bug is hard to exploit however, since to use it effectively you probably need to use a DNS hijack or some other man-in-the-middle attack. The service provider has promoted the bug to feature and it's still present in the latest version; if you're running it and someone has access to your internet wire say, he can execute arbitrary code on your computer.

    Of course, this also means that if you're using the server provider's client to connect to third-party servers…

  22. Paramanand Singh says:

    In my college days I used to this kind of reverse engineering for popular instant messaging protocols. This was very helpful exercise in terms of learning network programming and also decoding protocols. And I don't consider this wrong. Unless the piggyback company is making some money by reverse engineering it should be OK. But I am sure that they must have been doing this for commercial reasons and that's why the original service provider went to the extent of executing arbitrary code on client.

  23. Anonymous Coward says:

    Paramanand, in the case that I was thinking of (which I shan't name, so don't ask) the client program was used to connect to a functionally similar service (but using a different protocol). The piggybacking was added for interoperability purposes. This would make it possible to use both services without the need for running two clients. If I recall correctly (but this is a long time ago) both clients were ad-supported.

    In the other case that I mentioned (that didn't use an internet connection), the purpose of running the server-supplied code was to stop people from using the service without paying for it; there was also no risk of the problems I mentioned earlier, so that's fine.

  24. James says:

    >> But the official client connects only to the service provider

    The client could be connecting to an attacker that can hijack DNS or TCP connections (e.g. on a public wireless).

    They could achive the same effect in a more secure way.  For example sending a *signed* piece of code or the client to execute.

  25. Anonymous Coward says:

    Dave, when you remove the buffer overflow bug as such and just consider it a new execute signed code opcode, you could verify the signature with a public key embedded in the client before running the code. That stops the security vulnerability, and potentially makes it possible to tie the client to the official server.

  26. Jaloopa says:

    "executing arbitrary code on client"

    I think you mean "Random code" ;)

  27. Dave says:

    @Anonymous Coward:

    >you could verify the signature with a public key embedded in the client before running the code

    And the fake client would look at the signature, throw it away, and execute the code anyway.  At this point you're back to square one, both the real client and the fake client are running your checking code.

    [AC was explaining how the real client could avoid being pwned by a rogue server. -Raymond]
  28. Raphael says:

    @Medinoc:

    I see that you live in some kind of parallel universe where users care about security. *We* live in a universe where people open that mysterious email attachment to see naked pictures of Scarlett Johansson.

  29. Dave says:

    @James:

    >They could achive the same effect in a more secure way.  For example sending

    >a *signed* piece of code or the client to execute.

    And what would that achieve?

  30. Cesar says:

    @Brian_EE: If you follow the link, the actual rule is "no outing". I believe several of us know which service and which client Raymond is talking about (it was in the tech news back then, and it is such an unusual thing that we can remember at least which service it was). But Raymond does not want us talking about the software and companies involved (it is all ancient story anyways, the service is not as popular as it used to be); the point of Raymond's post is to talk about the concept (exploiting a buffer overflow in your own client). Like AC's digression on how to make that safe, for instance.

    I believe even saying the genre of the service, or the time frame involved (other than "it was long ago") would help people who do not know about it finding out who was involved, which goes against at least the intent of Raymond's "no outing" rule. So (correct me Raymond if you I am wrong) I believe you should stop here.

  31. Medinoc says:

    RE those who answered me: I am now depressed. That's what I get for forgetting common mortals are not me.

  32. @jaloopa says:

    No. "Arbitrary code" is more correct than "Random code".

    "Random code" suggests that the attacker doesn't get to choose what runs – and in practice the application will crash. "Arbitrary code" means that the attacker gets to steal your credit card information and install a rootkit on your machine.

    [Jaloopa was making a joke. -Raymond]

Comments are closed.

Skip to main content