They could mostly prevent boxing via code if they had the talent - which they very clearly don't. But I think it would be cheaper to just do some Rudy Giuliani stop and frisk on truebox servers. Oh well neither are likely.
The best prevention for boxing is a combination of 3 things, which are also the core principles for preventing hacking in online games: Deter, detect, and prevent.
If you only automatically enforce via code, you're going to have issues with people slipping through the cracks. Having a single failure-prone defense isn't going to stop people.
You need straight-up prevention. This could come in the form of the prevention they currently have with regards to truebox - if it's too easy to bypass, people will do so though. But that could also be used to your advantage.
If someone is 12-boxing from the same network, and on separate PCs per your design, you have an attack vector for potential cheaters to use. Cheaters/hackers simply modify the code that makes you unable to multibox on the same PC, and then you can multibox on the same PC. That is currently going on, by the way.
When people do that, you can take advantage of the fact that players are just looking for the bare minimum entry point - they get in game on a single machine. That single machine has /many/ different ways of determining if it's the same machine. This is where detection comes in.
Detection can come in the form of additional layers of defense on top of the existing 'bare minimum' entry point. You /want/ players to bypass that minimum protection, so that you can detect them bypassing said protection. How, you ask, if the game already is known to most due to MacroQuest 2's intense documentation? Well, MacroQuest is open source. You know the exact functions the MQ2 developers know of. You also may know that MacroQuest developers know of changes to the netcode layer, so you could attach additional detection to existing parts of the netcode layer. MacroQuest's developers are focused on structural changes to individual classes or functions they automatically and programmatically track, not additional functionality added to existing functions in the netcode layer.
For instance, you could have a simple packet that has garbage data in it, such as the PlayerProfile packet on incoming, and add a special size check on the generic packet handler.
Logic could go as follows:
If the packet is less than x size, then call "AnticheatFunction". Else, call normal function.
Due to how the packet handler is optimized, that sort of change could go undetected for months. It would require static analysis of every part of the binary - and if you're an MQ2 developer and there's not an obvious string that says "SendComputerName()" or "GetAdapterAddressInUse()", "GetExternalIPAddress()" or something along those lines, and it obfuscates and loads a string that references a Windows system library, you're going to think nothing of those changes. I'd say a good 80% of the EQ binary is actually known functionality wise, but there's a 20% that just hasn't been touched as it's not relevant to automation.
So if you were to call that hidden code path and send data on behest of the server (whether that request be a manual GM trigger or automated), you could query the machine for specific information that is not normally queried for, and that sort of query wouldn't show up consistently on runtime as it's not a normal part of gameplay.
What that means is if you're a common joe cheater, you're not going to see that level of detection or even think if it being an issue. And those that already know how the game works in assembly would be struggling to figure out what you added, especially if you hid it alongside another refactor - like the optimization passes EQ has been doing. They actually added detection for piggy zone in that update and restricted when the client actually tries to send zoning requests without the server's implicit permission. Requests that fall outside of that scope don't fail, but instead get logged for CSR review.
That brings us to the next part: Deterrence. Daybreak has no obligation to act on a cheater immediately. In the case of most EQ players that use cheats, they're 20+ year customers that would never play again if their main account got banned. And if they get that ban wrong, it looks even worse and could lead to a drastic drop in revenue. They have less incentive to ban 12 accounts financially. However, not acting on cheaters immediately allows them to have manual review and risk assessment performed by a human being behind the scenes.
They may be willing to let someone who has consistently spent money on their subscription, marketplace, and more within the last x months slide where as an account paid for with only Krono get banned. On top of that, having a large sample size of detections allows them to fine-tune and ensure their detections work.
Ban waves are the biggest form of deterrence EQ has. Losing your character in EQ is devastating, especially for folks that rely on their characters farming or selling items or services for Krono, as it directly impacts their enjoyment or personal black market revenue. They may be less willing to spend in the future, they may not even come back at all if 18+ accounts are all suspended. Having the flexibility to determine when you actually ban a player means that you can hide your detection methods, have players speculate, and then it's possible that if you do too many at once, they may be able to triangulate what actually resulted in a ban.
For instance, the very latest banwave was due to MySEQ. They have an existing system which MQNext normally hides its injected modules and processes from. However, most players also run MySEQ alongside that program, and MySEQ was not protected in comparison to MacroQuest. So players that didn't run MacroQuest, but ran MySEQ were hit with 7+ day bans. They simply checked for the process name. It's another way that a clever game developer can punish people that think they're getting away with cheating - most of them aren't the ones developing said cheat, so they use whatever they're given to them and don't think outside the box on what results in a ban.
On top of this, there's still other avenues that aren't the game. The Launchpad collects information about your PC, what accounts you've logged into using it, and associates all accounts on that launcher to your hardware ID. Additionally, the login server sends blanket information about your PC to the loginserver. This actually causes the loginserver to fail in some cases. If you've ever 'timed out' on relogging, it's because the hardware information packet was sent before the password or token information.
That means that if they catch one account cheating, they now have a unique identifier that persists across the entire game world. And if that identifier is used ingame, but not on the launcher or the loginserver (the loginserver screen is it's own isolated module from the eq binary) that becomes a vector in which they can track the timestamps of usage versus the timestamp ingame.
I've actually described several ways above that they could detect multiboxing on the same PC with the existing technology they have. They have to also be willing to do it; games are a business and if you remove your customers too frequently, they will be less willing to spend again on your product. That's why they prefer to suspend. Repeat offenders are rare unless they know they can get away with another offense. I've seen that myself on emu, with Rise of Zek having initially 5% of the active accounts cheating on launch, and by the time the last expansions (Luclin, PoP) hit, that number was just an occasional 1 or 2 person that just started playing.
Striking fear into players works. Right now, people feel like they can get away with multiboxing as there has been no repercussions for doing so. If even a few of them got hit, they'd probably start thinking twice. And especially those who are wary about using cheats to begin with would stop using them. It's statistically what I have found on emu, and I am sure Daybreak has seen similar results, though can't always act as quick as they need a consistent revenue stream for their parent company and their investors.
It's why I stated above that emus are the way to go for enforcing boxing rules consistently - they have no financial obligation to keep you around. They can be ruthless and invasive when it comes to determining you multiboxing, they have no investors or shareholders and operate on their pride of removing undesirable players from their game.
Daybreak can't afford that luxury. I think they're doing the best they can given the parameters and likely agile scheduling they have to work with internally. It's hard running a business in addition to maintaining a game's integrity, but I think they've managed to do extremely well so far.
