Flag: Tornado!
Hurricane!
|
|
Topic created on: March 6, 2007 16:14 CST by yermak  .
Is there any existing work on statically profiling an executable's instructions to reveal possible serial routine or other interesting locations in code?
I've found that, once a serial routine is located, the instructions just have a different look to them than regular. I suspect there's something that can help locate these areas, but I don't want to duplicate work already done.
-yermak
You likely can build a quick IDC script or other static analysis tool to look for addresses of typical serial port locations.
Look for "int 14h", etc. Really depends on the operating system you are talking about. I live more in the world of embedded devices these days, but could envision simply looking for Xrefs in Windows code to the appropriate serial handling functions.
With all that said, I generally just do a binary search for the appropriate instructions around serial communications when needed - again, talking embedded, raw access situations.
|
|
yermark are you talking about serial port. or keygen routines, that is softwares protected by serials keys?
|
|
static analysis is an interesting topic, cracking is not. at least not here ;-)
|
I kinda liked cracking :)
I think what he means is, for example, when you scroll on a disassembly of a file infected by a virus, once you got to the viral part, you can generally feel that this piece of code is out of place.
Perhaps due to the fact that serial routines mostly contain logical/mathmatical operations all bunched together, without major flow, yermak's idea was to write something that will locate such areas.
I suspect that most programs today contain such batches of instruction, but I don't believe they all have to do with serial routines, as most apps have some sort of a math algorithm for processing whatever.
So, 'bpx GetDlgItemTextA' should do the work :)
|
Yeah I'm talking about serial key generation routines used in shareware/trial version of applications, not serial ports.
So again, just was thinking about writing something that recognizes a high density of instructions common to serial routines (add,sub,shr,shl, etc..) that does some scrambling of a username or something to produce a serial.
I ask because when keygen'ing, most of the time is spent locating the serial routine.. once you've done that, it's game over.
-yermak
|
|
I would say that quality cracking generally involves solid analysis and reversing.
|
Writing such a tool shouldn't be such a hard task. You can do one of the following:
1. Write a small static code analyzer that will get a pointer to the code section, and then use a length disassembler and simply go over the code and check for any opcodes you'd like. It can be also easy because intel uses 'generic' opcodes exactly for such instructions. (I recommend LDE32 by Z0mbie)
2. If the program was packed - write an API hook over known text API's (GetWindowText etc), and trace over the code using an exception handler.
3. IDC Script.
Again, I really don't know how helpful could this be, but the above should provide reasonable ways to get what you want.
Hope I helped,
Orr
|
There are plenty of other places to go find out information about cracking.
Please cross OpenRCE off the list of places you assume cracking is accepted to discuss.
|
Reverse engineering and cracking go hand in hand.. get off your horse. The problem is valid and a solution will be useful in a number of scenarios that are not cracking. So if you can only think about the problem set if the word 'cracking' is not used, then replace it with analysis whenever you read it.
> aeppert: There are plenty of other places to go find out information about cracking.
>
> Please cross OpenRCE off the list of places you assume cracking is accepted to discuss.
|
|
Sadly, I do not list my "research interests" as cracking. Thus, you are the one drawing fire for your own actions. Perhaps if you took your own advice, this situation would not have come about.
|
What a tool! It looks like there's research to be done that potentially benefits multiple areas.. are you saying that rce research that is applicable to cracking is bad and shouldn't be done? Get a clue! Oh, and way to contribute useful comments.
> aeppert: Sadly, I do not list my \"research interests\" as cracking. Thus, you are the one drawing fire for your own actions. Perhaps if you took your own advice, this situation would not have come about.
|
You say that "Reverse engineering and cracking go hand in hand" -- I would argue that cracking requires RE, but the inverse is certainly not true. There are plenty of people interested in RCE who have no interest in cracking or keygenning, and whose ideals are not compatible with such actions. As aeppert said, there are plenty of forums on the Internet devoted to cracking and other purely illegal acts. Please don't waste the time of "legitimate" reverse engineers on this site who use their abilities in positive ways.
If you are pursuing legitimate and legal keygenning or cracking exercises such as on crackmes.de, we apologize for assuming your intentions are illegal. Given your responses, I doubt that is the case. The RCE community as a whole is filled with shades of gray, but cracking rarely has legitimate goals...
|
That is true; however, statements such as "Yeah I'm talking about serial key generation routines used in shareware/trial version of applications" and "I ask because when keygen'ing, most of the time is spent locating the serial routine.. once you've done that, it's game over." make it pretty clear what the goal is.
Do what you wish, but I agree with aeppert that yermak should follow his own advice: replacing "cracking" with "analysis" would not have attracted the ire of those who do not wish to help others circumvent mechanisms intended to guarantee fair payment for fair services (i.e., paying the developer for their hard work).
If you don't think developers should be compensated for their work, use and contribute to open source equivalents instead. If there is no open source equivalent, write it yourself or pony up the $$ for the commercial or shareware software. There are a million ways to rationalize software piracy, but that doesn't make it right.
If you are just doing it to learn, so be it, but I would recommend having a less cavalier attitude when discussing acts that border on, or are, illegal. You are more likely to get the participation of a wider audience. ;) As others pointed out, the root problem and its solution apply to a much broader set of challenges than cracking shareware or commercial applications.
Kris: good ideas in your book. Hmm, maybe time to think about the second edition - the first edition is sitting on my bookshelf. :)
|
PSUJobu
personally, I respect all developers, any developer has a right to protect his soft and asks money for it (or shows ads), however, some of customers have ability to break protection due to avoid payment. they could be stopped by only two reasons: civilian law outside them and moral law inside. in many cases moral law doesn't work, cos many developers act themselves very aggressive and violate both moral and civil laws, cover their asses with good lawyers. it gives us _moral_ right to crack programs, however, if we don't want to find themselves in the jail, we must _not_ crack anything, or keep our profile low and keep silence. anyway, following orders isn't my way of life. so, I prefer to live in the countries where copyright acts don't work. however, I repeat, I respect all developers and their works. I like free soft and used to distribute my own products on free basic. do I crack soft? well, yes. but! I don't use it. I just crack protection mechanisms and erase soft form my HDD after that. I do it just for fan, not for profit. and I'd never cracked anything for money. ever. also, I'd never distributed cracks, serials, etc.
> good ideas in your book.
> Hmm, maybe time to think about the second edition
> the first edition is sitting on my bookshelf. :)
the book was totally rewritten, so you will get something absolute new.
if you're interesting, I can upload some extra chapters on my nezumi server (hope, my publisher doesn't kill me :-)
|
> if you\'re interesting, I can upload some extra chapters on my nezumi server (hope, my publisher doesn\'t kill me :-)
That's like asking an addict if he wants drugs. We'd be delighted to "review" more of the book for you.
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}