Log in

View Full Version : about a nag dos crack


robertyonghu
November 9th, 2001, 21:04
I am cracking a dos exe program. Unfortunately, It is not a single program but a serials programs. The first programs will read the input file(i.e file.ccf),and use system to call the second and third programs to do the job. Maybe in the third program it test whether you are a valid user. How can I trace from the first program into the second program and so on?

Unregistered
November 9th, 2001, 22:28
hmmm, hard to say at first. But I would start w/the TSR's(Terminal Stay Resident) and go from there. Then check w/the PSP's, (Program Segmented Prefix) this way the info gathered in the beginning of the first program is carried over and over using the PSP's. I do belive you can use Softice or your fav debugger to trace how the program 'calls' one another.

PSP's are those undocumented areas of DOS that was never really understood, so be careful...

Aimless
November 10th, 2001, 03:24
Take a single .exe file. Split it into 3 parts. To run the .exe therefore, you need all the three parts. If one of the parts is missing, then obviously it will not run.

This is the principle behind a series of programs required to run the same. In this circumstances, do not try wasting your time figuring out where the proggie snaps. Instead, load softice (perhaps for DOS, if necessary. You will find may sites hosting the still used DOS version of ICE), log all the necessary calls (do your mapv86 first to get the ranges) and then subsequently try and figure out in which proggie it snaps. Kind of like attacking the protection from the behind. The simple approach does not work here as this is DOS and memory can be written anywhere (unless you are running it from a command window and not PURE dos), lotsa self-modifying code availablity, polymorphizm available and so on. Sourcer 7 or 8 can be used to disassemble the necessary. IDA is good, but Sourcer's summary of the INTS at the end makes it make me use that more for DOS cracking.

Also, if these programs are interlinked, you need not do the tracing manually. Softice will do it for you. At the beginning just note the limits of each program in memory (use mapv86 command) and keep a close eye on the segments (not the offsets) and when they change, you will know you are now in another program.

And yes, make sure you have downloaded and have ready Ralf Brown;s interrupt list.

...Have Phun

DakienDX
November 10th, 2001, 04:48
Please only post in one forum at the same time
(I've just seen that this post is discussed here, but I've already replied in the RCE General, so here's my reply)



Hello robertyonghu !

Do you know if them program only reads file.ccf in the first program?

If it does then the programs must exchange then registration data somehow. This can be done by commandline passed to INT 21/4B00 and at PSP:0081 in the called program, by using the inter-program-communication-area at 0040:00F0 (size 16 bytes) or by hooking one interrupt and calling it from the 'child'-process.

If you don't find the critical point that way, you should search for the 'bad-boy' message in the loaded program, which checks the user-info, and set a breakpoint on RW to this location.

If you're lucky, the program is in C++ and you land in the program at once, else you've to trace until you reach the end of the interrupt handler. (either 10h or 21h)

Now you should look for the condition when the 'bad-boy'-message pops up. (maybe by searching for some data of the file.ccf in memory)

NikDH
November 10th, 2001, 07:08
Quote:
Originally posted by DakienDX
Please only post in one forum at the same time
(I've just seen that this post is discussed here, but I've already replied in the RCE General, so here's my reply)


If you don't find the critical point that way, you should search for the 'bad-boy' message in the loaded program, which checks the user-info, and set a breakpoint on RW to this location.

If you're lucky, the program is in C++ and you land in the program at once, else you've to trace until you reach the end of the interrupt handler. (either 10h or 21h)

Now you should look for the condition when the 'bad-boy'-message pops up. (maybe by searching for some data of the file.ccf in memory)


Hi to all,
well i'm not very expert about dos cracking but what about looking 4 some functions used to show writings on the screen just as printf() that r statically linked into the exe ?

If the prog is in c++ its probable it uses the printf() to show the bad-boy nag on the screen and that function is recognized easily by ida in the lorg, u can put a bpx on it and w8 4 the program to call it and so look what kinda msg its showing

See ya
NikDH

robertyonghu
November 10th, 2001, 08:20
I have try to use the soft-ice to trace,but unfortunately it can't work with my program. The program use extended memory.It says extended memory is controled by another memory and exit.
Later I load soft-ice with parameter /emm 13192 (allocate some extended memory ). At this time it do not say the extended memory is controled by another program but can't work correctely. I use tr to load the first program but it can't trace into the second program.

DakienDX
November 10th, 2001, 08:32
Hello robertyonghu !

Are you using SoftICE for DOS?

If yes, you have to load it in your CONFIG.SYS (Device=[path]\S-ICE.EXE) and you mustn't use HIMEM, EMM386 or QEMM.

If you trace, you can't get to the next program. It should be possible, but there is so much DOS and BIOS code in these call that you will make some mistakes tracing and lock up your computer or simply run the program without stopping at the entrypoint.

Anyway, setting breakpoints is more comfortable and much easier.

If you're using SoftICE for Win9X or WinNT there shouldn't be this kind of problems.

robertyonghu
November 10th, 2001, 11:34
Yes I am use the softice for dos,because This program can't run in windows(it was written by fortran language,maybe some old verson). When it is run in windows,windows automatic restart to pure dos.
I have managed to let it compatible to softice now. And I am painfully trace in them. Yes I have lost my way in the bios and dos code. When I enconter the dos and bios interrupter, I usually can't intercept the program. Some interrupter can't be trace in and when you step over it you can't get back.
This is my first dos crack and I never used fortran. Are Fortran language special?