Wanting to understand Restunts source code structure

[llm]

I'm not starting with ida.

would be the easiest - but IDA is commercial, costs ~400$ in the home edition

i would love to go back to IDA Freeware 5 (the only free version that still supports DOS)
official download available on ScummVM homepage: https://www.scummvm.org/news/20180331/

but upgrading the IDA database (idb) is a one-way-ticket - and im currently working with 6.8

but you should install the freeware - give you a good idea how that all works, even if IDA is not the latest of the latest - most reversing projects using this freeware version (or Ghidra - which is sometimes problematic with segment/offset support)

[Daniel3D]

I'm not starting with ida.

would be the easiest - but IDA is commercial, costs ~400$ in the home edition

O i would love to learn more about this.
But with the current state of my knowledge everything has to be checked anyway.
But i can significantly reduce the amount of options.

[Daniel3D]

This should be one to.
Lucky find on my phone..

[llm]

This should be one to.
Lucky find on my phone..

no thats the DOS-API (int 21h, function=ah=4Ch=exit program, with error=al=0FFh result == -1)
http://www.osfree.org/doku/en:docs:dos:api:int21:4c

could be written as

Code Select Expand

mov ah,4Ch
mov al,0FFh ; -1
int 21h

or

Code Select Expand

mov ax,4CFFh
int 21h

you always need to analyse the context around a little - everything in assembler is more or less global, typeless (pointer, value, ... everything is possible)

C port of that is

Code Select Expand

exit(-1);


[Daniel3D]

Alright,..
As far as I understand now, the non-symbolic offsets point to a location in the binary with a hex value.
Looking at you regex i removed some variables to filter results that i wouldn't recognize as offset anyway.
resulting in : ((0[a-fA-F0-9]*|[1-9][a-fA-F0-9]*)h) i suppose that will only result in all hex values.

On that note, I looked at the first 12 segments. And I have come up with this..
This is everything resembling an offset I can find..
seg000 Line 2185:     mov     ax, 95F8h
seg003 Line 860:     mov     ax, 0AE6h ; 2790 .. probably nothing
seg003 Line 3996:     mov     ax, 4650h 1/3 in short space.. probably nothing
seg003 Line 4002:     mov     ax, 3A98h 2/3 in short space.. probably nothing
seg003 Line 4012:     mov     ax, 0B9B0h 2/3 in short space.. probably nothing
seg003 Line 5847:     mov     ax, 0AA0Eh
seg005 Line 1282.84,96:     mov     ax, 0AA5Eh also 3 in a few lines probably nothing
seg007 Line  123:     cmp     si, 6AD0h
seg007 Line  844:     add     bx, 6364h ; 25444 ??
seg007 Line  861:     mov     ax, 33BCh
seg009 Line 2201:     mov     ax, 95F8h
seg010 Line  835:     mov     si, 54C6h
seg010 Line  980:     mov     bx, 36BAh// these two and several others all between 3000H and 4000h
seg010 Line  999:     mov     si, 36D0h\\ until Line 1460 // probably nothing. just in case
seg010 Line 2066:     mov     ax, 37EAh
seg010 Line 2071:     mov     ax, 37F1h
seg010 Line 3184:     mov     di, 360Ah
seg010 Line 3206:     cmp     si, 365Ah
seg010 Line 3244:     cmp     si, 365Ah
seg010 Line 3868:     mov     ax, 43FDh
seg010 Line 3878:     add     ax, 9EC3h
seg012 Line  7499:     mov     ax, 49A0h
seg012 Line  7882:     mov     ax, 4BC6h
seg012 Line  9800:     sub     cx, 425Ch


others not an offset but could be mistaken.
seg001 Line  944:     mov     ax, 1E00h ; i think based on contents: full trk grid length/4
seg001 Line 2407:     cmp     [bx+di+CARSTATE.car_rc1], 5AEBh ; "23275"

Assuming I didn't miss any.. (which is a bold assumption, I am aware of that) the number of offsets is not too many, even if all of these are actually correct.

[Daniel3D]

I'm about 2/3 through the results now. I hope I have not missed any. I like to have the code clean of them.
Furthermore, I could not find any in segment 16 to 26. But I am only looking at big hex values that are not 0FFsomthing or round thousands in Dec..
(you don't have to explain every possible hit or miss, but I do hope it is of use when somebody has time to work on the source)

seg012 Line 10106:     mov     ax, ds:4E92h : 20114..
seg012 Line 10252:     cmp     bx, ds:3C56h : 15446
seg012 Line 13214:     mov     ax, 5416h : 21526
seg012 Line 18575:     mov     ss:54AAh     : 21674
seg012 Line 18597:     mov     cl, ss:54ABh : 21675
seg014 Line 116:     mov     ax, 2D41h : 11585
seg014 Line 193:     mov     ax, 393Eh : 14654
seg015 Line 194:     mov     ax, 3E17h : 15895
seg015 Line 249:     mov     ax, 3333h : 13107
seg027 Line  271:     mov     di, 8224h : 33316
seg027 Line  313:     mov     di, 0A2B6h : 41654
seg027 Line  510:     mov     si, 81FCh : 33276
seg027 Line  569:     mov     di, 86BCh : 34492
seg027 Line  744:     mov     si, 86E0h : 34528
seg027 Line 1383:     mov     ax, 4EC6h : 20166
seg027 Line 2705:     mov     ax, 4FA3h : 20387
seg027 Line 2714:     mov     ax, 4FD5h : 20437
seg027 Line 2719:     mov     di, 8214h : sp? 33300
seg027 Line 2720:     mov     word ptr [bp-6], 81FCh : 33276
seg027 Line 2728:     mov     ax, 4FFBh : 20475
seg027 Line 2738:     mov     ax, 5010h : 20496
seg027 Line 2748:     mov     di, 0A2C2h --
seg027 Line 2750:     mov     word ptr [bp-4], 0A2BEh --
seg027 Line 2752:     mov     word ptr [bp-8], 0A2B7h --
seg027 Line 2769:     mov     ax, 501Dh --
seg028 Line  237:     add     ax, 81FCh ref to dseg
seg028 Line  262:     mov     ax, 728Eh --

don't know...
seg027 Line 2224:     mov     di, 0A2B7h ?? 5 similar in 5 lines,
   Line 2224:     mov     di, 0A2B7h
   Line 2225:     mov     [bp+var_6], 0A2B6h
   Line 2226:     mov     [bp+var_8], 0A2B8h
   Line 2227:     mov     [bp+var_A], 0A2C6h
   Line 2228:     mov     [bp+var_C], 0A2E2h

[llm]

nice findings - i will have a look and check what of these a real offsets - but i think at least 50% are very likely offsets

[Daniel3D]

but i think at least 50% are very likely offsets

That is a motivating estimate.

[llm]

again, for your daily training

what happens if offsets are not symbolic?

Code Select Expand

0x3440 func0
0x3440  mov ax,0x3456
0x3442  call XYZ
0x3448
0x3450 func1
0x3451   some code <-- the above non-symbolic offset will get wrong if you add/remove code here
0x3452
0x3453
0x3454
0x3455
0x3456: dw some_value 234


Code Select Expand

func0
  mov ax,offset some_value
  call XYZ

func1
  some code <-- the above symbolic offset will not get wrong if you add/remove code here

dw some_value 234


[Daniel3D]

what happens if offsets are not symbolic?

Code Select Expand

Code Select Expand

0x3440 func0
0x3440  mov ax,0x3456
0x3442  call XYZ
0x3448
0x3450 func1
0x3451   some code <-- the above non-symbolic offset will get wrong if you add/remove code here
0x3452 added code
0x3453 added code
0x3454 added code
0x3455
0x3456: Something entirely different (not: dw some_value 234)
0x3457
0x3458
0x3459: dw some_value 234

Like this?
Then func0 fails. I know. That is why getting rid of them is important.
Just like making it para 16 and removing the alignment bytes; that I can do myself, I think.

I have more time next year. I will do everything I can to have those two finished next year.
It will benefit reversing the code, but also modding the code.

[Daniel3D]

And it does not matter where Func0 is. If the new code is before the location that Func0 is looking for it fails.

The function itself is not affected by the changed offset, but it fails because the required data has moved. Like..

Code Select Expand

0x3448
0x3450 func1
0x3451   some code <-- the above non-symbolic offset will get wrong if you add/remove code here
0x3452 added code
0x3453 added code
0x3454 added code
0x3455
0x3456: Something entirely different (not: dw some_value 234)
0x3457
0x3458
0x3459: dw some_value 234
0
0
more...
0
0
0x4440 func0
0x4440  mov ax,0x3456
0x4442  call XYZ

[Daniel3D]

There is a function that loads horizons. That function gets its filenames from Dseg.
You can not add a name there because it will create an offset and make all non-symbolic functions in the whole code fail. If we fix that, we can easily (probably not ) create new horizons.
it's a trivial, unimportant change, but a nice small project to make and to kinda test stability.

[llm]

what happens if offsets are not symbolic?

Code Select Expand

Code Select Expand

0x3440 func0
0x3440  mov ax,0x3456
0x3442  call XYZ
0x3448
0x3450 func1
0x3451   some code <-- the above non-symbolic offset will get wrong if you add/remove code here
0x3452 added code
0x3453 added code
0x3454 added code
0x3455
0x3456: Something entirely different (not: dw some_value 234)
0x3457
0x3458
0x3459: dw some_value 234

Like this?
Then func0 fails. I know. That is why getting rid of them is important.

yes 100% correct - but "fails" isnt defined here - it could be that the algorithm works still because its just not that robust, or there is a identical or nearly identical value at the target offset
think of values like 0,255,-1 or something there a very typical around so it "could" still work

[llm]

And it does not matter where Func0 is. If the new code is before the location that Func0 is looking for it fails.

yes 100% correct - its not called fails, but "undefined behavior"
its not clear what happens when the value gets read from the wrong offset - nearly everything is possile - like random-problem-generator, it could be that there is always 0 and the correct code always wanted 0, or there is a ever changing value that most of the time is in a range were the function can work with and producing no visual or audio glitches, maybe some strange physic behavior while driving a special way

[llm]

There is a function that loads horizons. That function gets its filenames from Dseg.
You can not add a name there because it will create an offset and make all non-symbolic functions in the whole code fail. If we fix that, we can easily (probably not ) create new horizons.
it's a trivial, unimportant change, but a nice small project to make and to kinda test stability.

yes, but you could add it to the end of the data-segment, and move the stack-segment a little for example
- the stack location is only needed in very early stage of the game while initilizing, this offset is already symbolic, there are some options that do not make the offsets go corrupt, but full symbolic is always the best we can have