I actually had a similar frustration for Half-Life 2 single player. Valve originally hard-coded the field of view (fov) to 75 which caused intense motion sickness for me (for some reason). I enjoyed the game immensely, but I still had to go lay down for 20 minutes for every 20 minutes of play.
In the first few weeks of the game (before they patched it to be less restrictive), it ignored and reverted changes to the game fov with some sort of bizarre level of meanness. They really wanted the fov to stay at 75 for some sort of game experience reason.
I edited the game binaries to remove the forcing of that field of view back to 75 (using VC6's binary editor after using SoftICE to monitor the code that was changing the value in memory) so that I could play the game without getting sick.
that's very interesting. i've always had terrible motion sickness problems with some games. i remember trying to play the original half life... it was jarring. playing 1 minute meant a painful headache for the next hour. 5 minutes and i would have a painful headache for the whole rest of the day, no joke. thankfully Dramamine helped out a lot
who woulda thunk the FOV was a potential culprit O_O
I has a player of one of my games pull a similar stunt on me.
He was sick and tired of other people using bots to cheat the game. He made some correct assumptions about my architechture, Memcached in front of MySQL, and determined a way to find pages that would guarantee a cache miss. He then wrote a bot to hit as many of these pages as possible, essentially blackmailing me into fixing the bot problem.
A simple captcha and a few bot honeypots later, the problem was fixed.
Discussions about the ethical implications of patching a DLL aside, it is quite a different thing to patch a DLL to prevent an application from crashing when you use it than to hammer someones server in an attempt to force them to fix a problem.
Can someone explain how one might do something like this? I get that you can use some sort of disassembler to read the code, but how did he insert his check without upsetting the machine code's memory offsets?
There are two (easy -- there are others) ways to pull it off. One is to replace instructions in the area with smaller ones, and take advantage of the open space. This is generally fairly easy to do, as compilers are terrible at generating code that's both fast and small.
The other way to pull it off easily is to replace an instruction with a jump to another part of code that's empty/unused, where you put the original instruction, your new ones, and a jump back to the patch location.
You use a disassembler to read the code, but accept that static analysis is a hard problem you might as well be looking at garbage.
You use runtime disassembly, the primtive disassembly feature built into most systems level debuggers (and the one good systems level debugger ;-)
You can replace instruction in memory with the 'a'ssemble command you can test your hypothesis without affecting that actual code on disk. Once you path the program in memory and see everything to your liking, you fire up a hex editor and patch that memory region. Patching is an art; if you new instruction can overwrite a region of the code, you can insert a jump to the new instructions, then 'ret'urn from them with another jmp to your call point. If, otoh, you're adding more code than the instructions you're replacing, then you will need to find more places to stuff it, or you might need to reconstruct the program header and adjust the sizes.
Reversing and binary patching are two different but related arcane arts. Reversing is the understanding, patching is the modification. Many people do both, but just understanding one doesn't mean you can understand the other. When it comes right down to it, binary patching can be done in a million different ways, regardless of how the reversing was done, and it doesn't get nearly the respect it deserves. Most people tend to lump reversing and all related (binary patching, anti-anti-debugging magic, etc) arts together, but they all deserve separate discussions and explanations.
(Sorry for the extremely long winded, slightly off-topic reply.)
As linux user I cannot be anything but glad to see skype developers a little bit pwnd. What is wrong with skype? They detain the monopoly on VoIP and yet they have not been able to keep up with the development of the program in years, now. It seems it is all about selling headphones on the website.
I think the linux version is something like 2 years old now.
According to Wikipedia, a monopoly "exists when a specific individual or enterprise has sufficient control over a particular product or service to determine significantly the terms on which other individuals shall have access to it.".
Given Skype's market share (not Voip in general, but free worldwide voip calls), I would say they do have a monopoly.
they run a service with a significant market share, proprietary protocol and client, and no interoperability with any other standards-compliant service. You are free to not call them a monopoly.
As far as I understand, Skypemate is a hardware phone made by company named Yealink and designed to work with Skype. It is not made by Skype, and that can possibly explain why it is not so polished and bugs are left unaddressed for long time.
If the user really cracked Skype, as the title made me believe, this would be big news. I have been told that Skype's protection is really tough.
Skype voice encryption is really though, meaning that agencies can't tap Skype. Change the machinecode of a program on your own pc is something entirely different.
Like the resume of a friend I read once (Stanford, Microsoft, etc.), I like how the guy talked about what he did (a fairly difficult debug/patch) in a low-key manner.
No, I think you're probably thinking of someone else. His resume had no fluff. Sometimes it's like you look at normal people's resumes and they try to fluff it up. His was like: "Proficient: MFC, Win32, C++, C, Japanese...Stanford CS GPA 3.93 etc..MS SoftDev Intern". And it didn't take up the whole page.
I'm curious what the Excel multi-threading issue is/was though.
My bad, you are right. I thought the original link was referring to the XP mode workaround listed by another author. When I checked the page again, I realized that the link anchor was pointing to a different post.
Why is that cracking? It's just a hack; patching a binary to fix a bug is by no means a crack IMO. A clever hack? Sure, but calling it a crack just serves to make it sound like a bad thing.
That was my big take away too and my sense was that in another forum, he would have used the term hack. But it's easier to explain it away as a crack to convey that users should observe caution, share it quietly, and also to piggy back on a commonly held notion that it won't break or otherwise harm any system (such as the service being used).
Skype is known for their insane obfuscation (to prevent reverse engineering of the protocol), though it doesn't sound like that's applicable in this case.
Damn - I was expecting to see something horrific in your comments judging from all the downvotes (had to highlight to read). What was so annoying about this comment? Relax folks!
In the first few weeks of the game (before they patched it to be less restrictive), it ignored and reverted changes to the game fov with some sort of bizarre level of meanness. They really wanted the fov to stay at 75 for some sort of game experience reason.
I edited the game binaries to remove the forcing of that field of view back to 75 (using VC6's binary editor after using SoftICE to monitor the code that was changing the value in memory) so that I could play the game without getting sick.