Modified game from start - resolved

[olagarde]

This issue is non-critical and low priority.

I've never actually gotten past the start menu, I got the "modified" notice on first start from a fresh install, and since reduced environment to the following reproducer. I can provide stacktrace/log/audit records if it will help. Given time to acquire a second testbed I can provide a system image of the minimal install (per above) or a system image of the full workstation install on which I first encountered this issue (it's a linux game system, there's nothing on it to protect but the cached steam account password).

- Fresh install of Rocky Linux 9.5 from install media onto
(Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 2TB EVO 890 SSD, GTX 1080 Titan Black)
- install epel and rpmfusion repos from official release packages
- install steam from epel packages
- install nvidia akmod kernel drivers
- do not enable selinux (either run without policy in Permissive mode or pass 'selinux=0' in the kernel args)
- start steam, log in, go to My Library, install X4 (includes the Timelines DLC)
- start X4, wait for 1st-time vulkan shaders processing
- X4 starts up with the Timelines screen and and reports the game modified.
- stop X4, walk the version of reported working Proton versions (no difference)
- reinstall X4 (no difference)
- zero xattrs across the filesystem containing the steam library (no difference)

Game files verify successfully, no updates required (X4 --> Properties --> Installed Files --> Verify ... "All 8837 files successfully validated"). Steam does not flag any updates after the initial install. There is no AV, no ACLs, no XATTRs on the FS, no SELINUX, no permissions issues, no FS blocking, no sync/rate/execheap/audit/etc issues in the logs. The underlying OS install, being a RHEL derivative, is as boilerplate as you're going to find anywhere, and contains only packages that satisfy the dependency tree starting at "basesystem" and ending with Gnome (Desktop 40.4-1), XFCE (4.18.1-2), and NVidia akmod (build 550.127.05-1 for kernel 5.14.0-503.16.1). I do not have an account with Steam Workshop, nor with any other modding community platform.

Note again that I've NEVER PLAYED X4. The only time I have on the clock is waiting for the shader processing. I've never gone past the initial Timelines banner screen, there are no saves,

One key item I haven't yet completed testing is changes to the runtimes/proton base underneath X4. This is Linux and Proton, so the vm stack that proton constructs is, from the context of x4, part of x4 at runtime. I think(?) this can be separated with a relocated librarydir for X4 alone plus full lib auditing, but I haven't yet figured out the appropriate _write_at() and *close() event filters.

[CBJ]

I've split this out from an older thread, partly because it's not really related, and partly because that thread contained information that is now very much out of date and might have confused people.

Not having in-depth Linux knowledge, I will pass this on to someone else to review. In the meantime, just in case it helps you think of other possible lines of investigation on your system, the game will show as modified if:

- mods are installed (obviously!)
- game files do not match their signatures
- signature files are missing or inaccessible

[olagarde]

Problem has stopped. I'm assuming it was something done by Proton runtime prior to the update posted nlt 17(?) Dec and applied to the local install yesterday (19 Dec). This is assumed because the issue stopped occurring before audit filtering was fully set up but I think it's a safe assumption because the filesystem container for the steam library had snapshots after the prior post here and again after the steam and X4 startup in which the issue first stopped occuring today. The snapshot deltas show only the hotfix and runtime changes.

The hotfix applied changes to the steam client core but the runtime changes by definition would impact the jvm in which X4 runs. I'm a bit surprised at the implication that the problem was less checksum result failure and more checksum functionality failure. Changes in the jvm do not modify X4 files in any way but they do modify the execution environment, which in turn provides the underlying library calls and hooks. How does X4 implement the checksum call, is it woven up from internal cloth, call extern openssl/libcrypto/etc? If the latter and the previous steam runtime/hotfix borked the extern syms or similar that would explain it. Probably not a fault in the underlying crypto libs, those are far too widely and constantly used by the base os, but a bad jvm passthrough or embedded, is entirely possible (especially since the latter is by definition per-runtime-java-engine-instance).

Either way the results are pretty conclusive, I can switch the issue on and off at will by rocking the steam library filesystem image between the two snapshots, and the delta between the two includes the runtimes bases (.../SteamLibrary/steamapps/common/SteamLinuxRuntime.../) but not the X4 base (SteamLibrary/steamapps/common/X4\ Foundations/). So, the problem was in the execution environment [yet again, go figure].

Update: on a whim I also tried adding/removing a mod subscription to the failing and working snapshots. Subscribing a mod (fusion generators, choosen at random) did not change the older snapshot and manually scrubbing the mod/.config/.local/steamapps X4 filetrees and reinstalling did not fix that snapshot. Doing the same to the newer snapshot introduced and removed the "modified" tag as expected. That's pretty conclusive

[CBJ]

Thanks for the update. I'll let people know that they don't need to investigate further.