Script Headers

[twinj]

Ok I want to understand the header and footer of a script. I am starting with functions headers.

 

My example: from Class UiSquadList_SSquadList in XcomStrategyGame

 

D4 16 00 00 A9 1F 00 00 00 00 00 00 CE 16 00 00
00 00 00 00 00 00 00 00 D4 16 00 00 00 00 00 00
39 00 00 00 24 07 00 00 15 01 00 00 C5 00 00 00
1B 55 21 00 00 00 00 00 00 00 D4 16 00 00 00 D3
16 00 00 00 D2 16 00 00 4A 16 14 2D 01 C6 16 00
00 2D 00 D0 16 00 00 0F 00 CF 16 00 00 19 00 D1
16 00 00 0A 00 50 37 00 00 00 1B 8B 0E 00 00 00
00 00 00 16 0F 01 C4 16 00 00 19 00 CF 16 00 00
0A 00 E2 3D 00 00 00 1B AF 0E 00 00 00 00 00 00
16 55 01 C7 16 00 00 03 00 2C 03 16 55 01 C7 16
00 00 03 00 2C 02 16 55 01 C7 16 00 00 03 00 2C
04 16 55 01 C7 16 00 00 02 00 26 16 55 01 C7 16
00 00 03 00 2C 05 16 55 01 C7 16 00 00 02 00 25
16 0F 01 C9 16 00 00 45 9A 01 C4 16 00 00 2C 06
16 02 00 2C 05 02 00 2C 04 54 01 C8 16 00 00 2C
06 16 04 0B 53 00 00 00 02 01 02 00 FA 12 00 00
00 00 00 00

 

simulated function Init(XComPlayerController _controller, UIFxsMovie _manager, UI_FxsScreen _screen, XGMission kMission, bool bNav)
{
   local XGShip_Dropship kSkyranger;

   PanelInit(_controller, _manager, _screen);
   bCanNavigate = bNav;
   kSkyranger = kMission.GetAssignedSkyranger();
   m_iMaxSlots = kSkyranger.GetCapacity();
   m_arrFillOrderIndex.AddItem(3);
   m_arrFillOrderIndex.AddItem(2);
   m_arrFillOrderIndex.AddItem(4);
   m_arrFillOrderIndex.AddItem(1);
   m_arrFillOrderIndex.AddItem(5);
   m_arrFillOrderIndex.AddItem(0);
   m_iCurrentSelection = ((m_iMaxSlots == 6) ? 5 : 4);
   m_arrUIOptions.Add(6);
}

 

So far I know: The first 48 bytes is a header and the last 12 some sort of extra info.

 

The first 16 seem to point to the objects class and a reference to a name table.

INDEX is DWORD size on file (4 bytes) else 8 bytes on load.

 

INDEX Object reference in export table. [self]

INDEX Object reference in export table: [Children] e.g: in XcomStratgeyGame a91f for None. or 8105 in table which = None.

DWORD ???? Not sure what this is may only be relevant to Classes.

INDEX Object reference in export table: [First Paramater] - read Export table from here until [self] order seems to be backwards pointing to [self], [Parameters], [ReturnValue], [Locals]All of these will affect jump counts and virtual file size.

 

The next 16 probably include child name flags as values can be negative

 

The last 16 bytes in the header:

 

 

DWORD LineNumber 'in class'. In UE Explorer this can be confirmed lines however do not match perfectly..

 

DWORD unknown

 

DWORD TextPos ??? in my example this 277. In my short analysis this always seems to be higher than EndOffset and the cave size (being endoffset - this) seems to always be a multiple of 4. I believe that if you rewrite a script and change the amount of index reads that you must recalculate this..

 

DWORD EndOffset This is the 'size' of the script from the end of the header to the start of the End of Script token 0x53. Note this size does not include actual load size. Some tokens get expanded to 8 bytes rather than four increasing this size. I believe a good parser could recalculate and fix all size issues with proper header information so as to repack.

 

BYTEs Script Script Code

 

BYTES 0x53 plus 15 more. There seems to be some flags in this part.

 

Can anyone add to this? Specifically the last 16 bytes in header.

Edited December 22, 2012 by twinj

[twinj]

DWORD TextPos ??? in my example this 277. In my short analysis this always seems to be higher than EndOffset and the cave size (being endoffset - this) seems to always be a multiple of 4. I believe that if you rewrite a script and change the amount of index reads that you must recalculate this..

 

I am pretty sure this is the size of the script expanded with index object reads. Including the paramaters.

[bokauk]

Some tokens get expanded to 8 bytes rather than four increasing this size. I believe a good parser could recalculate and fix all size issues with proper header information so as to repack.

 

...

 

BYTES 0x53 plus 15 more. There seems to be some flags in this part.

 

Can anyone add to this? Specifically the last 16 bytes in header.

I really like your idea about automatically fixing all size issues (if I understand you correctly). Calculating it manually will do for now, but what you suggest sounds like the way forward, albeit probably beyond my capabilities!

 

Regarding the footer (after EndOfScriptToken (53)), I think I accidently edited a byte which changed the function to a simulated function, although I'm not sure which byte or to what exactly. Not too helpful at the moment, but might be some sort of indication :) . I could be mistaken though, so it will obviously need more rigorous testing :)

[twinj]

Regarding the footer (after EndOfScriptToken (53)), I think I accidently edited a byte which changed the function to a simulated function, although I'm not sure which byte or to what exactly. Not too helpful at the moment, but might be some sort of indication . I could be mistaken though, so it will obviously need more rigorous testing

 

Nope that's what the footer is for.

 

I have made heaps of progress since this post but just haven't shared it. A lot of this stuff is already known by Eliot > he is a massive resource.

 

His post here, http://eliotvu.com/unreal-package-file-format.html, also points to other resources which go into massive detail. I have also studied the C# Unhood, I think you are a C# man right?

 

I have been working on a java version of a decompiler so I can tokenize the scripts and hopefully be able to rebuild packages on size changes and to enable full parametrization for XCMM. (I will be moving away from XCom in the future.. and enabling XCMM to handle different games.

 

For now though I am stuck on how to deserialize Exports into classes and properties.

 

I am successfully decompiling functions at the moment.

[bokauk]

Nope that's what the footer is for.

Isn't that what I said? hehe ;)

 

I've had the Unhood source downloaded for a while now, but when I first looked at it, it was beyond my understanding as I'm still learning C# as I go along. I might take another look now though, since I've learnt quite a bit since then. Eliot had also previously mentioned about adjusting the ScriptSize property when removing object indexes, but again, at the time it was beyond my understanding. Looking back on what he said and after your explaination, it all makes sense now! :)

 

Thanks for the link, I hadn't seen those other resources at the bottom before.

 

It sounds like the impact of your decompiler could be huge and very extensible! Keep up the excellent work and keep us posted :)

[twinj]

Nope that's what the footer is for.

Isn't that what I said? hehe ;)

 

I've had the Unhood source downloaded for a while now, but when I first looked at it, it was beyond my understanding as I'm still learning C# as I go along. I might take another look now though, since I've learnt quite a bit since then. Eliot had also previously mentioned about adjusting the ScriptSize property when removing object indexes, but again, at the time it was beyond my understanding. Looking back on what he said and after your explaination, it all makes sense now! :)

 

Thanks for the link, I hadn't seen those other resources at the bottom before.

 

It sounds like the impact of your decompiler could be huge and very extensible! Keep up the excellent work and keep us posted :)

 

Yeah sometimes I rush too much and dont get my true point across. What I meant was is that you were not mistaken.