Most obscure RW features: TXD screen drawing

[The_GTA]

Dear MTA community, you may not expect what I am about to show you. But your reaction is important to me so that I can categorize this new discovery. I am currently researching the TXD loading mechanics on request by the MTA team and I have found this peculiar use-case that I think is not a security hazard but a dubious feature. Don't get me wrong: this feature does NOT corrupt game memory, does not change game variables in a harmful way.

Consider the following MTA clientside script:

addEventHandler("onClientRender", root, function()
        local txd = engineLoadTXD("screendraw.txd");
        assert(not (txd == false));
        destroyElement(txd);
    end
);

Did you know that this script can be used to replace the backbuffer of the GTA SA engine? The result is as follows:

You can download the resource here: https://green-candy.osdn.jp/mta/screendraw.zip
Load it onto your local MTA server, start it and execute the "rt sdhd" command.

You need to have a clientside resolution of 1920x1200x32 for this resource to work.

You can edit the texture using my Magic.TXD tool to change the content that it displays using the screendraw resource.

What do you think about this feature? Do you think MTA should disallow TXD files that can draw onto the GTA SA/MTA screen by loading them?

Edited August 31, 2021 by The_GTA

[Einheit-101]

I see this as bug. 

[The_GTA]

32 minutes ago, Einheit-101 said:

I see this as bug. 

Let me explain to you how this might not be a bug from the perspective of RenderWare developers. Each texture can be one of the following types: normal, zbuf, camera, texture or camera texture. By loading a texture you are supposed to put pixels into the destination of a texture. In the normal or texture case, the target is a simple color buffer that can be mapped to triangles. In the camera texture case it is what we call render-targets inside MTA. But for the camera case, the destination is the camera itself. So you can see how loading a "camera" texture loads pixels into the backbuffer, directly.

But I think that MTA might not have anticipated this. Thank you for sharing your thought!

[Einheit-101]

As long as it does not harm anybody it makes no sense to do something against it, even if its completely useless after all. 

[Lergen]

That's an interesting find. But I think it'd be difficult for your average user to do anything overtly malicious with it, right? Practically speaking I think you'd likely only see something like this used by server admins messing with players (of which there's already a lot of ways for them to do that). Though that being said, in a worst-case scenario I can definitely see it potentially being snuck into an encrypted/malicious script or something of that nature which could be a real nuisance.

 

I think it's fine to keep it as-is for now since there doesn't seem to be any public misuse of it yet. But if it comes down to it the feature can always be disabled since you already know what the cause is.

Edited September 23, 2021 by Lergen

[The_GTA]

3 minutes ago, Lergen said:

... can always be disabled since you already know what the cause is.

Yes, I do! I know exactly what causes it in the game logic/code and how to modify the game to restrict the texture loader without impacting the regular use.

[DiSaMe]

What an interesting finding. If RenderWare developers specifically made textures work that way, then it's not a bug of RenderWare.

Is it a bug of MTA, though? That's a separate issue. If the purpose of TXD functions was to make custom textures apply to models and nothing else, then yes, it's a bug that's caused by absence of data validation in engineLoadTXD. If the purpose was to load the data the exact way RenderWare does it, it's not a bug. But that's just playing around with words - even if it's not a "bug", whether we should keep it or not is another separate issue

7 hours ago, The_GTA said:

Each texture can be one of the following types: normal, zbuf, camera, texture or camera texture.

Where is it specified? I'm looking at https://gtamods.com/wiki/Raster_(RW_Section) and there's some rasterType structure member but no description, is that it? Remembering the times I used to read/write TXD files, it's interesting to find out that there's this thing I never knew about. On the other hand, it's likely I wouldn't have found it interesting if I somehow managed to get this behavior back then, without knowing how it works.

Edited September 23, 2021 by Reyomin

[The_GTA]

54 minutes ago, Reyomin said:

Where is it specified? I'm looking at https://gtamods.com/wiki/Raster_(RW_Section) and there's some rasterType structure member but no description, is that it?

Yes, but the documentation is wrong. rasterType is just the first three bits of the 8bit unsigned char value.

0 - normal
1 - zbuf
2 - camera
4 - texture
5 - camera texture

Values 3, 6 and 7 are invalid. I have correct documentation of the D3D9 native texture binary stream format in my OneNote documents. I could export it if there is real demand.

[DiSaMe]

23 hours ago, The_GTA said:

Yes, but the documentation is wrong. rasterType is just the first three bits of the 8bit unsigned char value.

0 - normal
1 - zbuf
2 - camera
4 - texture
5 - camera texture

Values 3, 6 and 7 are invalid. I have correct documentation of the D3D9 native texture binary stream format in my OneNote documents. I could export it if there is real demand.

It's amazing how you know all these details. Knowledge about TXD/DFF in general would have helped me a lot back then. And even though I don't do anything related anymore, that doesn't make your findings any less interesting