TBone
March 3rd, 2004, 18:53
I'm not really sure why I'm sharing this except that perhaps it'll make someone feel nostaligic for their first reversing experiment. It's kind of long - apologies in advance. I'll be as generic as I can about the target without completely ruining the point of the story. I think I've browsed through the forums enough to get a general feel for what you can and can't talk about, but if I overstep a bound, let me know.
I've orbited around the reversing/cracking scene for a long time without ever really diving in to the fray. I've always been one of those "don't tell me how to use it; tell me how it works" kind of people. Why learn about chemistry before you've learned about quantum electrodynamics?
. If you know how the nuts-and-bolts work, it's easy to deduce the rest. But be that as it may, I've never really got into it as a hobby because I never really had a practical reason to.
Well, all that changed thanks to a odd little piece of equipment. I have a professional GPS surveying system. It consists of two receivers - a base station and a "rover". The rover hooks in to a data collector, which can transfer the data to computer with a serial cable and a kermit program of your choice. Amusingly enough, the data collector is driven by an 8088 processor - that thing is a reverse engineering project all by itself.
But my problem was with the data it collects. As I said, getting the data off the collector is easy; the hard part is making something meaningful of it. The data is stored in a very proprietary (pronounced: "WEIRD"
data format., consisting of raw latitude and longitude information for each point, dillution of precision information for each point, coordinate system information (i.e. how to convert from the raw lat/long to a state plane coordinate system), etc.
Now fortunately the manufacturer of this system sells it with piece of software that retreives the data from the collector, converts it to the desired coordinate system, and spits out a comma-dilimited ASCII file of X,Y,Z coordinates and point descriptions. Yay. At first all went well. Inexplicably, the software includes a copy protection system of the challenge-response variety. I.e. it gives you a serial number, you give that to the company, who gives you a registration code that matches whatever infernal algorithm they use to mangle and compare the two. As time went by, computers would get replaced, re-imaged, or (in once instance) exploded. Thus we needed replacement registration codes to keep us in business.
At first they were reasonable about this and gave us whatever we asked for. But somewhere down the line they decided that their software (which to this day is licenseless, mind you) was some kind of holy grail that everyone in the world would want to use. Why, I have no idea. Its only conceivable use is for retreiving data from their data collector, and no one would need to do that unless they owned one. Mind boggling. Their excuse was that various bloatware functions in their software had commercial value to a horde of surveyors and engineers who were apparently clamoring at their door to use this software for actual analysis and design work. Bullshit, says I. There are programs for doing that kind of thing, and they're called CAD packages. Using their backwards PoS software for engineering would be like using a jagged rock to saw a board. Sure, you could do it, but no one in the right mind would.
This meant war. We bought ~$25,000 worth of equipment from them, and part of that deal was that we could get the data off of the survey unit and into CAD. We never agreed to anything about only installing one copy of their software, and now they were trying to change the rules. So we told them that they could either give us a new registration code, or talk to our lawyers. For a while that worked. We got them to cough up one or two more keys, and then they just started ignoring us. Literally - we'd send them emails and they'd just flat-out refuse to respond. Things got bad. There was only one computer left in the office that still had a functional time-trial left on it, and it had only 2 or 3 more uses before it went kaput.
So I dusted off a few old ASM reference books and went to work as best as I could. Once upon a time I could actually do at least basic ASM programming, but that was easily 6-7 years ago, and I've got a mind like steel seive. Armed with W32DASM and a passing knowledge of very basic ASM commands (MOV, JMP, Jxx, ADD, SUB, etc.) and practically no knowledge whatsoever about how W32 apps are compiled and linked, I wasn't very optimistic.
It turns out I had naively over-estimated the intelligence/deviousness of most small corporate programmers. I remember that back when I was 11 or 12 (this was roughly a dozen years ago) I had one of these "1337 h4}{0r" friends (you know the kind). He told me in his infinte wisdom that most copy protections could be defeated simply by changing a single instruction to skip over the failure algorithm and go straight to the success algorithm instead. I thought, "surely programmers aren't still using the same decade-old methods that are so easily broken?" Surely they are. It took all of about 15 minutes to find the failure message ("That Which Shall Not Be Named has expired!" and backtrack to where the conditional jump was. NOPed a couple bytes and all my troubles were over! What a peculiar feeling.
Later I found a better solution. My first workaround told it to continue with normal program execution even if the program saw that it was unregistered (i.e. it never processed the "You have X remaining executions before blah, blah, blah" code). I improved it a little by just skipping over the portion of code where it checks to see if it was registered in the first place. Is I learn more, I'll go back and see if I can reverse their validation method, which is in a separate executable, and make a keygen from it. While I'm at it, I'll figure out how the program determines if it is registered or not, and what the validation program does to register the program when you give it a valid key.
Thusly inspired, I started poking around in an third-party .arx file for AutoCAD which had been giving me trouble for similar reasons. I won't go into the gory details, but suffice to say that .arx files are cute. They contain an indordinate amount of plaintext data in order to pass their function data to the LISP subsystem of AutoCAD. That makes them substantially easier to reverse than normal executables, and this time I was able to find what I was looking for in about 5 minutes. NOP NOP, bam. This could be addictive.
I'm not sure whether to be delighted or disgusted that I could apparently train a chimpanzee to "crack" a very large portion of commercial software. You'd think that people might learn something and put some new ideas to use once every few decades.
Anyway, thanks for the invaluable mine of information around here. Two major annoyances in my life are now removed from the equation. When I get a little free time I think I'm going to pursue this as a more active hobby. I've got a few oddball programs and devices that I have always made me wonder what makes them tick.
I've orbited around the reversing/cracking scene for a long time without ever really diving in to the fray. I've always been one of those "don't tell me how to use it; tell me how it works" kind of people. Why learn about chemistry before you've learned about quantum electrodynamics?
. If you know how the nuts-and-bolts work, it's easy to deduce the rest. But be that as it may, I've never really got into it as a hobby because I never really had a practical reason to.Well, all that changed thanks to a odd little piece of equipment. I have a professional GPS surveying system. It consists of two receivers - a base station and a "rover". The rover hooks in to a data collector, which can transfer the data to computer with a serial cable and a kermit program of your choice. Amusingly enough, the data collector is driven by an 8088 processor - that thing is a reverse engineering project all by itself.
But my problem was with the data it collects. As I said, getting the data off the collector is easy; the hard part is making something meaningful of it. The data is stored in a very proprietary (pronounced: "WEIRD"
data format., consisting of raw latitude and longitude information for each point, dillution of precision information for each point, coordinate system information (i.e. how to convert from the raw lat/long to a state plane coordinate system), etc.Now fortunately the manufacturer of this system sells it with piece of software that retreives the data from the collector, converts it to the desired coordinate system, and spits out a comma-dilimited ASCII file of X,Y,Z coordinates and point descriptions. Yay. At first all went well. Inexplicably, the software includes a copy protection system of the challenge-response variety. I.e. it gives you a serial number, you give that to the company, who gives you a registration code that matches whatever infernal algorithm they use to mangle and compare the two. As time went by, computers would get replaced, re-imaged, or (in once instance) exploded. Thus we needed replacement registration codes to keep us in business.
At first they were reasonable about this and gave us whatever we asked for. But somewhere down the line they decided that their software (which to this day is licenseless, mind you) was some kind of holy grail that everyone in the world would want to use. Why, I have no idea. Its only conceivable use is for retreiving data from their data collector, and no one would need to do that unless they owned one. Mind boggling. Their excuse was that various bloatware functions in their software had commercial value to a horde of surveyors and engineers who were apparently clamoring at their door to use this software for actual analysis and design work. Bullshit, says I. There are programs for doing that kind of thing, and they're called CAD packages. Using their backwards PoS software for engineering would be like using a jagged rock to saw a board. Sure, you could do it, but no one in the right mind would.
This meant war. We bought ~$25,000 worth of equipment from them, and part of that deal was that we could get the data off of the survey unit and into CAD. We never agreed to anything about only installing one copy of their software, and now they were trying to change the rules. So we told them that they could either give us a new registration code, or talk to our lawyers. For a while that worked. We got them to cough up one or two more keys, and then they just started ignoring us. Literally - we'd send them emails and they'd just flat-out refuse to respond. Things got bad. There was only one computer left in the office that still had a functional time-trial left on it, and it had only 2 or 3 more uses before it went kaput.
So I dusted off a few old ASM reference books and went to work as best as I could. Once upon a time I could actually do at least basic ASM programming, but that was easily 6-7 years ago, and I've got a mind like steel seive. Armed with W32DASM and a passing knowledge of very basic ASM commands (MOV, JMP, Jxx, ADD, SUB, etc.) and practically no knowledge whatsoever about how W32 apps are compiled and linked, I wasn't very optimistic.
It turns out I had naively over-estimated the intelligence/deviousness of most small corporate programmers. I remember that back when I was 11 or 12 (this was roughly a dozen years ago) I had one of these "1337 h4}{0r" friends (you know the kind). He told me in his infinte wisdom that most copy protections could be defeated simply by changing a single instruction to skip over the failure algorithm and go straight to the success algorithm instead. I thought, "surely programmers aren't still using the same decade-old methods that are so easily broken?" Surely they are. It took all of about 15 minutes to find the failure message ("That Which Shall Not Be Named has expired!"
and backtrack to where the conditional jump was. NOPed a couple bytes and all my troubles were over! What a peculiar feeling.Later I found a better solution. My first workaround told it to continue with normal program execution even if the program saw that it was unregistered (i.e. it never processed the "You have X remaining executions before blah, blah, blah" code). I improved it a little by just skipping over the portion of code where it checks to see if it was registered in the first place. Is I learn more, I'll go back and see if I can reverse their validation method, which is in a separate executable, and make a keygen from it. While I'm at it, I'll figure out how the program determines if it is registered or not, and what the validation program does to register the program when you give it a valid key.
Thusly inspired, I started poking around in an third-party .arx file for AutoCAD which had been giving me trouble for similar reasons. I won't go into the gory details, but suffice to say that .arx files are cute. They contain an indordinate amount of plaintext data in order to pass their function data to the LISP subsystem of AutoCAD. That makes them substantially easier to reverse than normal executables, and this time I was able to find what I was looking for in about 5 minutes. NOP NOP, bam. This could be addictive.
I'm not sure whether to be delighted or disgusted that I could apparently train a chimpanzee to "crack" a very large portion of commercial software. You'd think that people might learn something and put some new ideas to use once every few decades.Anyway, thanks for the invaluable mine of information around here. Two major annoyances in my life are now removed from the equation. When I get a little free time I think I'm going to pursue this as a more active hobby. I've got a few oddball programs and devices that I have always made me wonder what makes them tick.
... that was funny...