Steam: Easy Anti-Cheat does not work under Void

[Cynosphere]

Is this a new report?

Yes

System Info

Void 6.0.15_1 x86_64 AuthenticAMD notuptodate FFFFFFFF

Package(s) Affected

steam-1.0.0.75_2 (theoretical)

Does a report exist for this bug with the project's home (upstream) and/or another distro?

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1368284488 https://github.com/void-linux/void-packages/pull/34902#issuecomment-1255715853 https://github.com/ValveSoftware/Proton/issues/6051

Expected behaviour

Games using Easy Anti-Cheat run fine.

Actual behaviour

Games using Easy Anti-Cheat seem to not initialize Easy Anti-Cheat properly.

Steps to reproduce

VRChat:

1. Launch game through Steam
2. Login if fresh install
3. Be greeted with "Can't Travel" screen explaining Easy Anti-Cheat hasn't been initialized.

Apex Legends:

1. Launch game through Steam
2. Wait to get to the main menu
3. Be greeted with Engine Error message box saying "Easy Anti-Cheat Hash Catalogue not found"

[oreo639]

For comment 2, if you go further, you will see that the issue was that while I was testing with a patched glibc I wasn't using a patched glibc-32bit (hence why it wasn't working).

I tested with Multiversus right now and that works for me.

You can try xbps-install -Sf glibc glibc-32bit to make sure you are using the version from the repos and not an old local build.

(You can use xpkg -L to list which packages are installed locally as opposed to from a repo)

[Cynosphere]

No change, I don't think I ever had a local build of glibc as this install has only existed since October and I've had no reason to touch glibc.

[oreo639]

When did you first run into this issue and was it working for you before the glibc 2.36 update?

[Cynosphere]

November 19th is when I first tried to run a game using EAC, which if I'm correct was before 2.36 and it was not working then either.

[oreo639]

Did you try following cat /usr/share/doc/steam/README.voidlinux?

[Cynosphere]

Already had the needed 32bit packages, none of the troubleshooting steps made any changes.

[oreo639]

Can you join #voidlinux on irc/matrix?

[Cynosphere]

Joined on IRC

[oreo639]

I can confirm that Apex Legends doesn't work. I can also confirm that DT_HASH is present in glibc so it shouldn't be related to that. This can be confirmed using: readelf -e /usr/lib/libc.so.6 readelf -e /usr/lib32/libc.so.6 Both have .gnu.hash and .hash.

As a workaround flatpak should work.

[Cynosphere]

I do hope someone does attempt to find the actual cause of the issue instead of leaving it to die on the hill of "just use flatpak".

[oreo639]

You can try using strace -f to see where it exits? (you would probably want to edit the launch script or add it as launch args)

[Cynosphere]

I'm genuinely just tired of being thrown round and round into troubleshooting circles at this point. I don't care anymore.

I'm tired of how the greater FOSS, Linux and whatnot community as a whole treats people that it's infuriating at this point.

It just genuinely comes off as "just use X because we don't want to spend time and effort into fixing Y because Y is proprietary" and its this elitism that annoys me the most.

So whatever. If someone cares to fix this in the future, cool. But I'm not going to sit here just wasting time being thrown in an endless loop of "try this, try this, try this" or "just use this instead".

Sorry I wasted your time, as per usual that it seems to be with me trying to interact with anything on GitHub...

[oreo639]

When running it with proton 6.3: I found logs at $HOME/.local/share/Steam/steamapps/compatdata/1172470/pfx/dosdevices/c:/users/steamuser/AppData/Roaming/EasyAntiCheat It shows the following error Connect result: Couldn't resolve host name (6) Response Code: 0 Destination IP: Unavailable

When using proton experimental: The logs here indicate no error (although the "Easy Anti-Cheat Hash Catalogue not found" error still show up when trying to start the game). There are also logs generated at ~/.cache/com.epicgames.easyanticheat/154 when using proton expiremental which also indicate no error.

I'll see if I can find anything from the strace output.

Edit: I am not getting the hash catalogue error when using strace -f (and EAC isn't working) so maybe it is detecting that?

[Naia-love]

Hello, have same troubles here, on Void too, can't play apex or vrchat, I can play Elden Ring but in offline only. For Apex replacing the EAC dll/so by the one present in the proton EAC runtime make the game goes past the "Easy Anti-Cheat Hash Catalogue not found", launching properly, accessing to the loby and all, but after a while it'll kick you out saying that EAC isn't running.

I also want to report that EAC isn't the only thing acting strange on Void, steamvr is too

(and quick note, yes it do work in flatpak. Thanks for reminding me, i totally forgot steam flatpak existed. But while it's a great workaround, it still suck that it just dont work by default)

[paper42]

reopening because this is not fixed

[Johnnynator]

Actually the issue seems to be the compination of eac and our glibc, did setup a quick chroot and changing the glibc to the one from arch satisfies eac, using the void one doesn't :shrug:

[Naia-love]

what is very strange is that:

• I was using glibc 2.32 until now (which isnt a version of glibc known for troubles with EAC afaik)
• I just upgraded to 2.36, which is known to be problematic but that seems to be patched: https://github.com/void-linux/void-packages/tree/master/srcpkgs/glibc/patches

and that so in both case its broken

[ahesford]

I've read through some of the links on this page and, transitively, an essay at https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash that leaves me wondering:

1. Why we carry a patch attempting to revert the linker change contrary to our usual deference to upstream. They have been aware of this problem for months and are apparently uninterested in the issue or reverting the change.
2. Why this issue isn't closed as WONTFIX with a note that EAC needs to fix its shit. The patch doesn't fix Void-packaged software, it fixes proprietary software fetched optionally by one of our packages. Furthermore, as already noted, there are alternatives like flatpak while people bother the EAC people to fix what broke.

[oreo639]

Why we carry a patch attempting to revert the linker change contrary to our usual deference to upstream. They have been aware of this problem for months and are apparently uninterested in the issue or reverting the change.

I assume you are referring to: https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html

At present I would not make any changes to glibc. I would close bug 29456 as RESOLVED/WONTFIX. I'm open to hearing from the EPIC EAC developers if they have a case to make about DT_HASH.

Carlos later said: https://sourceware.org/pipermail/libc-alpha/2022-September/142353.html

The fix is available in version 1.15.2 of the EOS SDK and in the new corresponding version of the anti-cheat module. This was released in August.

Fixing this issue though requires several steps that need to be taken by the developers of the game itself. ... Looking across the distributions some of them are carrying a revert that adds back DT_HASH. Therefore I think it would help the distributions and add back DT_HASH support for a longer period of time before final removal.

I don't think this will solve all the problems, but I will work to test out the revert on my Fedora system.

Carlos added a temporary revert for DT_HASH in Fedora: https://src.fedoraproject.org/rpms/glibc/c/a9713abfbd4db4350fbc201e4d5cd6ddc36cfd27?branch=f37

[ahesford]

I'm referring to the fact that the upstream issue at https://sourceware.org/bugzilla/show_bug.cgi?id=29456 remains open and unassigned five months after it was reported.

Whether other distributions carry a patch to revert the change is irrelevant here. Void favors upstream decisions and eschews patches unless they are backports of upstream changes or fix issues introduced specifically by our packaging. This is neither. Upstream made a change to drop support for DT_HASH and continues to stand by it. We should be uninterested in fixing this problem until either upstream reverts the patch (in which case we can backport it if we don't want to wait for the next release) or EAC is fixed to support the glibc change (in which case the problem goes away entirely).

This is not our problem to fix.

[ghost]

I'm referring to the fact that the upstream issue at https://sourceware.org/bugzilla/show_bug.cgi?id=29456 remains open and unassigned five months after it was reported.

Whether other distributions carry a patch to revert the change is irrelevant here. Void favors upstream decisions and eschews patches unless they are backports of upstream changes or fix issues introduced specifically by our packaging. This is neither. Upstream made a change to drop support for DT_HASH and continues to stand by it. We should be uninterested in fixing this problem until either upstream reverts the patch (in which case we can backport it if we don't want to wait for the next release) or EAC is fixed to support the glibc change (in which case the problem goes away entirely).

This is not our problem to fix.

This issue isn't caused because support for DT_HASH was dropped though; as other comments indicate, Easy Anti Cheat has been broken on Void since at least glibc 2.32. After all, the current glibc package does contain this patch and yet EAC is still broken. IOW, discussion about this patch is off-topic and would be better suited in a separate issue IMO.

I'm posting this mainly because as a user your comment (being the last one in the chain) made me think that the issue is related to the glibc 2.36 update, when it isn't actually. This discouraged me from attempting to troubleshoot it on my own, which seems counter-productive to me (although admittedly I didn't get very far when I did try troubleshooting on my own). This is significant, as currently Void is the only distribution I am aware of in which EAC is broken despite the aforementioned patch being applied.

In any case, I would very much like to see this issue fixed, and I would be glad to help with any testing (I own Elden Ring and Fall Guys on Steam, both of which use EAC unfortunately).

BTW, I don't use the Steam Flatpak since I also use Steam as a launcher for emulated games - setting this up is very complicated with the Flatpak version (Flatpak in general is way too complicated IMO, so I'd prefer to avoid it if possible).

[numfin]

How i can install eac supported version of glibc so i can play games?

[Naia-love]

small update on my end, especially about https://github.com/void-linux/void-packages/issues/41388#issuecomment-1369014128 steamvr was probably not a void issue, just steamvr breaking up on some specific configuration im guessing. I was able to run just fine last public release, use it with alvr, get in vr, even launch vrchat without any troubles. Tho so vrchat dont run properly because EAC is still broken unfortunately :v (also no steamflatpak its actually complicated as of now for VR, especially on nvidia)

[fanyx]

bumping @oreo639

Were you or another member of the Void team able to find any leads on this? I've found the "Hash catalogue not found" error to be present in Dead by Daylight as well. Fall Guys works without any issues though.

[nonchip]

soo i have multiple EAC games, most (if not all; didn't check them all lately) of which don't run (for years now, so pretty sure not DT_HASH related) despite everyone telling me they should, the fact that steamflatpak seems to help some people points at some other library being borked but i'm not sure how to investigate further, please someone tell me if i can help figure this out finally? am happy to do a bunch of tests and provide logs and whathaveya, just no idea where to start (given anticheat stuff is a black box by design) and wish this worked for once :(

[ghost]

While search for information on this issue, i stumble upon this discussion in the Gentoo forum which is marked as solved. https://forums.gentoo.org/viewtopic-p-8703494.html?sid=92410f4f29b13814bbf566faa6d38886#8703494

I've seen that this is a bit older and i don't have enough experience to see if this might help or is relevant at all anymore. I tried to add this patch and build locally but this either didn't work or i just did it wrong.

[nonchip]

@Requion pretty sure that's about the .hash/.gnu.hash sections @oreo639 already ruled out as a potential cause.

[oreo639]

Btw, just I removed the patch since I couldn't figure out how to make EAC work regardless of what flags I used and I am not aware of anything fixed by the DT_HASH patch (since most EAC games don't work with Void's glibc regardless. Feel free to let me know if there are breakages after upgrading glibc, e.g. worked before updating but not afterwords).

If you still want to test with DT_HASH enabled you can enable it by copying these two lines before the make call in do_buld() in the glibc template (keep in mind that EAC checks both the 64-bit and 32-bit glibcs): https://src.fedoraproject.org/rpms/glibc/blob/ca9e6ac79501d9ee8eeaf795c5764d8733534910/f/glibc.spec#_1219

Were you or another member of the Void team able to find any leads on this?

Just to clarify, I am just a contributor and not a part of the void-team organization. Also, I couldn't figure out what the issue was, only that it is related to glibc and not some other library (as demonstrated by Johnnynator).

[dexgs]

I have tried intermittently to fix this myself by getting the configure arguments as close to those on Arch and Fedora as possible (as well as numerous other changes) and this hasn't worked.

As Johnnynator said previously, EAC works as expected if you use the build from Arch Linux. There is a problem with Void's build of glibc that is not present on other distributions.

Given that no progress has been made in the year since this issue has been opened, and that those affected stand basically 0 chance of resolving this on their own, is it possible to reach out to knowledgeable glibc maintainers from other distributions to shed some light on this problem?

It's good that users can circumvent this problem using flatpak or another distribution's glibc, but this is far from ideal.

EDIT: in case this goes anywhere, the one interesting thing I found that is not already mentioned is that arch's libc.so.6 has a .gnu_debuglink section while void's does not. void also has a .plt.got section while arch has a .plt.sec section.

[okawo80085]

Well, updating glibc to the recently merged 2.38_2 version that has the fix for EAC to not crash brings it back to life, and it does start now, only issue is that it fails with a network error now x) Which is weird, cuz looking at EAC logs it finishes the download, but the callback throws an error?

[2024.01.01-13.37.29] Download Progress: 90
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] [Connection] Connect result: No error (0) Response Code: 200 Destination IP: 18.244.146.77
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] [EAC Callback] Code: 509. Message: 'Unexpected error. (#1)'.

Not sure if its related to the new glibc update, it did disable cryptography functionality from glibc and instead moved it to libxcrypt , you can find more in the glibc package MR https://github.com/void-linux/void-packages/pull/45501

I wonder if preloading steam with libxcrypt will help it :thinking:

[oreo639]

libxcrypt is specifically for hashing passwords. For most cryptography, openssl is used. It is likely unrelated. Also, afaict libcrypt.so is not used or checked by EAC.

[okawo80085]

Well idk what it doesn't like then, all the links its checking are fine, i can even see in the logs from EAC that it finishes the download it was doing, but it still fails with that error :woman_shrugging:

[HO5DTOAT]

I am getting a similar EAC error when trying to run Brawlhalla. I tried both Steam with Proton experimental as well as Lutris with Ubisoft Connect and got the same error. This started happening after the glibc 2.38 update.

In the EAC logs folder of the game (~/.local/share/Steam/steamapps/compatdata/291550/pfx/drive_c/users/steamuser/AppData/Roaming/EasyAntiCheat/2a5901f5be6545b39f551a92214978d6/e7e719b170b74c18b89ba4f3cccd4fdc/loader.log) , I can see the download success followed by the error message.

[2024.01.08-13.09.03] Download Progress: 99
[2024.01.08-13.09.03] Download Progress: 99
[2024.01.08-13.09.03] Download Progress: 99
[2024.01.08-13.09.03] Download Progress: 100
[2024.01.08-13.09.03] Download Progress: 100
[2024.01.08-13.09.03] Download Progress: 100
[2024.01.08-13.09.03] Download Progress: 100
[2024.01.08-13.09.03] [Connection] Connect result: No error (0) Response Code: 200 Destination IP: 18.66.57.4
[2024.01.08-13.09.03] Download Progress: 100
[2024.01.08-13.09.03] [EAC Callback] Code: 507. Message: 'Failed to load the anti-cheat module.'.

In my system which has the glibc 2.38. I can see only the .gnu.hash entries.

Checking the commit history for glibc. it seems the patch that enabled DT_HASH is not present in the 2.38 commit https://github.com/void-linux/void-packages/commit/ee93adc0af49c8f3825dff7e3c6c7dbc40ef4b70. Could that be causing the issue again?

[oreo639]

Thank you, I can confirm that Brawlhalla does work on glibc with DT_HASH enabled (including ranked). If you don't want to play ranked mode, there is also -noeac.

[oreo639]

EDIT: in case this goes anywhere, the one interesting thing I found that is not already mentioned is that arch's libc.so.6 has a .gnu_debuglink section while void's does not. void also has a .plt.got section while arch has a .plt.sec section.

I compiled a glibc in xbps with the same sections as Arch Linux (same flags and same stripping) and it still errors. Verified using diff -rup <(readelf -S libc.so.6 | grep "\[[0-9]*\]" | sed -r 's/([^.]*)(\.[^ ]*)(.*)/echo "\2"/ge') <(readelf -S /usr/lib/libc.so.6 | grep "\[[0-9]*\]" | sed -r 's/([^.]*)(\.[^ ]*)(.*)/echo "\2"/ge').

I tested further using bwrap and overlayfs, and launching steam using Arch Linux's libc.so.6 (nothing else seemed to affect anything) does allow EAC games to work (with .hash in the system glibc ofc) even when swapping the libc.so.6 with the system one before launching the game. I am still not sure what the error is.

[Sapein]

That is...exceedingly weird. The only thing I can think of is there's some weird difference that's unrelated to the sections that is either incidentally environmental or is expected that Void doesn't have...not sure how you would go about solving that though tbqh...

[okawo80085]

Maybe lets try take flatpak's glibc and run and compare it to upstream glibc? Cuz like if on flatpak steam EAC works fine, lets check what they are doing different compared to our environments

[dexgs]

That is...exceedingly weird. The only thing I can think of is there's some weird difference that's unrelated to the sections that is either incidentally environmental or is expected that Void doesn't have...not sure how you would go about solving that though tbqh...

It's something caused by the glibc binary itself. As discussed previously, if you swap out glibc with the files from arch linux, EAC works as expected

[nonchip]

@dexgs are we sure on that though? definitely not how i'd read @oreo639's last comment (or literally any of the others trying to compare/replace those) with the "verified that i built it the same and it doesn't work", and all @Johnnynator said was they "set up a chroot" without details as to what was setup how, and those usually contain more than just a single libc.

and we've already proven it's unrelated to the existence or absence or naming or format of DT_HASH sections, the thing everyone keeps blaming here for no reason whatsoever.

i'm not saying it can't be the glibc, but all the experimentation say it definitely can't be (only) DT_HASH, and it most likely isn't anything else "meta" about it. so short of EAC parsing opcodes in glibc like some weirdo antivirus thing and shitting itself because we ran an optimizer slightly different or such (though on second thought, i wouldn't put it 100% past them), it sounds more likely to be at least not glibc's fault alone.

[fanyx]

Do any signs point to anything other than glibc? It does get more and more nebulous now that people have tested newly compiled, other distro's, sandboxed, etc. libc's

[uniboi]

I was able to work around the issue before glibc 2.37 was availabe via xbps by compiling the glibc version I needed and running steam like this LD_LIBRARY_PATH=/opt/glibc-2.37-32bit/lib steam. Today I finally updated glibc to 2.38 with xbps-install but I still get the Hash Catalogue not found error for EAC games. My workaround stopped working too, the steam UI now segfaults lol.

I just tried the workaround again with glibc 2.38, the steam UI now works but I still get the hash catalogue error.

I compiled glibc like this for 2.37 and 2.38

git clone https://sourceware.org/git/glibc.git
mkdir glibc/build
cd glibc/build
../configure --prefix=/opt/glibc-2.38-32bit --enable-multi-arch --host=$LFS_TGT32
make -j4
sudo make install

The workaround still works with a new compiled copy of glibc 2.38, I just misspelled the environment variable before.

[dexgs]

@dexgs are we sure on that though?

Yes, I managed to get EAC to work by taking the ld-linux-x86-64.so.2 and libc.so.6 binaries from Arch Linux and putting them into /usr/lib

I don't recommend doing this because it is very easy to break your install this way, but it confirms that it is specifically Void's glibc binaries which cause the problem.

[nonchip]

ld-linux-x86-64.so.2 and libc.so.6

...isn't a full glibc install, so that's interesting to know... do you want to maybe elaborate on the reasoning / your findings picking those two? we got multiple conflicting findings about "arch's glibc" (and nothing as to how that even differs from ours), one person claiming that simply compiling with pretty much default options (including a "not misspelled variable" that literally does not exist in any void setup i've ever seen) fixes everything after another says that compiling with the options arch itself uses doesn't fix anything. and now you're answering "can we be sure it's that exact issue with that exact file" with "yeah totally because i replaced 2 files and it works now", that honestly doesn't sound like it answers much :P

[dexgs]

No, sorry. I picked those two after asking @Johnnynator what he did, maybe he can explain why in more detail.

You're right that maybe the problem is caused by ld-linux but from what I remember, the system won't boot if the loader doesn't match libc.so, so there's no easy way to test "just" libc.so. I could be wrong, but I'm pretty sure this is the minimum files that can be taken from Arch while still having a bootable system.

My point about it being fixed with "just" the 2 files from Arch is that it demonstrates that the problem is not some environmental difference between Void and other distros, it is specifically an issue with Void's build of glibc.

As per the conflicting reports, I think one person is saying that they modified the xbps template to match Arch's build options as closely as possible while the other is saying they did a build of glibc without creating an xbps package.

Based on this, it seems like maybe the problem is caused by some automatic step in xbps (some symbol gets stripped which shouldn't, or something like that).

[classabbyamp]

https://github.com/void-linux/void-packages/commit/f36d21c5a25e24a15a740b83f0847956a1c1b146

[nonchip]

@classabbyamp https://github.com/void-linux/void-packages/issues/41388#issuecomment-1368376502 https://github.com/void-linux/void-packages/issues/41388#issuecomment-1369199300 https://github.com/void-linux/void-packages/issues/41388#issuecomment-1869486831

[nonchip]

#freeDtHash!

(sorry couldn't resist) essentially everyone including valve and the concept of linearish time are confirming that DT_HASH-related changes are not (or at least not the only thing) to blame for our problems. sure it might have made things "worse", but EAC did not work even before anyone even thought about that change, and does not work after undoing it with a patch, so we know for sure that we have another problem causing this issue.

Arch / Void differences

i just got an arch glibc (2.38-7 pacman) to compare to ours (2.38_4 xbps), so i'mma just post some findings of differences here, slowly growing this post as i figure out what to look for.

file output

ARCH libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /usr/lib/ld-linux-x86-64.so.2, BuildID[sha1]=8bfe03f6bf9b6a6e2591babd0bbc266837d8f658, for GNU/Linux 4.4.0, stripped
VOID libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /usr/lib64/ld-linux-x86-64.so.2, BuildID[sha1]=155f1ec9aea8bbf8c097651b576a018cbad543bf, for GNU/Linux 3.2.0, with debug_info, not stripped

ARCH ld-linux-x86-64.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), static-pie linked, BuildID[sha1]=6ebd6e95dffa2afcbdaf7b7c91103b23ecf2b012, stripped
VOID ld-linux-x86-64.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), static-pie linked, BuildID[sha1]=ae38d2f30121831555e199be378007e7f05bcd78, with debug_info, not stripped

section differences

(command from @oreo639 above)

--- ARCH
+++ VOID

@@ LIBC @@

-.gnu.version_r
-.plt.sec
+.plt.got
-.stapsdt.base
-.note.stapsdt
-.gnu_debuglink
+.debug_aranges
+.debug_info
+.debug_abbrev
+.debug_line
+.debug_str
+.debug_line_str
+.debug_loclists
+.debug_rnglists
+.symtab
+.strtab

@@ LD-LINUX @@

-.relr.dyn
-.stapsdt.base
-.note.stapsdt
-.gnu_debuglink
+.debug_aranges
+.debug_info
+.debug_abbrev
+.debug_line
+.debug_str
+.debug_line_str
+.debug_loclists
+.debug_rnglists
+.symtab
+.strtab

"red objects"

since i have no idea which of those are flags and which are herrings, here are some things i'm noticing so far:

• we're missing .gnu.version_r, which "shall contain required symbol version definitions" according to LSB
• there's conflicting reports (in different games, so might not actually conflict) whether our version worked before 2.36

and: look down, smarter people than me are contributing to this list, but i try to keep this updated as we figure things out here :)

---

entropy graphs:

arch:

void:

[nekopsykose]

-.plt.sec
+.plt.got

the former is from -fcf-protection (iirc). arch has that in default cflags. probably doesn't matter, but you can rebuild passing that and see

-.stapsdt.base
-.note.stapsdt

this is --enable-systemtap and also probably doesn't matter

-.gnu_debuglink

this is for split debuginfo (here it's not split)

-.gnu.version_r

this is a symver thing. might matter, but this one is optional https://maskray.me/blog/2020-11-26-all-about-symbol-versioning

-.relr.dyn

this is ldflags -Wl,-z,pack-relative-relocs which arch now enables and most likely makes no difference (very recent from arch side)

overall it might not be related to those at all

[oreo639]

I already tested those: https://github.com/void-linux/void-packages/issues/41388#issuecomment-1884242338

Also, the:

-.plt.sec
+.plt.got

has to do with Arch using -fno-plt.

Also when I say "launching steam using Arch Linux's libc.so.6" I just meant libc.so.6, I was using bubblewrap with an overlayfs script and swapping the libc after launching steam didn't affect anything until restarting steam as opposed to the .hash checks which are performed when launching the game.

[nonchip]

@nekopsykose thanks for your insight, my current best bet is on .gnu.version_r if i had to pick one, because it's very much not optional according to LSB (the way i understand the blogpost you linked to it's optional for "a libc" to have+support it, but glibc seems to usually have and its linker does support it) so there's a decent chance a "reasonable person" (and even an unreasonable malwareanticheat developer) might expect it. but like you say it might well not be any section difference, i just wanted to list them "for the record". i could just as likely see EAC accidentally triggering on some weird optimizer difference resulting in "suspicious" codegen or such :'D

@oreo639 i know you already did some tests, but you didn't show the details, and a lot of various quality levels of info are around on the googles about this topic, so i figured it doesn't hurt to start collecting some "hard facts" from some known good/bad samples, to make sure we're on a similar page to rule out or home in on the potential causes. (also offtopic but gotta love that "no-plt" means "use a different kind of plt")

swapping the libc after launching steam didn't affect anything until restarting steam as opposed to the .hash checks which are performed when launching the game.

wait, am i reading that wrong or does that mean EAC does something to the libc linking steam itself instead of the game?