sorry to bother

[jaejuan]

hey too all..
iv just started out so very new to all of this.
recently downloaded free demo poser9 but after installing you need to pay befor you can even use the demo.
or should i say need credit card details which i do not want to hand over.lol
mow im trying to bypass registration using olly hex workshop an w32d but cant seem too get through..
iv set break points on all api an get accsess violation and tried making jumps threw reg but get errors hah any help would be appricated an sorry still not familer with lingo.

[Cool_Fire]

I find the easiest way is to load your program into something that reverses it into a flow chart of assembly functions. (IDA Pro can be very helpful here.)

Than it's "just" a matter of finding the message that tells you your activation code is wrong and seeing where that branches off from where you enter your activation. 99% of the time, this junction is where you'll need to patch/modify code.

[jaejuan]

thank you for your reply..

um i used olldbg to find error activation message an tyied patching but seems not to work hahah
used hexWorkshop to change values from start of activation jmp an changed value from 74 to EB an 90 an just goes to programe needs to close error.
i dont know wot im doing wrong,n i think its wrong for smith micro to say trial is free 30 day an you gota enter credit info just to activate..force consumer to buy,i think thats wrong.

[jaejuan]

maybe i need to try starting off ona exe thats a bit eaiser hahaha till i learn

[dimcode]

Are you sure the line you edited was the activation jump ? Also, I know the goal here is to reverse engineer the application and perhaps I shouldn't say this, but torrents.eu might be a website you want to search for the program with :p

[jaejuan]

well i have fonud the activation error but there are two of them and jump both but get program error.have found the reg key / name i have typed in with olly but cant seem to find where it checking with tru reg key ..and not to sure with torrents lol had run ins with over the past hahaha mite get the flu haha.well thank you for help ill keep trying..

[psilocybin]

I resisted answering this question at first because I usually find that when I try to help people with cracking I end up being a bit long-winded and never getting a reply, so I don't know whether I've really helped anyone at all. Bear in mind that my answer will be long because of the nature of cracking/reverse engineering, because it is an involved process that I am attempting to describe. with cracking you have to constantly think about how a program works, and it really helps if you're a programmer or have experience cracking, and try different approaches based on that. the moment you reach the ends of your knowledge and creativity is when you stop having ideas for what approaches to take, in which case you need to learn more (by studying the program or programming in general) or think about it more. there is no set procedure, although there are procedures that often yield results. I'll state some of them here, but remember that none or all of these methods may work. to get better at cracking you need to practice, practice, practice (and read programming and cracking tutorials)... and I'm very aware of the catch 22 here, it sucked for me starting out too.

since you have found where the key you inputted is stored in memory (or at least one copy of it), have you tried placing a memory access breakpoint on that memory address? that will tell you when the program loads or compares the memory directly to something else. if you know that you have found the original copy, then tracing the transfer of the key in memory should eventually lead you to the final comparison/check. if it isn't the original copy then you should try to find it... if you're lucky then placing a memory write breakpoint on the address you found might work, but you will probably have to find the API the program uses to read the registration you entered from the text box, and begin tracing execution from there to determine where the comparison happens. I don't remember the APIs off the top of my head, if you're interested I'll hunt my references down for you and post them.

alternatively to all that, you could try the approach that you're using, just extended. you've found where the message box (or whatever the program uses to inform you that your key is horseshit) is called by the program, so *probably* at some earlier branch in its current execution it made the determination, and then set a flag or variable that it's looking at for the false validation message. so you need to trace back through the program to find where the actual comparison is made. you could try a memory write breakpoint on that flag/variable to find where it is written, and try correcting the jump that makes that determination there (or if there's another comparison then just apply the same procedure again).

OR you could try tracing the execution back by either tracing through the call stack or by placing breakpoints at the return(s) of each function and letting the program go until the breakpoint trips, then stepping until you are out of the function. the call stack is usually faster, but you have to know what you're looking at. either way, at each function you find you should look at what's being passed (pushed to the stack) to the function, and what it returns (usually what is in the EAX register after it has executed), and most importantly what is done with the return value immediately after. you can usually judge when the key comparison is done (in what function) by those parameters.

this all assumes that your program isn't hardened against cracking (it probably isn't).

well thank you for help ill keep trying..

this is the most important part you have to keep trying things, and learning things about the program, until you have it. expect it to take a very long time.