Hi everyone,
XIGNCODE3 was taken on for a number of reasons. One of those being cheaters and malignant hackers. Our version is custom built for us and is a work in progress, and we’re trying to improve it.
Please know we’re working on an FAQ for those that may have issues with XIGNCODE3. If you’re having issues, please write in a ticket or if you want to bypass us, write directly to Wellbia!
https://forums.enmasse.com/tera/discussion/comment/247776/#Comment_247776
The custom built part (which is mentioned to be a work in progress) is because it does not install itself in the Windows System folder (the kernel model driver named xhunter1.sys) or into the registry. The supporting software is installed into its own XIGNCODE folder under the TERA directory but the driver component is compiled into the TERA.exe binary. Its implementation as of current is easily bypassed via a Javascript based TERA Proxy module (this proxy utilizes the open source Javascript interpreter called Node.js).
Inevitably, someone did ask the question I would’ve asked; “why implement something that is a work in progress?” The answer to that is actually simple though because I believe the goal is to have XIGNCODE better integrated with the TERA application to where it can no longer be bypassed (this is the weakness with a lot of anti-cheat software which runs externally). If XIGNCODE is better integrated, it can checksum the game files to make sure they haven’t been tampered with and it can also then detect if it is actually running to prevent the current situation where it can be easily bypassed. As for actually detecting the use of the proxy, that is going to be difficult since the proxy alone isn’t very functional and all of the modules are simple Javascript.
Actually detecting the exploitative functionality of some modules still requires backend coding as well as an operating process to deal with information that shows potential exploitive actions (or just coding in the server side checks and validations/reducing client side trust; this part is never a high priority for most Korean MMO’s though because of the fact that they were primarily targeted for deployment in PC bangs and/or relied on the fact that any type of account in South Korea requires a KSSN). Hacking still happens though (as what happened with Overwatch which isn’t good news for those who used exploits on a Battle.net account tied to their real KSSN) but in most non-Blizzard games deployed in Korea, dealing with it is low priority (Blizzard is pushing e-sports so they are going to go after those who have the potential to reduce their revenue generating plans).
Digressing, once (big IF) they (EME) do have that “better” foundation in place, the real objective might be to try and mitigate the most exploitive proxy based modules (with detection of a bypass attempt as an initial one). So that is one of the primary reasons why they are implementing this work in progress since part of the whole thing could be asocial engineering to get those who rely on the proxy (and the use of the more nefarious modules) to get used to the fact that XIGNCODE itself, has been easily bypassed.
On the flipside though, it could also be that I am over reading this where the custom part is simply dialing in on processes that XIGNCODE could detect (it still doesn’t answer why there is an actual change to how XIGNCODE installs under TERA though). I guess time will tell either way.
