• Please review our updated Terms and Rules here

DOS .exe file header help

H

hargle

Veteran Member
Joined
Nov 30, 2007
Messages
1,397
Location
minneapolis, MN
ok, a little embarrassed to admit it, but throughout all the years I've been hacking away and programming in DOS, I've never actually studied the .exe file header information before, but I think I need to now.

I have what I believe is a very rare game "Pro Golf" by Mastertronic.
Unfortunately, it won't run at all.
Debugging through the game, it starts executing almost at the end of the 100k exe file, and starts executing 0's (data), which crash it.
I can tell there is actually executable code elsewhere in the file, like towards the top 1k of the file where I'd normally expect code to run.

It appears that the starting CS:IP of code execution comes from the .exe header, so I can blame the header for telling the game to start running bad code. If the .exe header is corrupt, is there any way to locate what the true starting CS:IP should have been?

here's the exe header in question
Code: 
Offset         0  1  2  3    4  5    6  7   8    9  A  B  C   D   E  F
00000000   4D 5A 33 01 C8 00 05 00  20 00 00 00 FF FF AB 14   MZ3 È       ÿÿ« 
00000010   90 01 0C FC 00 40 C4 14  1E 00 00 00 01 00 00 00   �  ü @Ä         
00000020   00 00 02 00 00 00 04 00  00 00 06 00 00 00 06 40                  @
00000030   C4 14 00 00 00 00 00 00  00 00 00 00 00 00 00 00   Ä

so it's not completely mangled, but I don't quite get why the CS:IP pointers there are shoving the starting address so far at the end of the file.

One theory I had was that this file had been infected with a virus before, which might alter the .exe file header and append its code at the end of the file. then at a later date the file was cleaned, but the .exe header was not restored, or the whole dang file is corrupt and I'm screwed.
the file itself is here: http://www.waste.org/~winkles/PROGOLF.ZIP

Getting this title resurrected would be quite a treat.
 
What version of California Pro Golf is it? Might be able to do a compare with a good exe file and find out where it's ganked.
 
Obviously you should reinfect the file. j/k While not always it certainly does sound virus like. That was the early and easy way to infect exe files (well or .com files really) plop your code on the end, tell it to jmp there then at the end jmp back to the original intended spot. If you load it up in a debugger are there any points later past the zeros that have a return or jmp back to somewhere useful? You might try changing the IP there but you'd be sorta shooting in the dark I think.
 
I looked at the file and looked at the code the CS:IP pointed at--just some data, not even executable. I wonder if the file is simply an overlay file and that the actual game execution is started with a different program. There is code at DS:120H that looks as if it might be anti-tampering code, so that my be an entry point.
 
patscc said:
Have you tried running exehdr to see if the checksum comes out right ? At the moment I can't get at a system that has it.
patscc
Click to expand...
i've not. the first version of exehdr I can find is an OS/2 app.

wait, here's the output from a different one, but it does not appear to be validating the checksum.

EXE header viewer Version 01.00b
Forever Young Software(r) (C)opyright 1984-2001

File Information (in Hex)
Header size: 0020
Code size: 00018D33
Min Load size: 00018D33
Min allocation (para): 0000
Max allocation (para): FFFF
Initial CS:IP: 14C4:4000
Initial SS:SP: 14AB:0190
Relocation count: 0005
Relo table start: 001E
EXE file checksum: FC0C
Overlay number: 0000

I can't seem to find a tool that validates the checksum on an .exe though. I don't think that will tell us much though.
 
Well, it would quickly tell us if the file was corrupt, but of course if no one can lay their hands on the utlity...
It doesn't look like there's a whole lot of code in there, mostly text and graphics.
Chuck(G), if it was an overlay, wouldn't the overlay number field be populated, or is that one of those things you can't count on ?
patscc
 
that's why I don't think we can count on the checksum either. There's nothing that is actually verifying it to make sure that it's correct before a program executes. I've hacked up many a .exe file without ever changing the checksum field and the programs still run. Or is the checksum just a checksum of the header?
 
Not that I know what this means but exehdr from masm5.1 comes back with this

Magic number: 5a4d
Bytes on last page: 0133
Pages in file: 00c8
Relocations: 0005
Paragraphs in header: 0020
Extra paragraphs needed: 0000
Extra paragraphs wanted: ffff
Initial stack location: 14ab:0190
Word checksum: fc0c
Entry point: 14c4:4000
Relocation table address: 001e
Memory needed: 100K



patscc said:
Well, it would quickly tell us if the file was corrupt, but of course if no one can lay their hands on the utlity...
It doesn't look like there's a whole lot of code in there, mostly text and graphics.
Chuck(G), if it was an overlay, wouldn't the overlay number field be populated, or is that one of those things you can't count on ?
patscc
Click to expand...
 
That's just the header stuffed into a struc. I think you need to run it with a switch for it to actually calculate( or verify ) the checksum, but I sure as heck can't remember what it is.
patscc
 
no other files that I'm aware of (this was scraped off an old 286 machine that I obtained a few years ago), but having an original copy would most certainly do the trick.
thanks for the link! case closed.
 
You must log in or register to reply here.
Back
Top