The game was using Arxan
Arxan is obfuscating JS, right? Obfuscated JS is rated as "2 out of 10" in OP, so it is not that surprising that it is easily broken. Breaking C++ client with lots of inlines and templates (compiled with -O3) will be much more difficult (like "more than an order of magnitude difficult") - and without slowdown too. And - if you want to run it in browser, it is possible too (compiling C++ into JS with emscripten).
In general - you cannot add protection as an afterthought, you need to embed it into your development process from the very beginning.
How do you know about "a tonne of templates" if you didn't see source code?
EDIT: and BTW, how do you know which instructions are "real" ones if you didn't see source code? In a highly_optimized C++, there are tons of jumps without any obfuscation ;-). BTW, FWIW - cost of JMP is about 0 these days (there are exceptions to this rule but they're rather rare).
RTTI and experience.
Ahhh, so they used RTTI - a pretty bad mistake on their part. Will need to add "NO RTTI" in big letters to the "no unnecessary info" section ;-). IIRC, it is still not really required.
as in pusha; ...; popa;
Not that much obfuscation if you ask me; should be something else hiding in there...
Mate, I respect your writing and all, but cut the attitude.
:-) Sry, but before your last reply I had doubts whether you're genuine.
And as you're genuine - tell me one thing: how did you get to the entry point of that bdMarketplace? After you identified that point - yes, it is possible to get the code dissected (to get through in an hour you should be really good, but well - it does happen ;-)); however - identifying that entry point is usually quite a problem (and that's where having a monolith comes really handy).
Yes, you usually replace the ... with code that looks like it's doing stuff; making calls, jumping around etc. just to have it undone later.
Sure, but yuck! - and still way too obvious as soon as it becomes known.
I started at the ws2_32::send API...
Oh, I see, thanks! Apparently, the guys were rather obvious there :-(. At the very least - a layer of statically-linked OpenSSL (and encryption is a must-have for other reasons, so it qualifies as an obvious oversight on their part) would probably delay you quite a bit on the way of identifying that create-formatted-payload function (TLS is a state machine, and quite ugly at that, so there is no 1-to-1 correspondence between calls). And, of course, being too obvious about their formats (that prefix stuff) didn't help their case either. Oh, and force-inlining that create-formatted-payload function (or even better - separating formatting into another thread - just for a good measure) would probably cause a yet another delay.
I can't think of any C++ compiler that respects your use of inlining.
When it comes to your use of inlining (simple inline I presume) - sure, but my use of inlining is different ;-)... I'm speaking about MSVC's __forceinline, and GCC's __attribute__((always_inline)) - these are respected (at least most of the time).
But I'm talking about real world use
So do I - just coming from the opposite side from the barricade :-). And I've seen C++ which wasn't really broken in 10+ years of running a 500K+player game - so well, I'm trying to figure out what was so different about it.
It's a fortune 500 company and a billion dollar franchise managed by three studios, I can assure you that they know how to use TLS.
I've seen more than one fortune 500 company which have absolutely no clue exactly about these things ;-) - including not-checking-server-cert-on-client :-( . Heck, I even happened to work for IBM at some point - so I know these things VERY first-hand. Oh, and BTW mate - if trying to see who can put longer company on the table - that unbroken-C++-above belongs to the multi-billion company, so it should also count for something ;-).
and you come off as "I googled 'security' and read a few blogs on how to slow down RE, now to apply everything to everything for best results ::))"
Well, there was at least one blog which you apparently didn't read - the one about __forceinline ;-).
EDIT: BTW, OP is certainly not meant as a "comprehensive guide on 'how to prevent RE in games'". This will come in Vol. 3 - and will take a separate large Chapter (with honey pots and protection from MITM-on-yourself attacks, with how-to-write-ToC and outlier detection, with known-attackers-scanning and forced-inlines, etc. etc. etc.) Here it was indeed a very simplistic "obfuscation 101" - but you won't believe how many companies out there ignore even these simple rules (just two most obvious examples: (a) @GDC16 DaysZ admitted that just recently started to encrypt traffic(!); (b) I can't even count number of games which are using openssl.dll).
This site is extremely bizarre. Who quotes themself? And adds bizarre bunny images next to the quotes?
This site is linked to fairly frequently and seems to be pretty well-regarded; and quoting article text as image captions is hardly unique.
quoting article text as image captions is hardly unique
Moreover, it is so well-known that it got its own name and article in Wikipedia: https://en.wikipedia.org/wiki/Pull_quote :-)
If this is the worst complaint about the article - that's good :-)
I suspect this is just the web version of what will eventually become a printed book.
"I quote myself all the time" - Myself
Compiling Emscripten to asm.js or Java/C# to optimized native code ahead-of-time can give you the best of both worlds - no slowdown (or even speedup) and a reverse engineering difficulty boost. A really paranoid JVM/.NET application vendor can also obfuscate names and encrypt resources prior to AOT compilation, and apply a code virtualization tool to the most sensitive parts of the resulting native binary.