i am trying to crack windows commander 4.5.2 any tutorial that u can suggest for that ??? don't forget i am newbie ))

If I remember right, BlackB wrote a tut about it some time ago. Have a look at ht*p://beam.to/BlackB

If my memory serves me right it used to be packed with AsProtect... if this hasn't changed - you might need to read the new ReVirgin essais too.

thnx for the source ))))

Don't forget that Windows Command 4.5.2 has a load of CRC checks built into the code that are time and feature triggered. It'll make you think you've cracked the program and then a minute or so later it'll something along the lines of "The windows commander executable is damaged - possible Virus!" and exit. It can be a real bitch to find and eliminate all the checks.

The perfect way to register it would be to create a proper, working keygen that created the wincmd.key file, but no one seems to have managed this as yet.

You are right mate it has fucking CRCs and weirdly i cant unpack 4.5.2 as BLackB unpacks 4.5.1.....But Predator from Phrozen Crew managed to crack 4.5.2 too we may need him here to tell us )))

Yup, strange thing is, the cracked version that you just run the keygen on seems like it's still packed, but with the additional text at the end, maybe they unpacked it and hacked it with softice, and then patched onto the end of the loader, hence the text at the end of the exe once cracked?

i finally gave up cracking it i got this
005ae4f3 61 popad
and set a breakpoint on it with bpm 5ae4f3 but softice didnt break when i re-run commander...so i used predator's crack..it works fine..

Dude! Go sit in the corner Bad Boy!

Alright, when using the crack, try at least finding out what he patches!

Save the wincommander.exe under a different name.. run the crack.. and do a byte compare on the original & patched one.. This gives you the offset! Disassemble the original search for the offset and [try] at least finding out what he did!

The tutor is right in you EmailBox.
i've just Crked it under a direction of a Tutor(Not in English.)

its so lame copying other's works like that ....

Excuse me???

what do you think what following a tut is? Don't you copy step by step what someone did before you?

It is not lame at all using your brain finding out what a cracker did by running his patch, imo! I even say that chances are higher to learn something as he has to find out how the code flows by himself.

no i disagree wtih you..as soon as all you and me know crackers use SoftIce i mean live approach technique to crack..they scroll down the code to find the protection routine..that time u learn everything not by see differences in the patched file...

Argh... ok... I give up.


that's not true.. you can use TRW or the Wdasm Debugger... hehehe..
without kidding: A disassembled listing && knowledge of the API Guide is usually enough...


Where do you think he patched it? Wild guess: Maybe in the protection routine?

lame or not i check differences..guess what i see..more than 182 differences...i think that contains wincmd.key routine (proggie looks for that ) , protection routine , CRC routine and some routines to chande the title...lets mail predator to write a tutorial about it...what u say dudes?

Gentlemen,

It is not lame to learn from other peoples examples.

Wether it is a tut or looking at what somebody elses patch does.

What you need to do is learn why something was done.

If you use a tut it is explained for you.
If you look at what a patch does, you have fo figure it out for yourself.

The latter teaches you more, if you want to learn for real.

The only real way of learning techniques is to see them in action.

From there you can then look for a better way of carrying out the task in hand.

e.g.

I looked at r!scs technique for settlers 3 and used a similar technique for copylok loaders.

Is that lame ? You tell me !
But compiler & API attacks are valid techniques.

Right now I am going back to learning about ASProtect (yet again), due to recent changes.

I will use whatever valid info is out there, I may find a better way of doing things or possibly not.

But life is too short to trace every single line of byte of code, unless I have to.

The whole point is to;

Look for a weakness and exploit it, only if that fails, is it time to use brute force.

yeah seeing them in action is really good to be a real cracker..but as i mentioned in my msg there are too many differences in patched version..so i need to read more about ASpack as u....

Not aspack in my case but the tweaked version of asprotect (seems to be for the Russian market).

Theres some extra screwing about with the IAT

man check h**p://rotaderp.cjb.net/
asprotect tutorial really worth a look..hope that can help

Hi all

I thought there was some IAT screwing going on too first, as my dumps didn't work... but somehow there's no need for idata saving... [I found that out as I pasted my idata nicely into the prog but forgot to change the pointer to my new table *g*]

load icedump
dd 551000 (where idata is located - currently there are 00 or ??)
bpx GetProcAddress
F12 until you see the idata filled up
bc *
F12 (probably a xor eax,eax)
[(here i dumped idata)]
F12 (wait! it parses for the next p ret - next break is at start of prog)
SoftIce breaks at push ebp
[idata changed? I dumped again to find out differences and maybe patch it together]
dump wincommander
use PEEditor with the dumpfix option
change caracteristics for code section to E0000020

done. Working dump. Until the CRC check pops in

Kilby: Not aspack in my case but the tweaked version of asprotect
>Are there different versions of WinCommander around?

Oh.. well... sorry for keeping this short... hope this helps someone

Well, maybe i am a lamer though i get my own ideas, next time i'll work out the KeyFile check.

If you gain back, try using BPM 005ae4f3 X
instead. I read that in a another tutorial about aspack

For those of you actually interested in reversing this program, I recommend that you review "Windows Comannder 3.02" by iNCuBus++ of 6 August 1997 on Fravia's site. It contains a discussion of the protection scheme which, with different addresses, is consistent with that discussed in BlackB's essay on v4.51.
Of even more technical interest, because it discusses a timebomb CRC check which was not addressed by BlackB, is the article "A Study in Methology" by +Indian_Trail. It can be found at h**p://www.cyberspy.com/~thesandman/Windowscommander.htm. It is a review of v4.01 using only Win32Dasm 8.9 and FileMon. He also discusses the decription code for the nag and help screens, which is partially discussed by iNCuBus++ as well. A search for wc32v401.zip (or change the last 3 digits and find other versions) will find +Indian_Trail's copy of the program to study and compare with v4.52.
The attempt to reverse v4.52 is my first project on the PC and I have begun by unpacking several of the packed versions and finding whether the code routines in the later versions are the same, although at different addresses, for those protection routines discussed in the essays. These locations can be found by searching in a dissambler for the op codes and/or hex values of the op codes and much can be learned, including how software authors, as opposed to protection writers, are not quick to make significient changes over time in their code for the basic protections. There appears to be little significient change in these routines between version 3.02 and 4.52.

Paraphrasing the addage: Give someone a crack and they have a program. Teach them to crack and they have "food" for a lifetime. If you start with an essay, search for others on other versions of the software. It is more likely that the packer/protection will change than the basic author's protection system.

Predators asprotect tut helps for 1.1 files.

But 1.2 has changed the game again

I know what needs to be done but it's finding a way, WITHOUT tracing the whole damn thing by hand.

Maybe I'm missing something here, but by my observation Win Commander is packed with ASPack, and not ASProtect, and doesn't have the difficulties which I have read discussed with the ASProtect. For example, when the exe is unpacked and dumped, the IAT is not a problem and Revirgin was not required to make the program run from the dumped exe without changes. This was noted in the BlackB essay.

The "only" problems: Bypass the call to the key file, which BlackB and the others describe; Defeat the nag, which they all describe; Get your own name, etc. into the title of the main window, which +Indian_Trail and iNCuBuS++ describe; Defeat the two CRC checks, one immediate and one random, BlackB and iNCuBuS++ describe the first and +Indian_Trail the second; and, finally, find if there is still anything "new" keeping v4.52 from working like the "official" version.

+Indian_Trail's essay is particularly helpful because rather than giving the answers it provides a framework for understanding the protections and what code to look for which might be supporting them. For example if you are investigating a CRC issue you know that the code must be "read" by the routine that is processing the check and if it is to detect changes in the file, the "expected" result has to be in the file somewhere, anthough it could be encrypted. Studying the process by which +Indian_Trail located the code where this reading and checking had to occur led to his discovery of the routine which gave the final result for the first CRC check and the second and his discovery of the location of the "expected" result.

A wouldbe cracker, like me, can learn a great deal from these lessons, without spending hours tracing code of reading the disassembly from start to finish.

thnx for all your attention and answers on this topic..it helps me a lot..