• Please review our updated Terms and Rules here

Disassembly/Debugging 16 Bit DOS programs?

U

uriahsky

Member
Joined
Jan 23, 2012
Messages
37
I am trying to bypass some hardware dongle protection on some electronic testing equipment made in 1990. The manufacture is long gone and I haven't been able to find any support for this item. The dongle seems to be dead.

I want to disassemble and debug some of the programs but I am having trouble finding programs that can do this. I tried IDA but it seems to not want to debug a 16bit EXE.
Does anyone have experience using a disassemble/debugging program on a 16bit DOS EXE file? It seems most newer programs like Ollydbg won't do 16Bit DOS programs. Can someone recommend a program/s that will work on a 16bit DOS program? That has a GUI on it?
Thanks
Russ
 
Nonsense. IDA debugs a 16 bit .EXE just fine. What version are you using?

I'm using IDA Pro 5.2.0 and have never upgraded (no point to it). The cool thing about IDA is that if it recognizes a 16-bit C program, it will even recognize library calls.
 
I guess I interpreted an error wrongly, and also this program is new to me. I did try IDA free, but it doesn't do debugging?? right? So I tried a newer version. The error was related to BochsDBG, and when I looked it up this was the result.

BOCHSDBG Plug-in does not support neither 16-bit MS-DOS/EXE nor 16bit code snippets.

Have you seen a good tutorial on IDA with DOS 16bit programs? Or anyone who can assist me with this?
Thanks
Russ
 
uriahsky said:
I guess I interpreted an error wrongly, and also this program is new to me. I did try IDA free, but it doesn't do debugging?? right? So I tried a newer version. The error was related to BochsDBG, and when I looked it up this was the result.
Click to expand...

You're correct--IDA is a disassembler/decompiler, something it does very well. The BOCHS debugger is a plugin, and doesn't AFAIK support 16-bit binaries.

BOCHS does have a native debugger/emulator for PC mode, but it's a bare PC environment--you have to load DOS along with your program. I think the same goes for the DOSBox debugger.

You may be best off using plain old DEBUG on real DOS--it works for me. If you want something fancier, you might want to get a copy of old Borland Turbo Debug.

The best debugger for 16-bit code was a product called SoftICE. I don't know where you can find the appropriate version, however. There were also In-Circuit Emulators (i.e. hardware devices) that are perhaps the ultimate solution, but again, it's been a lot of years...
 
I like to use Sourcer for 16-bit disassembly and SoftICE 2.8 for debugging. SoftICE is great with a dual-monitor setup (mono/VGA cards with SoftICE on the monochrome monitor). You will want a dedicated DOS computer for SoftICE, no emulators...

The dongle protection code is likely packed and/or encrypted so you will want to unpack it before trying to disassemble it. There are various "universal unpackers" which should be able to handle it.

You can find all these programs at exetools.com
 
The dongle I have is called SSI Activator and I have searched the net for info and there isn't very much out there on it, not like other dongles it seems. What seems strange to me is that there are no driver files or files that load directly related to the dongle. I think maybe the .EXE file must directly access the Lpt1 port. I did find a reference to a file called PORTS.DAT which holds some numbers in the EXE file that requires a dongle, but I haven't figured out when or how it access the parallel port. I have one advantage in that I have one program that needs the dongle and the exact same program that doesn't need the dongle. It was compiled to bypass the dongle. The main difference is block of code at the beginning of the program. I don't think it is going to be as simple as removing that block and I just don't know enough about it at this point. Anything I should look for in a program when it is trying to access the dongle?
Thanks
Russ
 
Dongle code was generally made harder to decrypt. The reason was that a dongle represented a recurring expense, which added to the unit cost of production of a product. So you'd see them on fairly expensive products, such as AutoCAD.

But yes, unless the program was written for an OS earlier than Windows NT, it'll probably access the printer port directly.
 
I am confused...if you have the exact same program with the dongle protection already removed then what is left to do?
 
There are maybe 10 or 15 different DOS programs on this tester. Some are simple things like turn power off and on but some are more complex like the ones that run the functional tests. There is a menu system but it just links to all of these individual DOS programs, but they are all separate programs. I have maybe five that were compiled to run without a dongle and I have both versions of those, the one that doesn't need a dongle and one that does. So I can compare those to see what was done, but there are maybe another five or more that require a dongle and those are the ones I really need to get working.

I have contacted maybe five or more people to see if they could help me with this, companies that do this kind of thing but none of them came through in the end so I am slowly leaning about this on my own. I will look into Softice and the other thing recommended here.
Thank you,
Russ
 
Just in case no one has explained how these dongles work, at some point, or multiple points, in the execution of the compiled code there is a call to verify the presence of the dongle. If it doesn't find it, the program exits or errors out.

What you need to do is find the function that is being called and modify it to always return a positive status.

This may sound obvious, but to the uninitiated a simple explanation like this might help a lot.
 
When I compared the two programs the one with the dongle requirement and the one without the difference was in the beginning of the code there is a few blocks of code that aren't there in the program the doesn't need the dongle. The thing that got me confused was there were so many sub routines that went all over the place I couldn't follow along to find anything obvious. It gets confusing when you can't quite tell what the code is doing and what the subroutines are doing. I guess I need to follow along with a debugger? That was what I figured and to study the code.
Russ
 
uriahsky said:
There are maybe 10 or 15 different DOS programs on this tester. Some are simple things like turn power off and on but some are more complex like the ones that run the functional tests. There is a menu system but it just links to all of these individual DOS programs, but they are all separate programs. I have maybe five that were compiled to run without a dongle and I have both versions of those, the one that doesn't need a dongle and one that does. So I can compare those to see what was done, but there are maybe another five or more that require a dongle and those are the ones I really need to get working.

I have contacted maybe five or more people to see if they could help me with this, companies that do this kind of thing but none of them came through in the end so I am slowly leaning about this on my own. I will look into Softice and the other thing recommended here.
Thank you,
Russ
Click to expand...

Ah I see...well if you get stuck I'd be glad to give it a try. Always up for a challenge :D
 
Bear in mind that self-modifying code isn't unusual in this type of thing, so you can do a static disassembly and the code will look nothing like that which actually executes. Those guys who wrote the dongle routines were pathological. (It sounds like fun).
 
You must log in or register to reply here.
Back
Top