#4541 - CoderArt - Wed Apr 02, 2003 9:50 pm
How would I create some anti Piracy code?
Like detecting Emulation e.t.c?
is there a lib for this or any know techniques?
#4543 - tepples - Wed Apr 02, 2003 11:23 pm
In general, it's impossible to distinguish a legitimate backup copy or format-shifted copy created pursuant to 17 USC 117 and Sony v. Universal (the Betamax decision) from an infringing copy except in a court of law.
| CoderArt wrote: |
| How would I create some anti Piracy code? |
By lobbying your legislature. Such lobbying got the Statute of Anne (the first copyright law) passed.
That said, the way for a program to detect whether it's being emulated is to detect differences between the hardware and the emulation. If the emulation is accurate enough (as in current cycle-accurate Atari 2600 and NES emulators), the software won't be able to tell.
The best method at the moment is to measure the number of cycles it takes to do a series of instructions from ROM, EWRAM, and IWRAM, with various prefetch settings. No two emulators currently seem to do it the same way.
Another way, used by Dance Dance Revolution for GBC, is to design the game to require that button presses be timed to match the audio. All current GB and GBA emulators for Windows delay the audio by up to 200 ms and would make keypresses go way off.
Or you can measure the bounciness of the joypad buttons; if the bounce pattern doesn't look like that of the hardware, the game is running on an emulator.
It's possible to introduce extra hard-to-emulate hardware into the cartridge, as was done in lots of Super NES games and is still done in coin-op machines. This is already done on GBA, by giving A Link to the Past's EEPROM save hardware an interface different from that of other GBA games' EEPROM.
But if you do introduce strict dependencies on hardware features to defeat emulation, not only will testing become more difficult (as a tester can't slow down the game or give the developer a save-state that reproduces a bug), but you may also ruin compatibility with future revisions of the GBA (such as the GB games that don't run on GBC). And the next releases of the emulators will just take your new hardware into account or possibly hack around your protection with high-level emulation or binary patches; just look at the changelogs of SNES9x and ZSNES and the "no-CD" cracks for PC games if you don't believe me. Besides, the money you recover from lost potential sales may not be enough to pay the developer of the copy protection, as the developers of CD-ROM copy protection schemes have learned the hard way.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#4545 - CoderArt - Wed Apr 02, 2003 11:36 pm
Yeah - I like the idea of using real world audio timing as an anti emulation device - nice!
also the prefect cycle counting sounds cool - altho like you say it would be only a matter of time before the emu author figures it out.
I suppose you can have layers and layers of different protection - with the hope of making the authors give up on reverse engineering (but there are some pretty hardcore people out there), or make them take ages to unravel the damn thing..
Anyhow thanks for your input...
#4549 - ampz - Thu Apr 03, 2003 1:40 am
Emulators are not that important, who wants to play GBA games on an emulator anyway? Besides, emulators cannot support link-cables.
The important thing is to prevent the use of piracy flash carts. There are hundreds of different ways to do that by not using standard cart hardware.
#4550 - CoderArt - Thu Apr 03, 2003 3:32 am
thanks for that input ampz
but I'm really not interested in if it's worth doing or not. I'm interested in the techniques behind this.
#4553 - Lord Graga - Thu Apr 03, 2003 10:50 am
Something that you can do too, is to write 0x01 to somewhere in the end of the SRAM, i.e in a place where it won't be easy to spot.
When you load the gam you check to see if the SRAM has 0x01 on that point!
If not, then it is because of that it has been dumped and is running on a emu!
It's kinda bad, but it's a addition :P
#4555 - ampz - Thu Apr 03, 2003 12:00 pm
Interleave the main ROM memory, split it into two or more areas. I don't think any flash cart can handle that, and it's very hard to circumvent by hacking the binary.
#4557 - delbogun - Thu Apr 03, 2003 1:23 pm
found on the yahoo gbadev newsgroup:
| Pete wrote: |
Does anyone have code for detecting the presence of an emulator?
Thanks |
| Neal Tew wrote: |
This works pretty well. It has to be run from RAM, of course.
detectGBA: ;returns 0 if emulated
mov r0,#0
str r0,_0
_0: mov r0,#1
mov pc,lr
|
| Pete wrote: |
Thanks, that was exactly what I needed. ;-)
Cheers,
-Pete
P.S. His code works by overwriting the next instruction with a NOP.
On a real CPU, the old contents would have already been fetched,
so the overwrite has no effect. |
;)
#4561 - CoderArt - Thu Apr 03, 2003 2:33 pm
That's cool
there are probably lots of hideous tricks like that, that'll stuff up the emu's
I'm tempted to spend some time to find em all.
I suppose the more of these you add - the tricky/slower the emulation becomes!
#4562 - CoderArt - Thu Apr 03, 2003 3:11 pm
Just thought of another one:
I guess the emus look for Vblank code to speed up the emulation - so maybe writing vblank waiting code in an obscure manner would stop this speed trick and slow the emu down?
#4563 - tepples - Thu Apr 03, 2003 3:45 pm
| CoderArt wrote: |
| I guess the emus look for Vblank code to speed up the emulation |
This is true of NES emulators running with a "speed hack", but it's not true of VisualBoyAdvance under default settings last time I checked. GBA emulators look for a VblankIntrWait() call.
| Quote: |
| so maybe writing vblank waiting code in an obscure manner would stop this speed trick |
The only thing that doing something strange while spinning before Vblank can do is eat up power. Games use VblankIntrWait() to stop the CPU when it's not needed so that the batteries last longer.
| Quote: |
| and slow the emu down? |
Anything that slows the emulator instead of defeating it will apply for only 18 months, until Moore's Law doubles the density (and consequently the speed) of PC processors. For instance, my 866 MHz PIII machine can't run the Farbrausch 'fr018' demo at full speed (even with frameskip), but this year's machine probably can. If your goal is to prevent copyright infringement, then you need something that will last for ninety-five years.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#4567 - NEiM0D - Thu Apr 03, 2003 4:36 pm
To detect a flash advance cart from Visoly, there is some code out to detect it.
It's called CARTLIB by Jeff F., if I'm not mistaken.
There is even code to erase the Visoly flash cart inside the GBA (might be handy when you want to do some funky stuff on their piracy carts ;)
Cheers.
#4570 - Vortex - Thu Apr 03, 2003 5:10 pm
I was thinking about encrypting the rom and using some decrypting hardware on the cart, but this probably is not you are looking for, because it is not a pure software solution.
#4571 - tepples - Thu Apr 03, 2003 5:30 pm
| Vortex wrote: |
| encrypting the rom and using some decrypting hardware on the cart |
Some Super NES games such as Star Ocean and Street Fighter Alpha 2 did this. Emulator authors eventually developed a way to use "decompression packs," made of data captured in transit from the decrypting hardware to the console, to decrypt the graphics.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#4574 - Daikath - Thu Apr 03, 2003 5:51 pm
But even then you could use the linkcable to get the decrypted rom dumped because you use the GBa to read it with uses the cart.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?
#4580 - delbogun - Thu Apr 03, 2003 8:17 pm
atleast the decrypted rom will not work on a flash cart...