TFAR Code Execution

Everyone who has played Arma for an extended period has come across TFAR, Task Force Arrowhead Radio. I am not going to go into how the mod works, you can check it out here.

I am going to dive directly into the code that drives TFAR, and do my best at explaining a type of lazy eval code execution that is much more complex than the previous exploit I covered. If you do not know what Lazy Evaluation is, I recommend reading that previous post to get a grasp on this style of exploit. To best explain my logic, I am going to take you down the path of how I figured out this exploit. It’s going to be different than how I normally explain exploits. Hopefully, at the end of this, you’ll understand how the TFAR exploit works, and how I created it from my initial thought.

The way I find exploits is by opening up a mod and looking through all of its scripts for a few identifiers that could point to a vulnerability. This is what I did for TFAR. Opening up the script files, I was looking for any lazy eval exploits. One of the identifiers I use for lazy eval exploits is A and B, where B is a variable. If B is a variable, there is a possibility that I can change the value of it, thus allowing a lazy eval code execution. Very often this identifier leads to a dead end. Either the variable is hard-coded or I cannot manipulate it. While looking at TFAR’s files, I came across fn_onLRTangentReleasedHack.sqf which contains 3 instances of this identifier. Let me show you the code.

Here we can see the following identifiers:

  • (_scancode == SHIFTL) and (_mods select 0)
  • (_scancode == CTRLL) and (_mods select 1)
  • (_scancode == ALTL) and (_mods select 2)

What this is telling me is that, if I can change the value of _mods, I can execute code through any of these fields. My next step is to figure out what SQF code determines the value of these fields.

Pages: 1 2 3 4 5


    Leave a Reply