Game piracy is a real problem for independent game developers, especially on platforms like Android and Linux where reverse engineering games is quite easy.
To counter this, a simple method of using OpenGL to encrypt the assets such as images and data can be done by using the graphics card or GPU for performing the encryption/decryption work completely on the GPU, by using native OpenGL calls. This uses the already established General Purpose GPU (GPGPU) computing methodology to accomplish this task. A description of a proof-of-concept is available at Stealth Labs blog and the source code is available at github.
From stealthy.io:
Suppose you are an independent game developer. You are facing piracy and fake copies of your game, and you do not have the legal and economic power to handle this problem. You want to continue making games without getting discouraged by pirates, who most likely reside in other countries. What do you do ? How do you prevent or reduce the incentive to pirate your game through reverse engineering ? Maybe you could perform encryption of your game assets, like textures, shaders and images, to thwart the piracy and copy-cat efforts ? You could use standard encryption libraries like OpenSSL, but that still leaves the decrypted data open to access, in CPU memory, by anyone running a debugger on your software. What if you could use OpenGL to do the encryption and leave the data in the framebuffer object and render it from there using OpenGL itself ? Then you would never have to even extract the data from GPU memory into CPU memory ! Debugging tools for OpenGL are not good enough, and reverse engineering tools for OpenGL are non-existent.
Original Submission
(Score: 5, Interesting) by ikanreed on Friday June 05 2015, @07:25PM
I wouldn't go that far. Tools exist to take dumps of VRAM. They're cagey and prone to synchronization issues, require kernel level driver access, and other things.
But none of that is going to stop you if you're the kinda person who sees copyright protection schemes as a challenge.
Not as black box as they're pretending. But also not as white box as RAM. Either way, I hate it, because DRM.
(Score: 3, Insightful) by arulatas on Friday June 05 2015, @07:26PM
-Yet
----- 10 turns around
(Score: 0) by Anonymous Coward on Friday June 05 2015, @08:08PM
That is a spot on observation.
On top of this it smells of security thru obscurity. This assumes no one can write an emulator or walk the code manually.
There are vids of people out there reverse enginering blu-ray external USB drives. I seriously doubt doing something in the framebuffer (which is easily accessible thru opengl calls...) is all that secure.
(Score: 2) by VortexCortex on Saturday June 06 2015, @09:13PM
Software only MESA / OGLES reference drivers = debug tool to dump decrypted assets.
Probably most who rip-off games wouldn't know how to use them, but it's kind of incorrect to say no tools exist. In fact, there are many perf tools for hooking into OGL, and some even can fetch texture data. So, it's not a question of if but when "pirates" will use those tools, and "yet" has already happened.
What's more interesting to me is the ridiculousness of trying to save the economically untenable practice of artificial scarcity via security theater. Data in the Age of Information is infinitely reproducible. If the copies are in infinite supply, Econ101 says their price should be Zero regardless of cost to create. For instance: Sand is cheap on this planet even though it was forged in an expensive supernovae. The 1's and 0's are not scarce, so monetize what is: The skill and capability required to make new arrangements of bits. If you don't release your work until it's been paid for in full, then you don't need to leverage artificial scarcity, and piracy disappears into free advertising and hardcore modders / fans. Just forget about "Intellectual Property" and monetize skilled labor: Make a payment arrangement up front, do the work (make the game/app), get paid, do more work to make more money. This is proven to work as it's how any labor industry operates. With crowd-funding I can ask for as much as I need to fund the entire project (+profit) and then give the output away for "free" (since it's already been paid for). This is basically the same as working for a publisher, except I cut out the middle man by working directly for the consumers, get free advertising and market research (not funded = saved time), and since publishers spend 3-5 times the dev budget on ads I can ask to earn 2x what I would under a publisher and still deliver the game/app to the public cheaper than a publisher does. Bonus: No "pirate" can hurt my sales since I've already been paid.
All this insanity over "Piracy" is just propping up the bogus artificial scarcity model that no other market besides "Intellectual Property" leverages. Use the same work method that home builders, mechanics, FOSS devs, and etc. laborers do and in the time I save by not screwing with DRM I can add more content / value to the game (and extract more pay since time is money).
(Score: 0) by Anonymous Coward on Friday June 05 2015, @07:27PM
(Score: 2) by jimshatt on Friday June 05 2015, @07:33PM
(Score: 4, Informative) by middlemen on Friday June 05 2015, @07:41PM
Android has most apps using Dalvik bytecode: androguard, dex2jar, dare are some of the decompilers that can literally decompile all your Android apps at the price point of $0. Refer Android Hacker's Handbook [wiley.com].
Linux has radare [radare.org] and many other in-built tools to ease reverse engineering at the price point of $0.
In contrast, Windows requires you to purchase something like IDA Pro [hex-rays.com] which costs about $2500 or more per license.
And iOS has iOS Hacker's Handbook [wiley.com] which also requires IDA Pro, an iPhone, a Mac and various other tools including being able to jailbreak the iPhone.
Compared to Windows/iOS, reverse engineering on Linux especially on Android is a walk in the park.
(Score: 0) by Anonymous Coward on Friday June 05 2015, @08:25PM
Radar works on Windows, Mac OS too
(Score: 3, Informative) by Anonymous Coward on Friday June 05 2015, @09:44PM
In contrast, Windows requires you to purchase something like IDA Pro [hex-rays.com] which costs about $2500 or more per license.
And that would stop people who make it their bussiness to remove copy protection... how exactly? You can find IDA Pro on TPB or your favorite hive of scum and villainy of choice.
And it's not as if there aren't free serviceable alternatives [ollydbg.de].
(Score: 1, Informative) by Anonymous Coward on Saturday June 06 2015, @05:24AM
OllyDbg, while nice, has nowhere near the functionality of IDA Pro. Nothing does, period. Honestly most people pirate it, and the people who are not willing to do that use the IDA free version.
(Score: 0) by Anonymous Coward on Sunday June 07 2015, @04:43PM
[....]"In contrast, Windows requires you to purchase something like IDA Pro [hex-rays.com] which costs about $2500 or more per license."[....]
because pirates are well known to maintain their paid licenses for reverse engineering software ┌∩┐(ಠ͜ʖಠ)┌∩┐
https://thepiratebay.se/search/ida%20pro/ [thepiratebay.se]
(Score: 3, Insightful) by Anonymous Coward on Friday June 05 2015, @07:34PM
This looks like a great way to write GPU resident malware that poses as a nice game for the users. Brilliant !
(Score: 2) by DECbot on Friday June 05 2015, @09:54PM
Damn you Minecraft! Your clever trickery not only steals all my time and PC resources, but also participates in a malignant botnet army!
cats~$ sudo chown -R us /home/base
(Score: 0) by Anonymous Coward on Saturday June 06 2015, @06:07AM
Indeed. If you're going to abuse your client like this, you could at least do something useful, like mine some bitcoins...
(Score: 3, Informative) by gnuman on Friday June 05 2015, @07:35PM
Game piracy is a real problem for independent game developers, especially on platforms like Android and Linux where reverse engineering games is quite easy.
CITATION NEEDED.
Furthermore, why do they think it is easier to reverse engineer on Linux as opposed to Windows? Sorry, but this doesn't pass smell test.
To counter this, a simple method of using OpenGL to encrypt the assets such as images and data can be done by using the graphics card or GPU for performing the encryption/decryption work completely on the GPU, by using native OpenGL calls.
I think maybe someone doesn't know of proper tools. Considering you can catch every single OpenGL function call along with its parameters, and emulate it, what is the point here? There are tools that will literally capture and replay OpenGL scenes, forwards, backwards and any which way so you can find bugs.
(Score: 0) by Anonymous Coward on Friday June 05 2015, @07:57PM
It is easier in two respects.
First is the obvious s/easier/cheaper/ Super-powerful tools exist for all platforms, but Linux, by the nature of the people who use it, has most of them available for free. Windows not so much, at least for well known ones (and maybe the scene has secret ones or can otherwise get around licensing for the expensive ones).
Second is that with open source software and the like, it is easier to patch the kernel or otherwise know what is going on. Also, I believe that android uses some sort of intermediate bytecode, which requires even less work with common tools than to disassemble a compiled program.
(Score: 0) by Anonymous Coward on Saturday June 06 2015, @01:06AM
But wait, isn't all FOSS simply a reimplementation of something that some hard working programmer or businessman designed, thus ripping off money from a working person? /sarcasm
(Score: 4, Interesting) by Hairyfeet on Friday June 05 2015, @11:33PM
Not to mention, at least from what I've seen, the indie devs aren't being "reverse engineered" they are being plain old knocked off. Hell look at companies like Zinga or King.com who have made fortunes literally just ripping off wholesale the designs of others games, no snatching off actual code is required.
Its the same thing we PC gamers have been seeing for awhile, Jim Sterling on YouTube practically has his channel dedicated to ripoffs and for every "war-z/day-z" ripoff you hear of there are a dozen that you don't. They have rip offs of everything from Minecraft to Tomb Raider and again no code stealing required, you merely have to make the name and the screencaps look enough like the original to fool the uneducated user just like mockbusters.
But I have to say as the "token Windows guy" that I am shocked, shocked I tell you! that nobody is bringing up the trend of FOSS projects embracing DRM? You have Valve building a DRM platform (SteamOS) on Linux, you have Firefox adding H.264 DRM, and now you have this, which if it keeps the user from doing what they want with their software? Well I don't think I really need to get a ruling from RMS, its DRM. Of course we Windows users really don't care as long as we get something good out of the deal, hence why Steam is so popular on Windows and why EA has been giving away games on Origin just to get users, but you would think the Linux faithful would scream bloody murder, so what gives?
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 2, Touché) by Anonymous Coward on Saturday June 06 2015, @05:36PM
Except that none of the projects you mention is by the "Linux faithful". Valve is hardly a FOSS project. And this is just a silly poc. One example doesn't make much much of trend.
(Score: 5, Insightful) by Tork on Friday June 05 2015, @07:44PM
Game piracy is a real problem for independent game developers, especially on platforms like Android and Linux where reverse engineering games is quite easy.
Is it a real problem in the sense that you see your revenue go down after the pirated version is available, or is it a problem because you see people who have played it and haven't paid for it? If it's the latter, then don't spend any resources on this. Spend your time making the game fun. When people have fun they pay. Seriously. Now you may not believe me, and that's okay, but please consider this: Every complication you add brings the potential for tech support down the road. Every second you spend responding to an email or fixing a bug is your profit margins shrinking. This is why I do not understand why companies like EA try to control activation of games. They're paying staff at their call centers long after the software purchase has been made. Dumb, just dumb. Every time somebody has to make that call the less likely they are to purchase a new game down the road.
I'm not just talking to you from the point of view of a consumer, but also as someone who has has been on your side of the fence. A few years ago I partnered with somebody to create some software that we later sold on-line. He was desperately worried that everybody was out to get our product for free. Since it cost over $150, I sort of understand his anxiety. But I started thinking about what it'd take to actually 'protect' this software from unauthorized use and I just felt like I was going to create several land-mines that would require tons of tech support. Worse, I've used software that was too restrictive and ended up just finding ways to not need it. I stood my ground on that and he reluctantly agreed.
I wrote the software with a fairly modest user-name + serial number unlock system. Sales were good. Eventually a cracked copy was released, but if you looked at our sales charts you wouldn't find where in the cycle that actually happened. And you know what? I had exactly zero bug reports about the unlock system. This was back in 2005, today we're out of business, but every single customer who has purchased our software can still use it. If we ever go back into that again, an idea that we've flirted around with, I believe we'll still have the good will of our customers.
I don't know what to tell you about copy-catters using your assets. But I do want to warn you against stepping over a dollar to pick up a nickel. Basically what you've described means more development time that doesn't go towards making your customers happy. It's not worth it.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 1, Informative) by Anonymous Coward on Friday June 05 2015, @07:48PM
You can encode/encrypt/translate a book into something unreadable, that does not prevent it from being copied by a photocopier.
What a lot have done is to put more parts of the game online. That makes it a lot harder to copy.
Reverse engineering is what pirates do when they're trying to disable the checks. That works if most of the game is not online. Doesn't work so well if the game world, calculations etc is mostly done by the servers.
(Score: 2) by Jesus_666 on Saturday June 06 2015, @08:35PM
On the other hand, putting parts of the game online is a great way to burn customer goodwill. Look at the Sim City disaster: Nobody could play the game at launch day because the servers buckled under the stress and everybody knows that at some point EA will shut down the servers and any non-cracked version of the game will stop working. Heck, not having Sim City's copy protection scheme was used as a selling point by the competition.
People hate always-on DRM. Especially those who can't be online all the time. Think of mobile gamers: Not only does being online drain the battery faster, constant traffic might also cost some non-trivial money if they don't have an unlimited data plan. Plus, you're just one dead spot away from the game kicking you out. Even PC gamers usually don't like it because even "fixed" connections like cable or DSL aren't 100% reliable and neither are your servers. Unfortunately, when the connection drops and takes the single-player game with it, people won't say "oh well, the internet isn't perfect" or "it's not like I have an SLA"; they're going to complain about how wonky your game is and how it randomly kicked them out of a session yet again. And suddenly your game's Steam review score is terrible.
Then there's the server issue. Servers cost money and you'll have to keep paying that money to keep them running – if you dont the game becomes unplayable. Even if you argue that limiting the game's lifetime is good because it means that people have to buy new games regularly, it's still a very transparent move to make people pay more and you will have to pay for it with lost respect. Lose enough respect and people might refuse to do business with you anymore.
For instance, neither I nor my friends won't touch anything from Ubisoft until they've proven that they really, really care about customer satisfaction. Nonsense like shutting down key activation servers without patching the key checks out of the game or completely botching the PC netcode of Splinter Cell: Conviction and never doing anything about it have pissed us off to the point where we'll pass up on otherweise good-looking games if they're from Ubisoft. There's a lot of other games out there and we don't need Ubi.
To sum things up: No matter how nice your game is, you can and will lose customers if you make them angry enough. Always-on DRM has enough moving parts and a sufficiently terrible reputation that it will result in a PR hit. Even though it might prevent piracy of this one game, it does damage to your entire company's reputation. Keep that in mind when you do the cost/benefit check on that plan.
(Score: 2) by meisterister on Friday June 05 2015, @08:04PM
Before either someone develops the OpenGL debugging tools necessary or integrated GPUs become powerful enough that these games will be played on them anyway?
The integrated GPU argument comes from the fact that HSA and other such things are increasingly bringing CPUs and GPUs into the same address space. So much so that I expect that such protections would be as useless as encrypting main memory for such purposes very soon.
(May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
(Score: 5, Insightful) by acharax on Friday June 05 2015, @08:12PM
If it can be decrypted by the client the client can dump it.
(Score: 0) by Anonymous Coward on Saturday June 06 2015, @05:00PM
If it can be decrypted by the client the client can dump it.
Let me guess. You've never written OpenGL code and have no idea how it or a GPU work.
(Score: 0) by Anonymous Coward on Friday June 05 2015, @08:19PM
Wouldn't HSA where CPU and GPU share address space defeat this?
(Not that many folks running Linux would allow copyprotected crap to run on their computers anyway)
(Score: 5, Interesting) by maxwell demon on Friday June 05 2015, @09:18PM
As far as I understand, Mesa has a complete implementation of OpenGL in software. Therefore you could just run the code using Mesa, instructing it not to use OpenGL hardware (or simply on a machine where the necessary drivers for OpenGL hardware are not installed). No need for HSA in that case.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Friday June 05 2015, @09:23PM
Game piracy is a real problem for independent game developers
I stopped reading right there. Using a propaganda term [gnu.org] like "piracy" to describe copyright infringement confuses the issue, and as usual, no data to back up the claim.
(Score: 3, Interesting) by darkfeline on Friday June 05 2015, @11:08PM
I would think piracy affects independent game developers even less than AAA developers. In fact, piracy is probably good for indies who need the kind of exposure that piracy gives them, lacking the multi-million dollar marketing budget of large companies. Players are also more likely to buy indie games to show support for the developers, even if they pirate the game (perhaps to avoid DRM that the short-sighted devs threw on, like this OpenGL thing).
Join the SDF Public Access UNIX System today!
(Score: 2) by maxwell demon on Saturday June 06 2015, @05:54PM
You misunderstand. It's hard for independent game developers to make good games based on piracy themes. And of course the GPU helps rendering those pirate ships. ;-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Insightful) by Anonymous Coward on Friday June 05 2015, @09:55PM
> reverse engineering tools for OpenGL are non-existent
So laughably wrong!
Plus, when a hacker needs a tool... a hacker builds a tool. Oh you meant crackers? I guess they probably do the same thing.
(Score: 4, Insightful) by No.Limit on Friday June 05 2015, @11:15PM
This is just a laughable non-protection.
Not only are there software implementations available for OpenGL (see mesa [mesa3d.org]: "If Mesa can't use its hardware accelerated drivers it falls back on one of its software renderers") that will keep everything on the CPU, but even if it runs on the GPU that's not a protection either.
You can easily record the OpenGL calls (they're executed on the CPU). With these you can get the shader that'll do the decryption. Then you can either port the decryption onto the CPU or you can just simply inject OpenGL calls that'll download the data from the GPU back to the main memory where you'll have all the decrypted data.
(Score: 1) by rleigh on Saturday June 06 2015, @09:24AM
I'm also unsure who this is intended to "protect" against. It certainly seems like snake oil at first glance.
It doesn't help with game "piracy" by end users; they'll just copy the whole thing and it'll decrypt the stuff on the GPU, but the game will still play. Unless there's additional licence key verification or other steps to conditionally allow decryption
The only people I can see it really attempting to stop are other game developers from nabbing the "assets" (textures and meshes) uploaded to the GPU. Frankly, this seems like a waste of time. Legitimate developers are surely going to not engage in such legally questionable activities? And if they did, they are the most technically savvy to circumvent the protection. Is this actually a problem in practice for real life development?
(Score: 0) by Anonymous Coward on Saturday June 06 2015, @05:44PM
They just want to make the lives of modders harder so they don't need to compete against their own old products.
(Score: 2) by acharax on Saturday June 06 2015, @03:08PM
This is a common tendency among game developers, they believe the GPU is a magical contraption that's completely isolated from the CPU. It's easy to observe when it comes to matters of performance where way too much attention is put on the magical domain of GPU hardware acceleration without realizing their game's choking because the single threaded monolith they call an engine can't send data to the GPU fast enough to ever hope of caping it out in the first place.