Unlocking ACMI Recordings

[Case]

Tacview 0.94 has the ability to open ACMI recordings even when LockOn crashed. However, it can now also open ACMI recordings while they are written, which is potentially harmful in multi-player games.

 

To prevent this ability from being exploited, the 51st and 169th Dedicated servers will still allow you to record ACMI recordings, but these will have to be unlocked after the flight in order to be readable by Tacview.

 

Please check this thread on the forums of the 51st PVO Regiment for a program to unlock locked ACMI recordings.

Edited June 18, 2009 by Case

[104th_Crunch]

Again, great work Case. Thanks for your efforts!

[A.S]

LoL..... ok...question...

 

how you LOCK them in first line?

 

(im thinking bout TCL-matches ..etc etc etc)

 

help ? :huh: :smartass:

[Vyrtuoz]

Indeed, since Tacview 0.94 is it possible to open files while the flight is still running. This can be exploited by unscrupulous players who want to know where the enemy is in a network game.

 

However, with minor file manipulation the same was already possible with previous versions of Tacview. And it may become even easier when Tacview will support real-time flight replay over a network!

 

Actually, players have two ways to secure network sessions:

• By preventing flight recording by clients (from Config.lua)
  
• By using 51st tools to lock the recorded file
  

 

I admit that it is a security flaw which must be fixed as possible.

 

So if you can let me know how to lock the file from the server (on this forum or by PM), I may add a similar protection in the next release of Tacview.

[GGTharos]

It's pretty simple; use something to encode the file with a password (any old encoding function will do, it doesn't really have to be cryptographically strong) and then embed the password elsewhere.

 

Alternatively, use a special timestamp to indicate that the tacview has finished recording and refuse to play the file back until that timestamp is found. But that has a loophole also: You could then treat it as a 'broken file' and 'repair' it.

[104th_Crunch]

Vryrtuoz,

Your excellent work you have done with Tacview has been extremely valuable for online play and mp squads training in particular. Having an actual ACMI tool for Lock On is great feature.

 

Your planned implementation of real-time flight over a network sounds like a useful training feature as well, but of course such a feature would mean that tacview would have to be disabled on all multiplayer servers. Perhaps you could arrange it so that the Lock On server would need to enable this real-time feature on the server lua file before any clients could get live updates, else tacview would just write to a file as it does now.

 

Another option may be for servers to continue using the current version of tacview scripting as it works now integrated into the Yoda's LRM. Any new tacview versions that require new script changes would need integrated into LRM and be set to true before it works.

 

Thanks for your work on tacview and your consideration.

Edited June 20, 2009 by Crunch

[Moa]

In my opinion all TacView needs to do is refuse to display frame sequences that are more recent than x minutes ago. The delay should be around 10 minutes or a player will be able to deduce the general area of the opponent. I often fly the A-10 on the 169th server and if fighters know your general area using TacView that is enough for them to overtake and kill you, since they can usually guess which area you're heading to as there are always a finite number of target areas.

 

A delay means you can't view the TacView straight after you exit (which will grate with some), but then it also means you can't look at the TacView as soon as you die and vector your buddies to avenge you (that is, this extra form of cheating is prohibited). In my opnion there is no real need to waste CPU encrypting the file (which also presents problems with manual file recovery if there is disk corruption), a time delay on display is enough.

 

You're never going to stop anyone smart enough to break encryption-lite from getting the realtime TacView anyway, so just do a quick fix and delay playback . You will also need an incompatible change to the TacView format to prevent people from using TacView 0.94 with the data, so that they will have to use a new TacView version that implements the delay.

 

As Crunch said, thanks for all your excellent work on TacView Vyrtuoz (and <51> Case for your decryption tool).

Edited June 20, 2009 by Moa
Added more notes regarding flight areas, fixed typos

[GGTharos]

It most definitely WILL grate with some - like anyone who wants to review their bfm/training match right after it happens. There are far better ways with achieving this goal; and really, overburdening the thing with 'security' features is rather silly.

[Case]

So if you can let me know how to lock the file from the server (on this forum or by PM), I may add a similar protection in the next release of Tacview.

The reason ACMI locking works, is that the Tacview export script is incorporated in Yoda's LRM scripts, forcing the client to execute the server side Tacview routines instead of the client side routines. As far as I see it, the only way for you to incorporate something like this is to also create server side Tacview export scripts, because to me that seems the only way to communicate from the server to the client.

[Vyrtuoz]

That’s the answer I was looking for. Would you like to send me by email your actual server side script(s)?

 

That will help me to develop a clean solution which can be at the same time optionally secure and easy to use during network games and transparent for solo flights.

 

The reason ACMI locking works' date=' is that the Tacview export script is incorporated in Yoda's LRM scripts, forcing the client to execute the server side Tacview routines instead of the client side routines. As far as I see it, the only way for you to incorporate something like this is to also create server side Tacview export scripts, because to me that seems the only way to communicate from the server to the client.[/quote']

[Evgen]

Thank you so much guys .

 

Спасибо .