Broken Linux version, incorrectly checked assertion? --> fix

[Dr. Kun]

Hey guys,
since several weeks, I am getting a strange "Assertion failed: GRHIVendorId != 0" error. I cannot start the game, it crashes after 5 seconds while the music is playing.

I backtraced the issue. After replacing the "jne 0x257e67f" at location 0x0257e65c with "jmp 0x257e67f" (this disables the assertion and assumes that it is OK), I can play normally.


Would be great if this bug could get officially fixed.

Can I play on official servers without getting banned due to my modified binary?

[let the snek alon]

X-post

Originally posted by terorie Аутист:

Originally posted by Teotwawki:

This thread indicates a possible fix for the binary;

https://steamcommunity.com/app/346110/discussions/0/1870623125771630145/



I'd like to see an official fix for Linux, (or even just a response from Wildcard) somewhere.

I have the same 5 seconds loading then crash on Xubuntu, for what it's worth.

Good question regarding the modified binary. You can also open /proc/PID/mem of the process really fast, and patch it externally, that should be able to avoid the ban.

I traced back the exact same thing yesterday. I could get into the main menu, but I would crash after a few seconds on Ubuntu 20.04, NVidia Driver 440. I located three such JNE jumps to patch, all within ~32 bytes of each other. I also tried to patch GRHIVendorId to a few different values, all without success.

The second crash is the infamous "Assertion failed: FCompression::UncompressMemory(", which sometimes occurs on Windows. I can see reports back from 2015. I don't have time to fix that one though.

[let the snek alon]

Are you on Linux, too? If not, then let's wait for the ARK devs to properly fix it.

[韩国把汉语写成母语]

jmp 0x257e67f
Where do you put it?
How to fix it?

['/^^/d']

Originally posted by 韩国爹们汉语像自己国:

jmp 0x257e67f
Where do you put it?
How to fix it?

I assume it's with a HEX editor. Also as the OP stated, that means you modify the binary, and it's unclear whether that will trip the anticheat system on official servers.

[Dr. Kun]

Yes, you change it in a hex editor or some other reverse engineering tool. I use radare2.
The exact address depends on the version of your game. But since one of the last updates botched the version numbers as well, you ADDITIONALLY need the binary version before the update. (=This is very hard to do if you are not familiar with reverse-engineering)

I cannot tell if this will trip the anti cheat measures. Although this modification is entirely harmless and far from being a cheat, the binary has been modified nevertheless.

I was hoping for the devs to fix this, since it seem REALLY to be trivial, hence all this information.

[DW_Taya]

Originally posted by Dr. Kun:

The exact address depends on the version of your game.

explains why i am not understanding your address position, and unfortunately i get this information after i had accidentally wiped my last install.

[let the snek alon]

you can run strings (I think it's UTF32) to find the "Assertion failed: GRHIVendorId != 0" string. Then find references to that string and you should be able to find the JNE.

[Jat]

I wouldn't recommend playing on the Official Network with a modified binary, you'll risk getting flagged by BattlEye. We are looking into Linux/Mac issues atm and hope to have a patch out which resolves the issue as soon as possible.

[DW_Taya]

ok i manged to find it using a few different encodings but what i am not understanding is the JNE JMP part


this is what i see from the wxhexeditor in plain text. using Character Encoding "Windows CP1250"
in ghex offset is 0x49F745F thats the start of GRHIVendorId

InFeatureLevel < ARRAY_COUNT(FeatureLevelNames).GRHIVendorId != 0.!IsValidRef(WorkArea.ComputedBSS->BSS) .

[let the snek alon]

Originally posted by DW_Taya:

ok i manged to find it using a few different encodings but what i am not understanding is the JNE JMP part


this is what i see from the wxhexeditor in plain text. using Character Encoding "Windows CP1250"
in ghex offset is 0x49F745F thats the start of GRHIVendorId

InFeatureLevel < ARRAY_COUNT(FeatureLevelNames).GRHIVendorId != 0.!IsValidRef(WorkArea.ComputedBSS->BSS) .

Sorry if this was misleading; a simple hex editor won't get you far. What you are looking at is the strings region, which contains a bunch of text from all over the application crammed together. You would need some reverse engineering framework like radare2 or Ghidra to efficiently locate the jump instruction that leads to the assertion error.

Not to be discouraging, but I think you would end up spending lots of hours getting used to these tools, at least that's how I felt when patching binaries for the first time.

As Jatheish, a developer of the game mentioned, there seems to be a patch in progress. I would recommend waiting for that instead. If you are playing on a server without BattlEye, you can use the Steam Proton Compatibility Layer.
To disable BattlEye on your own server you can add the flag -NoBattlEye to the launch options. Finally, for singleplayer, Proton should work without any issues.

[NoMic]

Originally posted by Jatheish:

I wouldn't recommend playing on the Official Network with a modified binary, you'll risk getting flagged by BattlEye. We are looking into Linux/Mac issues atm and hope to have a patch out which resolves the issue as soon as possible.

I tried to report this error in a support ticket on survivetheark.com, both times support was completely useless and said the error was on my end and that I should get a computer specialist to look at my PC and they never mentioned that they forwarded the crash info to the Dev team.

The survivetheark.com tech support staff is completely useless if they won't at least forward the crash info.

[NightStormWolf]

Originally posted by Jatheish:

I wouldn't recommend playing on the Official Network with a modified binary, you'll risk getting flagged by BattlEye. We are looking into Linux/Mac issues atm and hope to have a patch out which resolves the issue as soon as possible.

Its been over a month without this being acknowledged or looked into. I too have reported this to the support system with no success of getting it resolved. You and the rest of the dev team need to start taking these problems seriously. We are paying customers just like everyone else and you guys/gals constantly blow up our clients and leave them in a non-working state for weeks or months at a time. It's not acceptable!

[let the snek alon]

lmao rip i guess

[Oddstr13]

Originally posted by Jatheish:

I wouldn't recommend playing on the Official Network with a modified binary, you'll risk getting flagged by BattlEye. We are looking into Linux/Mac issues atm and hope to have a patch out which resolves the issue as soon as possible.

Could be related to this?
https://answers.unrealengine.com/questions/725849/view.html

[let the snek alon]

Originally posted by Oddstr13:

Originally posted by Jatheish:

I wouldn't recommend playing on the Official Network with a modified binary, you'll risk getting flagged by BattlEye. We are looking into Linux/Mac issues atm and hope to have a patch out which resolves the issue as soon as possible.

Could be related to this?
https://answers.unrealengine.com/questions/725849/view.html

Yes it is related. That's precisely the integer that causes the assertion to fail. Know we just need to find the handle of an Ark dev to bypass community managers / marketing and get the word straight to the developers.