The problem.
I have an application protected by what I thought was a rather primitive protection: It stores the state "registered" or "not registered" in a global bool variable. I changed the code that sets the variable so I am "registered". the modif works OK on a pentium 4 Windows XP professional OS.
I copied the altered file to a AMD 64 running Windows XP OS. The program complains "not regtistered" I debugged it in the new system: the altered code is still altered, but it is never run.
I traced a little bit, and the symptom is, in this different but very similar computer, the app code flow takes a different path that bypasses my modification. Of course I can fix the problem, but I am somewhat puzzled by this behavoir.

My questions to the public are why? and how?
The OS is the same, as far as I can tell: XP professional sp1 (Installed from from the same CD actually), the CPU is different but this should not be an issue for a ring3 running app, right?


Any suggestions on how I can figure out where or how the execution path diverges between the two machines?

It is out of curiosity, for the most part...

One random idea for a method:
Maybe you can set a breakpoint in your patched code in the first machine, and then write down the callstack when it breaks. In the second machine, set breakpoints on all levels of this callstack (shouldn't be too many to handle), and see at which level it stops breaking. The difference in execution flow most likely resorts in this function, and using manual tracing will most likely not be overly bothersome to find the final spot once you know this.

Let us know what it was when you find it anyway.

reminds me of bleem (the first crack released didn't quite work 100% for amd)

Someone please call M$ and report that "nobody" has installed their copy of M$ from "the same CD" on more than one machine. Oh the shame of it all.

Regards,

An API monitor might pick up the differences. If not, I know a more generic call function (as opposed to strictly API) monitor which might, but it hasn't been released yet..

Wow. Kayaker knows a secret. Now we'll have to kill him so he can't tell.

Regards,

Aah, no beta-testing for JMI then...
Trying to encourage development with a real world scenario, not play "I've got a secret and you don't nyaah"

Cheers

Uh? Is that there Beta testing anything like them there drug tests where you gots to pee in one of them there little bottles?? Or is it some other kind of dang test?

Regards,

Hi guys,

Been a while since I've had much time for RCE... but I have the tool that Kayaker is referring to... It is currently a very "alpha" version. Real life has gotten in the way of me finishing it up and releasing a beta, but I hope to do so now that I'll have a bit of time over the holidays My tool traces at the procedure level granularity and captures all calls realated to local functions, statically compiled library functions, and API funtions. It is similar to an API monitor, but generic in the sense that it can capture the entire call tree of an application. I know that you guys are all skilled reversers / programmers and the implementation for such a handy little tool like this isn't really that difficult if you don't want to wait for my release Mine is implemented as an IDA plugin. Basically, I just query the IDA database for all of the local function start addresses and then use a debugger to place breakpoints on them. When the debugee process starts running, my debugger gets called when one of the bpx's hit and I log the arguments from the stack (I combine this with IDA's static analysis of the stack frame to get argument sizes, names, and such). At this point I can also automatically trace the arguments on the stack for pointers to user defined strings and integer values. I'm sure you can think of lots of uses for this ability ranging from automated serial sniffing to vulnerability discovery. The API's are monitored using IAT hooking and all of this information is logged into a GUI interface. I hope to eventually port this to ring 0, but right now it is limited to ring 3 tracing. It is also incapable of handling obsfucation or dynamically generated code (SMC) since it relies upon the accuracy of IDA's static disassembly for the breakpoint list.

Cheers,
Clandestiny

Sounds really interesting and we look forward to your eventual release, as we have for all of your contributions to the craft.

Regards,

Clandestiny, are you kidding? I would kill for this sort of app. I've always wanted to do something like this but the amount of work scares me away. All right, I'll admit I am lazy.

Back to the original poster, AMD64 is a different beast when it comes to debugging etc. If you copied a native 32bit program onto it I can imagine why it behave differently. If you have a 64bit version of the same program and you alter some code I think it'll probably behave as you have expected.

You are right Homersux, 64 cpu shuld be different from pentium, or they are not worth the extra money you pay for them, but in this situation I am using the same 32 bit OS, the same 32 bit program and the action is taking place at ring3, application level, which, in theory, is several abstraction levels away from the cpu intrinsic operation perversities.
Formally, AMD 64 should emulate perfectly the win32 operation, but apparently it does not. If that were the case, not only cracks, but whole programs would have to be specifically coded/compiled/linked for this CPU strain in order to work!

Ok, we've all been waiting long enough now to hear the interesting solution for this naides, so I'd say it's about time you get to it and make use of the tips in this thread and then let us all know what it was.

There is not a smiley for blushed face, but it belongs here. . .

I certainly want to use the kind suggestions all of you guys have given me.
The problem is logistics. . .
The AMD64 belongs to my girlfriend and I have not been able to run the app side by side because we are in a fight, so the AMD64 computer and other resources are temporarily out of reach

As soon as I patch the situation, I will duly report back to the board.
OK?

That was the best excuse I've heard in a long time, good luck with the patching (good breakpoints for these kind of patches are often the APIs GiveFlowers or SubmitExcuse btw, but sometimes if you've got the balls, it may just be a simple matter of not responding to anything in the message queue until the remote peer calls SubmitExcuse themself).

Actually the API "SubmitExcuse" rarly is effective. Long experience has taught that generally the only effective API is "AbjectApology" and/or "Groveling." Sometimes the API "IAmACompleteIdiot" used in conjunction with "I'veBroughtYouAnExpensiveGift" get to the solution more quickly.

Regards,

naides, what's the nature of your crack? Does it have anything to do with stack manipulation?

I think all you guys are giving late advices. Prevention is better. Naides should have wrapped his girlfriend inside a try/catch situation before trying anything else.

Cheers
Peres

You guys are really geeks

Clandestiny

If I were a real geek, I'd make some comment and congratulation about your postcount just about to exceed 8 bits for your next post... Aw crap.

Anyway naides, you'd better secure that crack soon, and then pack it real good, before some other guy (or even a whole group!) keygens your target right in front of you. Aw crap again, I'm a dirty geek too...

dELTA:

We knew that about you already. But we still like you anyway.

Regards,