Hi,
I'm trying to learn with a very Old DOS programa that has a FLOPPY Protection, But it's amazing if I load the code in SICE I got the code with instructions that cahanges once that I star tu run the program, so if I change any change in the file on the HD next time when I load and run again the program the change it's not there, Looks like a Dummy Code or Hiden Code somewhere..
somebody with any clue?
Thanks
Bluetongue

A DOS program would be 16 bit code. When you run it in a Win32 OS, chances are the program is played in a Virtual machine. This issue may complicate debugging and cracking somewhat.

Old FLOPPY protections made heavy use of BIOS interrupt 13h. Learn about it and that may help you close on the protection routines.

Can you explain on different words or an example of the actual code what you say about the code changing? what you say is not clear.

Thanks for your reply. But to get less problems with the debugging I install the Old DOS6.22 and I Install all the staff for DOS, the first thing that I read it was about the INT 13, but the thing is:
1) IF I Load the Program with S-ICE LDR and I start to dive into the code, comes with a lot of Instructions very strange so I started with BINT 13 so in that way I debuged the program and I printed out a lot of the code, but when I compare the code after my First Stop in the Break point with the code as soon I load with the LDR are totally diferent, looks like the program changes the code but itself. The only thing that I distinguish is a lot of Changing Vectors...
Do you think that I'm talking a lot of crap or it has some sense.?
Thanks
Blutongue

Perhaps this...

1. Trying to "debug" DOS applications (specially with protections based on Floppy/CD) is a nightmare under any system that is basically "NT" based. This means NT4, NT5, XP, ME and win2k and win2k3. It might be better to use a disassembler in this case. Try Sourcerer (better than IDA cos it ennumerates the Interrupts at the end and gives one shot call/callee for all calls that the program makes)

2. If you really want to "debug" only, you'll have to install Win98 or its variants. You can try a virtual machine manager such as Bochs or VMWare, but ice behave funnily with them. Your best bet is a fresh installation of Win98.

3. You also need Softice for DOS rather than softice for windows. Boot your PC in the DOS mode rather than running DOS after windows has started, will give you better results and remove the noise.

4. Try using the CE:EIP NOT <addr> command to filter out additional noise when breakpointing.

5. Try to understand low level floppy accesses. My hunch is that the int13 is not going to be used at all, but other interrupts. A text searchable format of Ralf Brown's may be useful.

6. You may also try to low-level copy all sectors from the floppy disk using good old debug.exe (as found in ORC tuts) and compare them to the changed ones once the program has run. SImply breakpoint over there and it should lead you to the routine that sets off the protection routine. You can take it from there.

Have Phun

Thanks for your reply,
I'm agree with you about to try to debug a DOS program in Windows, so that's what I installed DOS 6.22 in my old 486, so I'm with the native OS for that program, I found all the instructions where the program makes a read for a especific sector in the floppy, the problem is that when I want to make the changes into the file, the next time that I load the program the code looks without the change, I doble checked with an HEX editor and the change it's in the file, but this is funny, If I load the Program with s-ice LDR option and I have a look to one of the instructions, this instructions changes as soon I start to run de program.
Funny Isn't it?
Thanks
Bluetongue

1. You may be dealing with Self Modifying Code over here. You may need to go to google and find out some basics about the SMC.

2. Your program may be storing its pristine instructions in either data/rsrc section, subsequently upon running some check (CRC, Checksum, etc) it may be overwriting the code portion of the file in memory with the correct instructions.

3. Some associated files may be recreating the entire program if they find that the same has been alterd (CRC, Checksume, etc)

4. Though softice detection for DOS programs was funnyily easy, it could still hold the answer to why the code is being modified in memory

5. Just ensure that the program does not keep backup copies of itself,which it restores on-the-fly.

6. If none of the above works, its time to get dirty: You can effectively do this:

a. Modify the file on the HDD/Floppy
b. You know the bytes you have modified. Put int 03 instructions for the beginning of the patch. Ask softice to break on int 03
c. Load the program in memory
d. See the breask
e. Find what breaks it. Use memory map to find out the process hitting the file.
f. You can find what it is that is actually modifying the file.

Have Phun

Yes, what you just said it has more sense, I didn't know that some programs can be selfmodified in DOS, and I,m 100% sure that that'w whta happens, but there is no hiden files, Looks like at the end of the file there is a pice of data that the program reads itself.
Got any Idea how can I manage this?

Bluetongue

Basically this points out beginners to SMC.

http://www.eccentrix.com/members/mammon/Text/smc_apj.txt

Have Phun
PS: you may have to search virus sites on polymorphic code (samples can be searched specifically where the payload/code is in the data/rsrc sections)

let me know how it goes.

Hi

I may be wrong here but I have not played with DOS for about 10 years or more

Something in the deeper part of my single cell brain is telling me that some progs where you had an installation disk ( for copyright) marked a few sectors as BAD, then when it ran it removed the tag and the data it required was in those blocks marked as BAD. Like I said I may be wrong but it is years ago now

/hobferret

Didn't DOS Softice have memory access breakpoints? In that case, simply stop the program at the entry point, and put a memory write breakpoint at your patched instruction, then run. Now you should easily be able to see the code that modifies the patched location, and be able to backtrack from there, disabling the modification code or patching any possible CRC code that triggers it.

Howdy,

I am unclear about some things.

The box is an old 486 with DOS and SI for DOS- No windows ?
Are you working from a copy of the original floppy or are you trying to modify the program on the floppy ?

Woodmann

Looks like the original flopy it has a bad sector, Now I can Install te programa into C: drive but when I try to run the program It'comes with the error "COP'S COPYLOCK II BAD COPY" thats why I want to Crack it, if I try another disk the Program asks forever fgor the original disk, I founf with S-ICE the instruction, but Im new with this, and I cant find the instruction in the exe File coz it changes on the fly as soon you execute the program.
Thanks for the help
Bluetongue

I forgot, my Box it's 486 with DOS 6.22 Loaded on it and S-Ice for DOS, I'm trying to reproduce all the original enviroment.

I found this, can somebody explain it to me??

Cop's CopyLock II Standard for DOS
For the copy protection of DOS .EXE and .COM files. Files are locked to key diskettes. The key diskette is required each time the program is loaded, or once for each reboot. No special diskettes, hardware or code changes are required. All DOS diskette formats are supported. Unlimited number of protections. Highest diskette and code security. The protected files are encrypted and furnished with state-of-the-art debug-trapping. On the market since 1984

Howdy,

I think that protection was to prevent the copying of the floppies
to the hard drive without the proper key. It is probably the same
for the installation.
It is not self modifying code, you need to stop the routine from looking for the key. This may be the reason why you cant make any changes. No key=no change. I think this may be an easy NOP job.

That is some old protection

Do some Google work and see what you can find.

Woodmann

But Just one question.
It says that The protected files are encrypted and furnished with state-of-the-art debug-trapping. Can you please tell me whats all this about? Just one thing it's clear to me, The code that I'm debbuging it's not the same that the one in the exe file.
I know this could be very easy for you, bot I just started with al this two weeks ago...
Thanks
Bluetongue

Howdy,

Well, the problem is what WAS state of the art back then ?. It is difficult to recall things that are so old. I cant even remember what I had for lunch
yesterday

Encrypted....maybe. Anti-debug....maybe.

The anti-debug means it can detect SI or others and shut itself down.
This usually occurs instantly when you try to debug.
Since you can get it somewhat loaded means that the new tools are not recognized.

Have you tried to look at it in a hex viewer ?
I only ask because this is old and maybe you are trying new technologies that maybe dont return the results you desire.

Woodmann

I love the old shit

Well I'm new in all this and all the documents that I found are more related to SI, but all this tools are for DOS too I tried to found all the tools for that age. One of the things that I notice is that some disassemblers says that the file it's splited and even with SI if I type map looks like my program it's in two segments of the memory
Thanks

Howdy,

I found this little tid-bit today:



Woodmann

Hi Mr Woodman,
That methot to duplicate the Disk it's very interesting, but the problem it's that I got the original Disk, and now the disk It's saying tha the copy it's a BAD COPY, this it's a different message that the one that you get with a non original disk, itn that case the program just asks for the original disk forever.
I found some information regarding this scheme, and I found a utility to remove it, but sisnce this software it was developet in 1998 I think that I need a very old computer tu run it.
Looks like I chose a very complicate target to learn about all this, but It's exicting anyway.
Look the attachment. I found this information that explains how the security patch it woprks, may be you can tell me how can I get rid off the pice of crap.
Thanks
Bluetongue

hi all,

the protection you talk, Cop's CopyLock, is very easy to remove, forget about copying the disk exactly, it's much more easier to crack the app,

i've been doing research in old disk-copy protections for some moths ago, i am writing a very extense and technical paper about all these protections for my university degree, just for historic notes

i posted in this forum asking for help about disassembling and reversing the very old and very famous copywrite program, but all i got was my message been deleted, still wanting to know why

copywrite program stills has the most hardest and difficult dos shell crypter i've ever seen, and it's soooooo old (first protected version from 1984 !!!) forget about old protect, FFSE, SDW386, etc hehe, this is really weird

if you want to copy the disk, just ask, i have a very extense collection of old copy-protected disks collection (i have for example 24 versions of CopyIIPC and 13 versions of Copywrite)

best regards and good luck,
anormal
ps. you can p.m. if you want

anormal, is this paper of yours available online somewhere? Would you be willing to upload it here otherwise? It would be very interesting to read!

[OFF TOPIC]



this is off-topic here, take in account that i am only doing this study for documentantion and historic research, and of course i'll make it public, in this and other related forums, have you seen hxxp://www.caps-pr0ject.0rg/ ?

by now, i am studing (reversing) very old dos copiers, i have a nice collection, i plan to finish this job in a pair of months of so, if you want or need something just ask, if you know anyone that could help me with copywrite shell just let me know!

thanks!
[/OFF TOPIC]

best regards!

Hi Anormal,
Yes Im very interesting in get some clues in how this protection it works,I found just one tool that says that can remove the whole protection and uncrypt the program, but it doesn't work, all I know right know is that the propgram has been encrypted with a pice of the security code.
If you can ilustrate to me I'll be more tha happy.
Regards
Bluetongue

just private message me, or post more info about your app,
my other experiencies with this protec. is that is easily patched

regards!

Maybe you can try DosBox with a debug build, there's a debugger in it (though it's not softice ).
I don't have SoftICE for DOS so I can't tell if you can virtualize your PC by launching SoftICE and your app in DosBox but if it works, you have a DOS sand box (no reboots) and the possibility to tweak the VM source to do impossible stuff which can be very useful (setting bp on some hardware stuff and interrupts and so on)