Subject to protect their games and applications

siddharth93

  • Posts: 125
It is easier to re-engineer games of this size than reverse-engineer. How do you 'decompile' one of these games. I am considering using GameMaker now -_-

Vadim Va

  • Posts: 26
It was just like one of the typical examples of bad behavior thieves your work.
And not the most impressive!
Such cases on Google Market very, very much...
And if that thief Developer Account is more famous than you, he will be able to sell "your" game more successful than you.
Is not it a shame? :(

siddharth93

  • Posts: 125
Ok, I don't mean to make it about stealing (instead of protecting, which this thread is originally about); but how do you extract these resources? or hack into a game?

avvi

  • Posts: 17
It can be a painful experience, to see how someone takes your work, changes graphics and gains the praises for "original idea" :/

Sadly, there is not much you can do about it - because of two things:

1) Just stealing the concept, the mechanics, is often enough. Threes (paid) vs awful clones like Three Saga... which is drawn from scratch, but it's still a copy! For many people it doesn't matter, if the original has voices, beautiful animations. Many players don't care if it HAS A SOUL. They just prefer 'free' instead of paid. Don't worry. They're probably not your clients anyway.

2) Thieves in niche markets are much less common than in the casual, highly competitive mainstream. Great, risky, well-thought game is not that easy to steal. The risk and work to be done, to complete the game, are too high. Simple overnight hits like Thress are much more vulnerable to this problem.

I can't see any candidates to copy Monument Valley  :D Even if someone uses the idea, there are great chances that Valley will remain the best game like that on the market.

Vadim Va

  • Posts: 26
but how do you extract these resources? or hack into a game?
I dont know - i'm not hacker! :)

avvi

  • Posts: 17
but how do you extract these resources? or hack into a game?

It's very easy, really.
Just extract the .apk file (as you would do with a normal .zip file, for example with 7-Zip). Now browse into the folder, find assets and you can copy all the graphics :D

siddharth93

  • Posts: 125
but how do you extract these resources? or hack into a game?

It's very easy, really.
Just extract the .apk file (as you would do with a normal .zip file, for example with 7-Zip). Now browse into the folder, find assets and you can copy all the graphics :D
From all the stackOverflow posts, it is much simpler to do than I thought. Guess there is no way around this, and PlayStore is quite lenient with copyright as well.
Good chance a game that you make will be copied within hours (if gets popular).

From what I read about ProGuard, it doesn't save your resources, just saves the code a little by messing up with the variable and function names and semantics.

Quote
"The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names."

avvi

  • Posts: 17
If the game is REALLY popular, then.... how much code + art work does it take to copy Threes or Flappy Bird? ;)
And Google won't do anything (if you're not Chillingo), because the graphics differ A BIT.

dareek

  • Posts: 91
What about JOBB? At least for Android.
Quote
"The jobb tool allows you to build encrypted and unencrypted APK expansion files in Opaque Binary Blob (OBB) format. You can download and mount these expansion files in your application using StorageManager on devices with Android 2.3 (API Level 9) or higher. OBB files are used to provide additional file assets for Android applications (such as graphics, sounds and video), separate from an application's APK file."
https://developer.android.com/tools/help/jobb.html
Would not 'Encrypted APK' be what we need to protect our artworks or sounds from being easily extracted by plain crooks?

I have found nice explanation of what OBB is and how it work.
Quote
"OBB lets you package up large files and store them on the public SDcard in a way that only your app can decrypt and use them. After building the AOSP the mkobb.sh and obbtool allow you to create (on Linux) OBB files.
After setting up things like PATH, permissions and kernel modules, creating is basicly:
Code: [Select]
$ mkobb.sh -d /data/myfiles -k my_secret_key -o /data/data.obb
$ obbtool a -n com.example.myapp -v 1 -s seed_from_mkobb /data/data.obb
After which you can store the data.obb on SDcard and only access the files from your app with use of the my_secret_key
Code: [Select]
storage = (StorageManager) getSystemService( STORAGE_SERVICE );
storage.mountObb( obbFilepath, "my_secret_key", myListener );
obbContentPath = storage.getMountedObbPath( obbFilepath );
Although other apps can destroy the data.obb on SD card only the app can access them and the content is as secure as if stored in app private.
Only on API level 9 and up and with the WRITE_EXTERNAL_STORAGE to access OBB files from SD."

I think this is what we are looking for.

« Last Edit: June 21, 2014, 07:57:18 am by dareek »