Please add documentation

[clefru]

Can you clarify, where your superhexagon.x84_64 binary comes from? I presume that it comes from Steam. I applied the bspatch file to my copy of the game and looked at the diffoscope output. It produces bad assembler. E.g.:

│ @@ -202716,17 +202726,19 @@
│       xor    %eax,%eax
│       jmp    4da0e5 <getPixelColorRGBA8(unsigned char*, unsigned char*, unsigned char*, unsigned char*, unsigned char const*, unsigned long, LodePNGColorMode const*, unsigned int)+0xc5>
│       movzbl (%r8,%rax,1),%edx
│       mov    %dl,(%rdi)
│       movzbl 0x1(%r8,%rax,1),%edx
│       mov    %dl,(%rsi)
│       movzbl 0x2(%r8,%rax,1),%eax
│ -     mov    %al,0x0(%rbp)
│ -     mov    0x18(%r12),%r8d
│ -     test   %r8d,%r8d
│ +     mov    %dh,%ch
│ +     adc    (%rcx),%bh
│ +     mov    -0x37(%rsp,%riz,4),%eax
│ +     (bad)  
│ +     test   %al,%al

(bad) is already an indication that something went sideways, and additionally, the new instructions don't make much sense to me. So I presume that I have the wrong binary. It would be nice, if you can add a source and a sha256sum for the binary.

Also please note that Super Hexagon recently updated and removed superhexagon.x64_64, see https://steamdb.info/depot/221643/. I pulled my copy from an older backup snapshot, but for the general public, I think that superhexagon.x64_64 can't be found any longer.

Also I have trouble understanding your hooking method. (Maybe because I don't see what your bspatch actually does). You seem to rely on overloading __stack_chk_fail. How do you trigger the stack check fail method? Wouldn't it be cleaner to override a few symbols from inside the game itself?

Also would you care to explain what:

typedef void ofSetWindowShape_t(int, int);
ofSetWindowShape_t* ofSetWindowShape = (ofSetWindowShape_t*)0x004dba70;

is about? You seem to set a raw address to the ofSetWindowShape function. But this address is way too short. That seems to just be an offset. But an offset into what? What's the base address for this offset? Does this get relocated by the linker? But I can't see a relocation instruction anywhere.. so I am not sure if that theory is correct.

Pardon my many questions. I have never seen application hijacking done this way and I am quite interested in how you achieve it.

Thank you in advance!

[gabcoh]

Hi, it's been a while since I've looked at this code, but I'll try to get around to investigating your questions when I get a chance (not sure when that'll be though).

Regarding where my superhexagon binary comes from I believe I got it from the superhexagon website. If they recently updated the binary then my patch likely won't work.

[gabcoh]

I know it's been a while since you asked, but I've just been fiddling with this project again lately and I have the answers to your question in case you're still interested.

My version of the game does not come from steam. It comes from the humble bundle distribution of the game which is sold at https://superhexagon.com/. The sha256 of the executable (not the bash script launcher) is a27df72e78e8e7b791d213ab3da5b18f38b26c2d3a5dca58c47172bef6278527.

Regarding how I implemented the hooking I did just override the __stack_check_fail function and patch the binary to call that function anywhere I wanted to shim. I couldn't override symbols from within the game using LD_PRELOAD because those symbols are not dynamically linked. My overrided __stack_check_fail function then checks rbp to see which call site it is at so that it can perform the appropriate operation. I believe the address you point out is in fact just a static address, not a relocation or offset.

Hope that answers you're questions. Sorry for such a delayed response.