Increasing the trek.exe Palette Limit project

[Flocke]

the only interesting thing I saw in mpr565.dll was;

Code: Select all

.rdata:10297194 word_10297194   dw 7Fh                  ; DATA XREF: engMessage:loc_10015ED6r

Code: Select all

10015ED6 D9 2D 94 71 29 10                               fldcw   ds:word_10297194

it is loading a float value for the default case of engMessage
whatever it is for, it is very unlikely it is related to the palette count

184 palettes in game with just 1 byte changed
mpr565.dll
0x0017a0e 80 -> FF

This one looks very promising indeed!
It is a for loop that searches for the first empty value (zero) up to the limit of 80h-1 esi increments (esi is initialized to 1).
Then it allocates some buffer.

It even allocates the buffer when no empty slot was found and continues to process both the buffer AND the index.
When the limit is increased, the index very well might go out of range of some index table, like the palette handle buffer. And if getting out of range, you have a buffer overflow where it's overwriting whatever data follows, which can lead to crashes or other strange behaviour.

now it crashes at 53115C via windows event viewer.

from your post, it crashes right before accessing some buffer and then calling "get_texture_list_entry"

Code: Select all

0053115A           mov   esi, [ebx+8]
0053115D           call  get_texture_list_entry_24h_??

this very well could be caused by messing the texture list when your palette list index gets out of range

when I look at GlobalPaletteHandle some text is not displaying as ascII
if you look at highlighted line 0AF61928 the ascII should be vr8_
so when it trys to load defiant crash
why it is doing this I have no idea
vr8.jpg

only a guess, but while debugging IDA might have detected that the value got read from some other location and adjusted the data type
you might set a data break point next time to find where it's being read

the data type is listed as 'dd' though

[thunderchero]

184 palettes in game with just 1 byte changed
mpr565.dll
0x0017a0e 80 -> FF

This one looks very promising indeed!
It is a for loop that searches for the first empty value (zero) up to the limit of 80h-1 esi increments (esi is initialized to 1).
Then it allocates some buffer.

if lowered to 01, no crash but look at what we get

01.jpg (233.7 KiB) Viewed 886 times

I bet if I debugged GlobalPaletteHandle would only have 2 entries 0 and 01
so my guess this image was using last entry of GlobalPaletteHandle for palette
If I took the time to debug I could figure out what palette it used


right now not even sure what to be looking for or if there was any thing I missed I should try now.

[Flocke]

@ Flocke can you check whether these values are buffer size values or just other stuff like flags.

One is used for MPR+ context buffer:

Beginning with dword_58AB20 you see twelve times the value 20100h = 131,328 dec for array_store and delete_free memory.

This is suspicious close to the max palette limit 131,072 and used for our codes in question.

Watching the IDA code I can't tell much about it. I only saw offset references for deallocation, but not where the value actually is used.
Debugging it and setting some data break points might bring some light.

I however checked Falcon code again for the limits. In flyer\Texture TERRTEX.H you find a TextureDB, which has a 256 entry limited palette array. Maybe in some earlier version it was limited to the half of it.
The textures there however are limited to a 256 entries array as well, so textures would have been limited to 128 just as welll..

furthermore, that file is about terrain textures...

edit: oh, on a note, in Define.h there is:

Code: Select all

#define	TEXTURE_USE_PALETTE_MODE			0x80

so 80h is also used to enable palette usage It comes along with definitions for the image types and so is used as a flag.

[Spocks-cuddly-tribble]

[EDIT] I start to see the pattern, but you guys are not going to like it.

The entire MPR565.dll is hardcoded for a max limit of 128 (-1?) palettes. And I mean HARD-coded.

Code: Select all

1001860C                 cmp     esi, 80h      // 0x17A0E -> for malloc and data stack (by thunderchero)

To prevent a crash when returning to BotF all data for free functions has to be changed: +(0x418 * new extra palettes limit)

Some of them:

10015E77                 test    byte ptr [eax+20C50h], 4

100160EA                 test    byte ptr [edx+20C50h], 4

10017E25                 mov     edx, [eax+20C34h]

10017EAA                 test    byte ptr [ecx+20C50h], 8

---

10018732                 mov     al, [ebp+20C74h]

10018788                 mov     eax, [esi+20C34h]

10018795                 mov     dword ptr [esi+20C34h], 0
1001879F                 mov     edx, [esi+20C38h]

100187B6                 mov     edx, [ecx+20C38h]

100187E5                 cmp     esi, 20C00h     ; 0x418 * 0x80 default

---

10018818                 mov     eax, [ecx+20C34h]

10018840                 mov     ax, [ecx+20C74h]

1001888F                 test    byte ptr [ecx+20C74h], 8

10018979                 mov     [edx+20C3Ch], ecx

10018989                 mov     ecx, [eax+20C38h]
1001898F                 mov     [eax+20C38h], ebx

1001899E                 mov     eax, [ecx+424ECh]

100189B7                 test    byte ptr [ecx+20C74h], 2

10018A07                 test    byte ptr [eax+20C74h], 8

10018A1C                 mov     eax, [edx+20C3Ch]

10018A68                 mov     esi, [eax+20C3Ch]

10018A92                 mov     ecx, [eax+424ECh]

10018AE8                 mov     esi, [ecx+20C3Ch]

---

100188A4                 mov     ecx, 7Fh      // 0x17CA5 ?

100188FC                 cmp     ebp, 80h      // 0x17CFE ?
dword_10298790  dd 7Fh                         // 0x1AD90 ?

---

it crashes right before accessing some buffer and then calling "get_texture_list_entry"

Code: Select all

53115D           call  get_texture_list_entry_24h_??

Be careful. The ?? indicates its just a guess. A wrong one in this case.

Dynamic_5CD5B8__24h_36dec_total is related data but no loaded texture.lst entry.

603E94 is GlobalTextureList_48h_72_dec_entries

so 80h is also used to enable palette usage It comes along with definitions for the image types and so is used as a flag.

Yes:

80h -> just a flag for the texture type: 80h = PALETTE, 40h = ALPHA, 20h = CHROMAKEY, 1 = MIPMAP, 0 = DEFAULT

EDIT:

sub_557D90 texture_GIF_palette -> sub_5574B0 has some funny code:

Code: Select all

005574BE           movsx edx, byte ptr [edx]   -> positive range limit 0-127 else negative -> movzx for positive range 0-255

005574C2           and   edx, 0FFh     // keep dl set rest 0 if negative

005574CB           mov   eax, edx

Later often used for:

Code: Select all

00558737           cmp   eax, -1  -> impossible due to above 'and' ???

[Flocke]

The entire MPR565.dll is hardcoded for a max limit of 128 (-1?) palettes. And I mean HARD-coded.

Code: Select all

1001860C                 cmp     esi, 80h      // 0x17A0E -> for malloc and data stack (by thunderchero)

To prevent a crash when returning to BotF all data for free functions has to be changed: +(0x418 * new extra palettes limit)

Yep, it looks to be hard-coded indeed. From what I found it might be initialized with MPRCreateRC (shorthand for resource context)
Debugging it I however was struggled by the disappearing mouse cursor.

In case we manage to relocate the palettes, the fact that all the data is hard-coded however doesn't necessarily mean that all subsequent data references need to be updated too. Maybe we can just leave the previous array in place and only move contents.

With debugging I found that the start of the palette list is read from .bss asm_100841E0 + 44Ch = asm_1008462C
compare:

Code: Select all

.text:100185FB                 lea     eax, [ebx+44Ch]

It first is accessed by the data block initialization at asm_10018C7E (rep stosd => for ecx = 8300h repetitions, store eax = zero into edi = (esi:100841E0h + 34h)

The next time it is accessed is when the palette is allocated and stored to the palette list by MPRNewTexturePalette:

Code: Select all

.text:100185FB                 lea     eax, [ebx+44Ch]
.text:10018601                 cmp     dword ptr [eax], 0
.text:10018630                 mov     [edi], eax

Thereafter it is accessed in asm_10018C42 (10000000h + 5AA8C42h - 5A90000h), where by rep movsd the contents of the palette is copied over from esi to edi.

palette_access.jpg (42.36 KiB) Viewed 805 times

And finally, once combat is over, it is released in:

Code: Select all

.text:10018718                 mov     eax, [ebp+esi+34h]
mov     dword ptr [ebp+esi+34h], 0

palette_release.jpg (96.84 KiB) Viewed 805 times

At least for combat IDA didn't show any further access to the global palette list, not even when the application is quit and not by the rendering either. But is it a back copy? What about the other 414 bytes of each palette entry?

I might have set the breakpoint wrong, the large first entry gap indicates that the data pointer only is stored to the end of the 418 bytes palette entry.

[thunderchero]

input overload... brain exploded (add video of your choice)

[Flocke]

What about the other 414 bytes of each palette entry?

I kept analysing the palette entries.
They are rather stupid as usual...

In sub_1001BC70 all the 128 palette entries of 418 bytes each are getting zero initialized by rep stosd.
That command repeats to write the 4 byte eax value 8300h times, so 418h/4 = 106h * 80h entries = 8300h.

init_palettes.jpg (57.08 KiB) Viewed 697 times

The very first palette entry starts at asm_10084214 and seems to be skipped.

Code: Select all

.text:100185F6                 mov     esi, 1

It is preceded by the gen.mpr library handle, stored by asm_10016367.

For the next 127 entries, they usually begin with a data pointer to the palette data, as already reported. In some cases yet to be analysed it however is set to zero, like below. If set to zero, the entries by themselves contain the palette data, making it such huge! Otherwise they instead are mostly blank.

Palette entry structure (UPDATED):
0x000-0x003: the allocated palette data pointer or zero
the buffer allocation routine sub_100185FB searches for the first unused entry by checking whether the palette data pointer is set or not
this is both the case for combat and tech info screen

0x004-0x007: always set to 0x7FFFFFFFh, max signed integer
0x008-0x00B: always the base pointer to asm_100841E0, which contains the palette list
0x00C-0x00F: some usage counter I guess

palette defaults 0x004-0x00F are initialized at:

Code: Select all

.text:10018636                 mov     [edi+8], ebx ( =100841E0h )
.text:10018639                 mov     dword ptr [edi+0Ch], 0
.text:10018640                 mov     dword ptr [edi+4], 7FFFFFFFh

the counter gets incremented at:

Code: Select all

.text:10018C4A                 mov     ecx, [eax+40h]
.text:10018C4D                 inc     ecx
.text:10018C4E                 and     ecx, 7FFFFFFFh
.text:10018C54                 mov     [eax+40h], ecx

0x010-0x013: by some models set to the model render number, e.g. 78h or EFh, else 0
the value is getting read at asm_10015297 to check whether it is already set:

Code: Select all

.text:10015291                 mov     ecx, ds:dword_1003D6C0
.text:10015297                 mov     edx, [eax]
.text:10015299                 and     edi, 0F8F8F8F8h
.text:1001529F                 cmp     edx, ecx

palette_convert.jpg (93.5 KiB) Viewed 667 times

if not already set, the optional data array gets copied over at asm_100152E0 (see optional palette data)
and afterwards at asm_100152F1 the palette index gets stored:

Code: Select all

.text:100152EB                 mov     edx, ds:dword_1003D6C0
.text:100152F1                 mov     [ecx], edx

0x014-0x017: converted 16bit palette data pointer, usually zero
sub_10015270 first stores away the current palette index pointer

Code: Select all

.text:100152A1                 mov     off_10298154, eax

then it checks whether the converted 16bit palette pointer is zero

Code: Select all

.text:100152AB                 test    esi, esi

next it keeps searching esi+4 for first zero pointer or end mark "F8F8F8F8" (edi) like it was a queue

Code: Select all

.text:100152AF                 cmp     [esi], edi
.text:100152B1                 jz      short loc_100152BC
.text:100152B3                 mov     esi, [esi+4]
.text:100152B6                 test    esi, esi
.text:100152B8                 jnz     short loc_100152AF

if marked "F8F8F8F8" processing is aborted
the "F8F8F8F8" value is set short thereafter at

Code: Select all

.text:10015301                 mov     [eax], edi

afterwards loc_59C52F3 calls sub_100153D0, which updates the data pointer at asm_10015427

Code: Select all

.text:100152F3                 call    sub_100153D0
.text:100153D0                 mov     ecx, off_10298150
.text:10015427                 mov     [ecx+4], eax

short thereafter with the loop of loc_1001535D the optional palette data is converted from 32bit ARGB to 16bit RGB and written to the 16bit palette data with an offset of 18h

Code: Select all

.text:100152F8                 lea     ebx, [eax+18h]

it is returned to the callee, but in another iteration of sub_10015270 the processing is skipped but it is read back from the pointer at

Code: Select all

.text:100152C3                 lea     eax, [esi+18h]

so sub_10015270 does the 16bit conversion, caches the converted data and sets both the converted data pointer and the entry number

sub_10015270 is called from

Code: Select all

.text:1001852A                 jmp     sub_10015270
.text:10016FBF                 call    sub_10018500
.text:10002E43                 call    dword ptr [edx+38h]
.text:100156E5                 call    sub_10001C50
.text:10001522                 call    sub_10015630
.text:1001A271                 call    [esp+2Ch+var_8]
.text:10015EAD                 call    dword ptr [eax+edx*4] (engMessage case eax=7)

also called from

Code: Select all

.text:1001852A                 jmp     sub_10015270
.text:10005BF2                 call    sub_10018500
.text:10002E43                 call    dword ptr [edx+38h]
.text:100156E5                 call    sub_10001C50
.text:100016D7                 call    sub_10015630
.text:1001A29D                 call    [esp+24h+var_4]
.text:10015EAD                 call    dword ptr [eax+edx*4] (engMessage case eax=7)

both called from

Code: Select all

mpr97.dll:1000290C             call    dword ptr [eax+18h] (MPRMessage case 2)
trek.exe:0053AE8B              call    MPRMessage
trek.exe:0053AE0E              call    MPRMessage_context_buffer
trek.exe:00511758              call    call_MPRMessage_context_buffer
trek.exe:00402484              call    cc_MPRMessage_context_buffer
trek.exe:0040233C              call    c_call_Time_render_object

sub_10018500 is a massive data processing routine and by the call stack above looks to be part of the rendering process
engMessage case 7 keeps processing some message array, always substracting the message size till all are processed


0x018-0x418: optional palette data
the optionla palette data is written by the data copy routine sub_10014C70 at:

Code: Select all

.text:05A44CC1 mov     [ecx-4], edx

called from

Code: Select all

.text:100152E0                 call    sub_10014C70

which only happens for some of the ships, see viewtopic.php?p=59974#p59974
furthermore it only is written once when a new model is rendered, afterwards it is reused

palette_entry.jpg (26.83 KiB) Viewed 697 times

asm_1003D6C0 is some model render counter it seems. It isn't reset but continues to increment with:

Code: Select all

.text:10015206                 inc     ds:dword_1003D6C0

more analysis to follow

input overload... brain exploded (add video of your choice)

almost as insane like this I guess:
https://www.youtube.com/watch?v=ctUDMAcKqrE

[thunderchero]

almost as insane like this I guess:
https://www.youtube.com/watch?v=ctUDMAcKqrE

more like mars attack

head-exploding.gif (688.31 KiB) Viewed 783 times

[thunderchero]

[EDIT] I start to see the pattern, but you guys are not going to like it.

The entire MPR565.dll is hardcoded for a max limit of 128 (-1?) palettes. And I mean HARD-coded.

Code: Select all

1001860C                 cmp     esi, 80h      // 0x17A0E -> for malloc and data stack (by thunderchero)

To prevent a crash when returning to BotF all data for free functions has to be changed: +(0x418 * new extra palettes limit)

Some of them:

changed all you had listed and ctd on game start...

event viewer log
Fault offset: 0x00018811
Faulting process id: 0x1e5c
Faulting application start time: 0x01d9e271213f6855
Faulting application path: E:\botf\Vanilla\trek.exe
Faulting module path: E:\botf\Vanilla\mpr565.dll

[Spocks-cuddly-tribble]

changed all you had listed and ctd on game start...

Don't waste your time (yet). This is just some of them, some like the 40k+ might need 0x418*2, and some other wrong and not even used or lead to crash.

You need all and just the right ones for this to work.

Same as Flocke I think most of this crap is not even used and pointless. So it's just about the free functions before returning.


We could just force a fixed alloc/free total size and ignore all the crap data?
But combat vs reseach screen and screensaver might use different load/unload modi.

If you look at sub_10018700 free_palettes there is two calls:

sub_10018780 loop_free_max_0x80_times -> sub_10018660 free_??_crap_before_palettes

Here is a switch case @ off_1001610C for most of them:

Code: Select all

.text:1001610C off_1001610C    dd offset loc_100160E3    ; jump table for switch statement
.text:1001610C                 dd offset loc_10015F64
.text:1001610C                 dd offset lo_free_max_0x80_palettes_plus_crap
.text:1001610C                 dd offset loc_10015FCB
.text:1001610C                 dd offset loc_10015FDA
.text:1001610C                 dd offset loc_10015FFB
.text:1001610C                 dd offset go_free_??_crap_before_palettes
.text:1001610C                 dd offset loc_100160E3
.text:1001610C                 dd offset loc_100160A4
.text:1001610C                 dd offset go_loop_max_127_palettes_malloc
.text:1001610C                 dd offset go_copy_palettes
.text:1001610C                 dd offset go_free_1_palette?

[EDIT] Important question:

With only this change and over-limit palettes used are there any bugs in tactical combat?

Code: Select all

1001860C                 cmp     esi, 80h      // 0x17A0E -> for malloc and data stack (by thunderchero)

E.g. damage spots missing, explosions, station special damage textures & flashing lights?

After destruction/retreat of ships any issues next combat turn (since object removed)?

[thunderchero]

[EDIT] Important question:

With only this change and over-limit palettes used are there any bugs in tactical combat?

Code: Select all

1001860C                 cmp     esi, 80h      // 0x17A0E -> for malloc and data stack (by thunderchero)

E.g. damage spots missing, explosions, station special damage textures & flashing lights?

After destruction/retreat of ships any issues next combat turn (since object removed)?

I have not had many combats, all effects present as far as I can tell but,
crash after combat complete when switching to main map screen.
but after combat completed before I selected "end" I could select "option" to switch to main home screen without crash.

EDIT;
this one is causing CTD on game load (with all other code changes I saw no change in crashes)

10017E25 0x0017227*               mov     edx, [eax+20C34h] 1C 14 04 00

Note; I am using 127 + 127 = FE (+1 = FF)
7E -> FE
80 -> FF

EDIT2;
new crash position when selecting too many ships in research screen

Fault offset: 0x000153dd
Faulting process id: 0x289c
Faulting application start time: 0x01d9e2c052bfd243
Faulting application path: E:\botf\Vanilla\trek.exe
Faulting module path: E:\botf\Vanilla\mpr565.dll

What is this big value at;

10015E6A 89 3D 10 B1 01 10                               mov     ds:dword_1001B110, edi

[Spocks-cuddly-tribble]

No idea whether this project is realistic. I wouldn't pursue it.

You need to search at least all values larger than 0x20000h and many others.

A few of the many still missing ones in my above list:

Code: Select all

10015E77                 test    byte ptr [eax+20C50h], 4

100160EA                 test    byte ptr [edx+20C50h], 4

10018684                 mov     ebp, [edi+20C34h]

100186A4                 mov     [edi+20C38h], eax

100186B3                 mov     [edi+20C3Ch], edx

100186BC                 test    byte ptr [edx+20C74h], 4

Plus stuff like this:

In sub_1001BC70 all the 128 palette entries of 418 bytes each are getting zero initialized by rep stosd.
That command repeats to write the 4 byte eax value 8300h times, so 418h/4 = 106h * 80h entries = 8300h.

What is this big value at;

10015E6A 89 3D 10 B1 01 10                               mov     ds:dword_1001B110, edi

No value, just a pointer to dynamic location dword_1001B110?

Only fixed size dynamic areas with static location would need relocation if the stored data block was extended.

[thunderchero]

current Changes I am testing

Code: Select all

add +0x418 * new extra palettes limit +0x7Fh (+127) E8 07 02 00 133096

10015E77 0x0015279                test    byte ptr [eax+20C50h], 4  38 14 04 00       

100160EA 0x00154ec                test    byte ptr [edx+20C50h], 4  38 14 04 00 

10017E25 0x0017227 *CTD           mov     edx, [eax+20C34h] 1C 14 04 00

10017EAA 0x00172ac                test    byte ptr [ecx+20C50h], 8   38 14 04 00 

---

10018732 0x0017b34                mov     al, [ebp+20C74h] 5C 14 04 00

10018788 0x0017b8a                mov     eax, [esi+20C34h] 1C 14 04 00

10018795 0x0017b97                mov     dword ptr [esi+20C34h], 0 1C 14 04 00
1001879F 0x0017ba1                mov     edx, [esi+20C38h] 20 14 04 00

100187B6 0x0017bb8                mov     edx, [ecx+20C38h] 20 14 04 00

100187E5 0x0017be7                cmp     esi, 20C00h     ; 0x418 * 0x80 default E8 13 04 00

---

10018818 0x0017c1a                mov     eax, [ecx+20C34h] 1C 14 04 00

10018840 0x0017c43                mov     ax, [ecx+20C74h] 5C 14 04 00

1001888F 0x0017c91                test    byte ptr [ecx+20C74h], 8 5C 14 04 00

10018979 0x0017d7b                mov     [edx+20C3Ch], ecx 24 14 04 00

10018989 0x0017d8b                mov     ecx, [eax+20C38h] 20 14 04 00
1001898F 0x0017d91                mov     [eax+20C38h], ebx 20 14 04 00

1001899E 0x0017da0                mov     eax, [ecx+424ECh] D4 2C 06 00

100189B7 0x0017db9                test    byte ptr [ecx+20C74h], 2 5C 14 04 00

10018A07 0x0017e09                test    byte ptr [eax+20C74h], 8 5C 14 04 00

10018A1C 0x0017e1e                mov     eax, [edx+20C3Ch] 24 14 04 00

10018A68 0x0017e6a                mov     esi, [eax+20C3Ch] 24 14 04 00

10018A92 0x0017e94                mov     ecx, [eax+424ECh] D4 2C 06 00

10018AE8 0x0017eea                mov     esi, [ecx+20C3Ch] 24 14 04 00

---

10018684 0x0017a86                mov     ebp, [edi+20C34h] 1C 14 04 00

100186A4 0x0017aa6                mov     [edi+20C38h], eax 20 14 04 00

100186B3 0x0017ab5                mov     [edi+20C3Ch], edx 24 14 04 00

100186BC 0x0017abe                test    byte ptr [edx+20C74h], 4 5C 14 04 00

---

1001860C 0x0017A0E                cmp     esi, 80h      //  -> for malloc and data stack (by thunderchero)

100188A4 0x0017ca5                mov     ecx, 7Fh ?

100188FC 0x0017cfe                cmp     ebp, 80h ?

10298790 0x001ad90                          dd 7Fh ?

results from changes above

if palette is 127 or below,
ran 300+ combat no crash exiting and no issues switching screens
crash after combat entering research/ships and selecting ships in research

if palette is 128 or above,
crash exiting combat, crash selecting ships in research, crash switching screens after selecting ships
no crash switching screens (went 30+ turns) as long as you never load any ships in research/combat

[thunderchero]

that is a lot of new info you added

right before I read I was looking at this file
Graphics\BSPlib\TexBank.cpp

this sounds like what you are describing lol

Edit I can't believe some of the comments in source
"palID = 0; // Punt! Might break somewhere else later (runtime?) but for now..."

[Spocks-cuddly-tribble]

So the sole purpose of MPR565.dll is converting the palette data to 16bit for the MPR context dialog?

Graphics\BSPlib\TexBank.cpp - I can't believe some of the comments in source:

"palID = 0; // Punt! Might break somewhere else later (runtime?) but for now..."

I guess that's the main reason why the hid/trashed the trek.exe source code.
It would look very bad for all involved people. Albeit clearly not their fault given the shortage of time they had to deal with.