Topic: Hex Editing of Starfleet executables  (Read 185474 times)

0 Members and 1 Guest are viewing this topic.

Offline TarMinyatur

  • Lt.
  • *
  • Posts: 938
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #260 on: February 03, 2015, 05:36:08 pm »
With regard to EM, I thought one or more of the anti-pirate missions in original sfc has the hostile orion ships use em. Is that mission scripting? I guess it doesn't matter, because SFC volume I and SFC volume II: EAW/OP are probably too different from each other for code in one to be much help in the other.

Interesting. The mission script can place numerous restrictions on the behavior of objects in a battle. Maybe it can enable certain functions, such as EM. I don't know.

The SFC1 code appears to be entirely inside SFC2. There are many references to obsolete items. SFC2 was not written from scratch. EAW is more-or-less a large patch for SFC1, and OP is a medium patch to EAW. Things get moved around, but a lot of it is identical. (I'm not slighting the work of the Taldren crew. They buillt upon what they had -- I'd do the same.)

Offline Corbomite

  • Commander
  • *
  • Posts: 2939
Re: Hex Editing of Starfleet executables
« Reply #261 on: February 03, 2015, 09:12:14 pm »
In SFB you can fire any phaser as a lesser version if you choose (IIRC, I'll look it up later), but to fire more than once with the same phaser in the same turn as a lesser type was an Aegis function IIRC (again, I'll look it up later), and only fpr PD.

Offline Corbomite

  • Commander
  • *
  • Posts: 2939
Re: Hex Editing of Starfleet executables
« Reply #262 on: February 03, 2015, 10:10:58 pm »
I was right about downloading any phaser to a lesser phaser. I was wrong about Aegis; it only allows you to step fire weapons in a single impulse, not fire one weapon more than once per turn. Tar was right about X Phasers being able to fire two (or more) smaller shots in the same or subsequent impulses and I was right about it only being good for PD, but in SFB all phaser types become X-Phasers and can be OL, so yes an X PH-4 can fire as four normal or four OL Ph-3's or two normal or two OL Ph-1's. This is from the rules I have, which may not be the most current as they keep changing thier minds about X-Tech.

Offline JanB

  • Lt. Junior Grade
  • *
  • Posts: 103
Re: Hex Editing of Starfleet executables
« Reply #263 on: February 04, 2015, 06:57:54 am »
I finally found my old assembler text books.  From the looks of what I am seeing on this thread, Taldren used either a MASM or TASM 5.1 compiler.  This is based on four main scratch pad 16 bit registers (AX, BX, CX, DX) which is themselves broken up into two 8 bit registers (AX -->  AH {15 --> 8} and AL {7 --> 0}).  Colors are handled by the INT 10h, INT 16h, and INT 21h interrupts as apposed to INT 13h which handles common programming functions.  So looking for these interrupts should give you a clue as to where the colors are handled in the program.  Although IIRC, INT 21h was also used in old virus programming so I'm guessing you won't see any of that here.  I think I found some of the ASCII values in hexadecimal if you need them.  The book says that display memory is fixed in the first megabyte of the PC's memory which the book is saying is B800:0000 and that this information can be transferred using the MOV instruction.  Hope this helps.

Very interesting... What do you mean by the hexadecimal forms of the ASCII values, are they colors or the hexadecimal forms of the interrupts?

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #264 on: February 04, 2015, 02:58:39 pm »
I'm talking about ASCII values of symbols on the keyboard converted into hexadecimal.  I'm in town so I don't have them in front of me at the moment.  IIRC all interrupts are in hexadecimal, the most common is INT 13h.  My thinking is since the books said colors in Assembler are handled by INT 10h that finding that code would be as simple as doing a search for that interrupt.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #265 on: February 04, 2015, 04:19:46 pm »
Search for Int 10h and Int 16h in the program and we'll go from there.  I'm not eager to jump back into this since it's been 20 years now.  What little I remember is rusty.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #266 on: February 04, 2015, 06:33:11 pm »
When I say search for INT 10h, I mean just that.  Look for the instruction:  INT  10h

If you find it, look at the code just above it and try to find addresses where the offsets are loaded into one of the registers, probably the DX register.  It's possible I am sending you on a wild goose chase, but if the hex edit program you are using has a find function then it should only take a minute or two.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #267 on: February 04, 2015, 07:16:45 pm »
The pictures you attached aren't loading and I can't see them.  Can you copy/paste the code?

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #268 on: February 04, 2015, 08:47:39 pm »
From what I'm seeing those lines of code are printing lines of text onto the screen like "You'll need more than that".  Looks like a taunt to me.  Remember those canned taunts that you could send to an opponent.  That is what it looks like to me.

What I find disturbing is that I have seen both 16 bit registers (AX, BX, CX, and DX) and extended registers (EAX, EBX, ECX, EDX, EBP, ESI, EDI, and ESP).  Extended registers use double word or 32 bits in a register.  For instance, ECX which is regularly used as a counter register (or variable) will have a low byte (CL) of 0 through 7, high byte (CH) of 8 through 15 and a extended portion (ECX) of 16 through 31.  Just so we are on the same page, AX is usually used as a Accumulator register (or variable), BX is a Base register, CX is a Count register, and DX is a Data register.

Something else I'm seeing is that I'm seeing is that they defined some but not all of the keyboard keys (example:  db  2Eh ; .).  I would have done that once in the program and referred back to that part of the code as needed.  Just so we are on the same page ASCII values in hexadecimal are as follows:

01 thru 1A     =    Control-A thru Control-Z.
1B:    =    ESC key
20:    =    Space key
30 thru 39    =    Digits 0 thru 9
41 thru 5A    =    Upper case letters A thru Z
61 thru 7A    =    Lower case letters a thru z

The reason why I know this is that the programers were kind enough to put comments in the code for me to read.  When you are looking through the program and see a semicolon, anything after that is a comment that the processor ignores. 

For example:   ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

Obviously that is not code and is meant to be read by programmers and not the processor.  Things like that above are meant to keep things separated and make chunks of code easier to read.  Once the processor finds a ; the processor stops reading anything to the right of that line and goes to the next line.  One quick observation is that these guys sucked and commenting.  I didn't see one INT (13h or 10h) in the code you quoted.

Something else I noticed is the line "mov     eax, offset unknown_libname_1572".  What this does is move (MOV) the first part of a line (OFFSET) located at unknown_libname_1572 into the EAX register.  Why on earth would you name a variable something like that?  Also noticed this:  "Microsoft VisualC 2-8/net runtime".  So they used two different types of programming languages for this, it's not unheard of but back then they didn't always play nice.  But now that I think of it, I remember Erik Bethke stating that he "sold his soul to Microsoft".  Maybe that is what he is talking about.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #269 on: February 04, 2015, 10:03:18 pm »
Some more random thoughts as I read through that code...

From my text books in Assembler, program data is defined or declared in a data segment.  The data is introduced with the directive:   .DATA

The following directives are used to define the different data types;

DB  =  A single byte integer or character.
DW  =  A two-byte (word) integer.
DD  =  A four-byte (double word) number, which can be either an integer or floating point (real) number.
DF  =  A 6-byte (far word) pointer.
DQ  =  An 8-byte (quadword) integer or floating point number.
DT  =  A 10-byte number.  This is usually a floating point or packed decimal number.

For example:

.data:00857F90                 db  2Eh ; .

This assigns the variable 00857F90 with the value of 2Eh (where h equals hex).  Using ASCII code, 2Eh appears to equal a period.

I'm also seeing the commands PUSH and POP, these commands put data on (PUSH) and remove (POP) data to and from a stack.  However I don't see where the stack is being defined.  Example:

.STACK        100h          ; Allocate 256-byte stack

Also it looks like .CODE has been replaced with .TEXT .  I think what I'm going to do from here is start explaining each of the different instructions that I'm seeing here like the XOR instruction which means exclusive or.  Maybe then some of you can get a handle on what was coded.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #270 on: February 04, 2015, 11:52:57 pm »
In explaining the different instructions, I think I'm going to start with the J command.  To me this one is the most disturbing, a crude comparison would be the SOSUB or GOTO in BASIC programming.   This is probably one of the biggest reasons most programmers don't want to touch this code with a 10 foot pole.  I'm going to get some aspirin as this one is going to give me a serious head ache...

Anyway a J command is always followed by a condition such as JMP.  Where in this case J is followed by MP, this tells the processor to jump unconditionally to another spot in the program.  IIRC this program was built using a 16 bit operating system so JMP can only move the processor to a location that is -32,768 to +32,767 bytes from it's current location.  Again, kind of like a GOTO in BASIC.  So when I look at the code Adam provided above and I see a JMP  $+5, I'm confused to say the least because I don't know where $+5 points to.

JNZ  -  Where we again have the J command and NZ is the condition.  NZ means jump if not equal.  Usually followed by a CMP (compare) or TEST command.  Kind of like saying in BASIC:  IF A <> B then GOTO 30.  Crude comparison but you get the idea.

JZ  -   Where we again have the J command and Z is the condition.  Z means jump if equal to.  Or IF A = B then GOTO 30.

If anyone see's any other J commands that is not listed above then I'll provide the entire list but it's getting late so I'm going to stop here.

Offline TarMinyatur

  • Lt.
  • *
  • Posts: 938
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #271 on: February 05, 2015, 01:11:00 am »
Quote from: Captain Adam

.data:00857F90                 db  2Eh ; .
.data:00857F91                 db  3Fh ; ?
.data:00857F92                 db  41h ; A
.data:00857F93                 db  56h ; V
.data:00857F94                 db  74h ; t
.data:00857F95                 db  46h ; F
.data:00857F96                 db  78h ; x
.data:00857F97                 db  5Fh ; _
.data:00857F98                 db  50h ; P
.data:00857F99                 db  68h ; h
.data:00857F9A                 db  61h ; a
.data:00857F9B                 db  73h ; s
.data:00857F9C                 db  65h ; e
.data:00857F9D                 db  72h ; r
.data:00857F9E                 db  40h ; @
.data:00857F9F                 db  40h ; @
.data:00857FA0                 db    0
.data:00857FA1                 db    0
In IDA, press the "a" key at data:00857F90. It will put all those characters onto one line that is easy to read:  ".?AVtFx_Phaser@@",0

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #272 on: February 05, 2015, 01:45:28 am »
Yeah, I saw that after I posted.  I still think it's clumsy.
 

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #273 on: February 05, 2015, 01:39:13 pm »
As near as I can tell, but then again a lot of the subroutines that are called isn't listed on the example you provided.  With those JMP commands I'm not totally sure those chunks of code are related.  Again this is the first time I looked at Assembler code in 20 years.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #274 on: February 05, 2015, 04:41:27 pm »
That section of code you quoted frequently calls a subroutine "sub_5050E2".  Have you looked at the section of code around line ".text:005050E2" and see if the code is related?  My guess is that the programmer used the actual location part of the subroutine name.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #275 on: February 05, 2015, 08:28:26 pm »
There is something else we can try, look and compare both SFC II and SFC OP.  Look for code that is not the same, that should help narrow it down a bit.  Especially since we have the source code for SFC II.  If you see duplicate code in both programs then it's probably not what you're looking for.

Offline TarMinyatur

  • Lt.
  • *
  • Posts: 938
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #276 on: February 05, 2015, 08:34:47 pm »
That section of code you quoted frequently calls a subroutine "sub_5050E2".  Have you looked at the section of code around line ".text:005050E2" and see if the code is related?  My guess is that the programmer used the actual location part of the subroutine name.
The interactive disassembler, IDA, provides these names simply for convenience. Taldren didn't create a function named "sub_5050E2" or a floating-point variable named "flt_9669A0". (Those are hexadecimal addresses after the underscore.) The programmers used Microsoft Visual C++ to write the high-level language code. They then compiled that into assembly code which must use GOTO statements because it is a low-level language -- it doesn't understand the concept of a conditional loop. I highly doubt anyone at Taldren looked at Starfleet.exe with a disassembler.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #277 on: February 05, 2015, 09:48:51 pm »
That convenience by IDA may still lead us to where that pointer leads to.  Even in the 90''s we were told to stay away from JMP commands.  I find it odd that Microsoft couldn't create a transitional library for a conditional loop that didn't have a JMP statement.  Then again I've seen WinMe... but I degrees.  Point is that appears to be a fault on Taldren's end.  Why would Taldren announce the use of Microsoft Visual C in the middle of the program if it wasn't using two different programs?  Anyway thanks Tar for clearing some of that up.

Offline TarMinyatur

  • Lt.
  • *
  • Posts: 938
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #278 on: February 05, 2015, 11:07:56 pm »
Maybe part of the game was written with Visual C++ 5.0 or earlier and newer stuff (v6.0) had to identify itself.

In other matters, I tried giving the PPD a hold cost of -8 by changing its value from 02 to F8. When the PPD was fully charged, it gave the ship 8 more power to use (although this bonus power isn't shown on the bottom of the screen). This could make an interesting unconventional mod...

If you give a ship a weapon (or weapon mode) that does no damage and has a max range of zero, and change its hold cost to a negative number, the "weapon" acts as a fragile power pack. If the weapon is destroyed, it produces no power. And obviously it first has to be fully charged. The UL PPD, Proximity Photon, or Plasma-G could have this power pack function. I don't know how to do it with Disruptors, otherwise the Disr-IV would be a good choice.

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2986
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #279 on: February 06, 2015, 04:46:19 pm »
Not much going on with that Subroutine Adam.  The FLD and the FMUL statement are as follows...

The FLD instruction loads a 32 bit, 64 bit, or 80 bit floating point value onto the stack. The instruction converts 32 and 64 bit operand to an 80 bit extended precision value before pushing the value onto the floating point stack.  And the FMUL instructions multiply two floating point values.

So from the looks of it this subroutine is multiplying two numbers.  I don't know what the variables mean so I can't tell you much more than that.  Sorry Adam.