‘Skidrow’ Pirates Get Pirated After Removing Their Own ‘DRM’

[shamu726]

After a rival group beat them to the release of a new game, this week legendary crackers/pirates Skidrow complained that their work had been 'pirated'. While that's fairly ironic in itself, the group went on to reveal some of the reasons why it doesn't protect its code. Just like its DRM counterpart, Skidrow 'piracy' protection causes difficulties for end users.

It’s very common for the entertainment industries to get their collective undergarments in a twist over piracy, so it makes an interesting change to see the same kinds of emotions spill over onto the other side of the piracy fence.

It all began a couple of weeks ago with the release of the Redlynx / Ubisoft motorcross game Trials Fusion. Released on all the top platforms mid April, the race was immediately on for a so-called ‘Scene’ group to remove its copy protection and release a pirated version. On April 16 the group ‘MoNGoLS’ released the game on XBox 360 and eight days later a group called ‘CODEX’ released the Windows version.

Scene records show that CODEX have only been around since February this year yet they managed to beat other leading groups on this particular release. Was that due to them being clever and working hard, or was there another explanation? According to one of the most famous cracking/piracy groups on the Internet, CODEX cheated their way to the win.

Skidrow is one of the most famous groups around and is responsible for the cracking and release of hundreds of games over the years. On April 27, three days after the CODEX release of Trials Fusion, Skidrow released their own version. Then, the day after, revealed why that had been necessary.

According to Skidrow, CODEX had – shock, horror – PIRATED Skidrow’s work.

“While looking inside their emulation code, we discovered something that was about to shock us completely,” Skidrow explained in an announcement this week.

“It was OUR work, OUR emulator.”

But how could Skidrow be so sure? Apparently the group employs rudimentary watermarking.

“CODEX must be stupid to think that we don’t mark our code, but we had it clean on our screens, that CODEX are thieves of our Ubisoft emu. 99 percent of all their API calls in the code are identical with ours.”

Just to be sure, Skidrow say they also plant “several stealth API calls, that identify and tag” their work. Those were apparently found inside CODEX emulation DLLs. For those who understand it, the proof is apparently revealed in the image below.

“[The image] shows the original function written by the coder, using a global variable for another function. Basically, the way the coder wrote the API to set the flag is unique, and [this is] simply copy and paste of our code by CODEX,” Skidrow say.

But while the irony of one group complaining about the pirating (or plagiarizing) of another’s work is pretty obvious, this week Skidrow revealed something else of interest. The group said that while previously it had taken measures to protect its cracks and emulators and obfuscate their code, it had decided to stop doing so when the code got in the way of enjoying the release.

“In the past we used to protect our creations, but lately we have found out that even the most functional [encryption] tools have certain limits when it comes to preventing them from stealing CPU resources,” Skidrow revealed.

“Furthermore we have noticed that some people that use our releases, sometimes have issues with our work being notified as dangerous, when they run them on machines with certain antivirus, spam, spyware programs etc. Therefore we have decided to let our work, which is OUR work, be as clean and direct as you can get it.”

So there you have it. Even the swarthiest of game pirates get upset when people “steal” their code, and not even leading experts in consumer DRM cracking can get their own ‘DRM’ working without negatively affecting the gaming experience. Intriguing indeed…..

Note: For clarity some of Skidrow’s English translation errors have been tidied up.

Source: TorrentFreak

Edit: Skidrow nfo containing statement. It's under "PROPER NOTES" heading. Trials.Fusion.Proper-SKIDROW

Edited May 4, 2014 by shamu726

[shamu726]

TorrentFreak writer is equaling plagiarism to piracy? <_<

[software182]

:wtf:

[shamu726]

CODEX Responds to Skidrow Allegations of plagiarism

CODEX PRESENTS: Trials Fusion STATEMENT
Release Date : 4/2014 Protection : Brains
Discs : 1 Genre : Action RPG

CODEX is rather new to the scene, so it was to be expected that one of the old established groups would sooner or later start picking at us. Now Skid Row took a poor attempt to actually score again in a scene that has overtaken them ...

If you are throwing accusations of stolen code around , atleast make sure your information is correct. We did not copy your code , nor do we have any interest in copying it. After investigating your emu, we find that your code is hilariousand lacking , but we do not hold this against you and we encourage everybody who is able to verify that the two emulators are different in numerous ways that disproves any claims of copying. More about the difference further at the bottom.

The reasons given for a PROPER release of Trials Fusion are so far fetched, that we decided to clear a few things up. So heres an extract of Skid Rows accusations with our statements:

SKIDROW: 99 procent of all their API calls in the code is identical with ours.
CODEX: Of course thats the case because we are trying to emulate uplay, and thats how uplay works. So if you take a look at ANY other UBI emu available - you will definetly find a lot of code loking alike. Like the simplest of all; return 0/1. This is in fact the most used way of returning a function that has no real value in the game.

SKIDROW: We did of course plant several stealth API calls, that identify and tag our work. Yet those API calls are inside the CODEX emulation dlls.
CODEX: Which API calls are you referring to then? Maybe they are too stealth that they cant be found anymore ...

SKIDROW: Link above show one, out of many proofs of stolen code. It shows the original function written by the coder, using a global variable for another function. Basicially the way the coder wrote the API, to set the flag is unique, and simply copy and paste of our code by CODEX.
CODEX: The unique flag you supposedly set, is actually in OUR code a DWORD array which holds a simple value for telling the function that is called - to define if the Overlap Operation has been completed or not. Now how unique is that approach ? ...

SKIDROW: To finalize their CODEX stupidity - they set the wrong parameter for CreateFile API when it comes to folders. We do use GENERIC_READ, cause of an important point, Windows simply dont allow GENERIC_ALL without admin rights.
CODEX: Didnt you accuse us that we copy/pasted your entire emu ? So why are there differences now ? Maybe because we coded everything ourselves .. Thanks for pointing that out.

As a result to this pathetic attempt to make everyone believe we are copycats, we had to spend some time looking into their crappy code and found some interesting and obvious differences:

- CODEX emu is written in c++ , SR emu is written in ASM - how can you blindly copy/paste there ?
- CODEX emu uses 76 Imports, SR emu uses 27 Imports
- CODEX emu has 75 Exports, SR emu has 70 Exports
- CODEX doesnt use file padding, SR does
- CODEX uses heaprealloc and heapsize, SR doesnt
- CODEX emu doesnt need a patched .exe in Trials Fusion to work, SR emu does need it ...
- CODEX uses 6 vars for their read function, SR uses 7 vars
- .....

We could go on showing you a lot more differences, but we dont think its worth the effort since nothing is stolen. Concerning your nice little picture where you busted us, heres our 2 cents to this awesome finding :

Our original c++ code :

UPLAY_R1_LOADER int UPLAY_HasOverlappedOperationCompleted
(TwoDwords * OverlappedOperationCompleted)
if (OverlappedOperationCompleted-a2)
Ovrlaped[0] DWORD(OverlappedOperationCompleted-a1);
return 0;
else return 1;

... in a debugger it looks like this:

0FFD1A92 / 55 PUSH EBP
0FFD1A93 . 8BEC MOV EBP,ESP
0FFD1A95 . 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
0FFD1A98 . 8378 04 00 CMP DWORD PTR DS:[EAX+4],0
0FFD1A9C . 74 09 JE SHORT 0FFD1AA7
0FFD1A9E . A3 A0D8FE0F MOV DWORD PTR DS:[FFED8A0],EAX
0FFD1AA3 . 33C0 XOR EAX,EAX
0FFD1AA5 . 5D POP EBP
0FFD1AA6 . C3 RETN
0FFD1AA7 33C0 XOR EAX,EAX
0FFD1AA9 . 40 INC EAX
0FFD1AAA . 5D POP EBP
0FFD1AAB \. C3 RETN

CODEX is open for a head to head discussion about this issue. You guys know where to find us! We will no further have this silly discussion in public anymore .. We have nothing to hide and wont participate in your lets beat the new guy before he gets too strong mission.

CODEX is currently looking for: nothing but competition! are you ready?

LNKCPS 02/2014

Source: Scenenotice.org

Edited May 4, 2014 by shamu726

[software182]

Interesing to watch... go on

:snack:

[Myna]

Yea... Now that looks interesting.... I would like to see/read about some more action..... :D :D :D

[Allen_Prasetya]

When pirates accussing another pirates :\

[#return 1337]

I like CODEX's approach, and I try to incoporate it in my peronsal releases I pass around to friends.

I like to break the protection in an API layer, instead of the EXE layer, that way it makes it so patching the game for future updates abstracts the crack from the game itself, and can work on other platforms, so long as the distro layer stays the same. I've noticed some crack groups like RELOADED have tried to do the same, but fail horribly at it, treating the API calls so ham fistedly, causing the save files to be fucked, as was the case with Far Cry 3 when it got updated to 1.04. My solution also allows the cracking of DLC with nothing more than an INI update.

I mainly only crack Steam games as that's the only layer I've cracked myself, but CODEX has taken the same approach. I crack the steam_api.dll, which takes an existing AppID, spoofs it as the game you want to play, and just returns 1 for HasAppID call. Nothing spectacular, but all the Steam authentication code is done in that one function, and I simply just gut it. Since every game uses a different steam_api.dll, I wrote some extra layer inside my DLL to just call the original steam_api.dll called steam_api_original.dll, and so far has worked on every steam game I've thrown at it, and can even work to play pirated games on legit servers, so long as you know how to force the ISteamMatchMaking interface.

Anyway, their UPLAY solution is similar to my Steam solution, as they are cracking the UPLAY layer directly, instead of patching the UPLAY calls in the EXE. Brilliant work, Skidrow can suck a nutt.

Edited May 5, 2014 by #return 1337

[SnakeMasteR]

When pirates accussing another pirates :\

Crackers aren't pirates, they are crackers. Otherwise the word would start with P instead of C, there must be a difference somewhere.

[x3r0]

I like CODEX's approach, and I try to incoporate it in my peronsal releases I pass around to friends.

I like to break the protection in an API layer, instead of the EXE layer, that way it makes it so patching the game for future updates abstracts the crack from the game itself, and can work on other platforms, so long as the distro layer stays the same. I've noticed some crack groups like RELOADED have tried to do the same, but fail horribly at it, treating the API calls so ham fistedly, causing the save files to be fucked, as was the case with Far Cry 3 when it got updated to 1.04. My solution also allows the cracking of DLC with nothing more than an INI update.

I mainly only crack Steam games as that's the only layer I've cracked myself, but CODEX has taken the same approach. I crack the steam_api.dll, which takes an existing AppID, spoofs it as the game you want to play, and just returns 1 for HasAppID call. Nothing spectacular, but all the Steam authentication code is done in that one function, and I simply just gut it. Since every game uses a different steam_api.dll, I wrote some extra layer inside my DLL to just call the original steam_api.dll called steam_api_original.dll, and so far has worked on every steam game I've thrown at it, and can even work to play pirated games on legit servers, so long as you know how to force the ISteamMatchMaking interface.

Anyway, their UPLAY solution is similar to my Steam solution, as they are cracking the UPLAY layer directly, instead of patching the UPLAY calls in the EXE. Brilliant work, Skidrow can suck a nutt.

As long as the exe itself isn't protected by SteamCEG or SteamStub, right? However, users that play "pirated" games still wouldn't be able to join any matches with legit users.

When pirates accussing another pirates :\

Crackers aren't pirates, they are crackers. Otherwise the word would start with P instead of C, there must be a difference somewhere.

RZR uses word "Pirates of 7 Seas" though. Edited May 6, 2014 by x3r0

[Allen_Prasetya]

When pirates accussing another pirates :\

Crackers aren't pirates, they are crackers. Otherwise the word would start with P instead of C, there must be a difference somewhere.

ahh, forgot about that, can't think any other word when writing that post though, thanks for correcting

[#return 1337]

I like CODEX's approach, and I try to incoporate it in my peronsal releases I pass around to friends.

I like to break the protection in an API layer, instead of the EXE layer, that way it makes it so patching the game for future updates abstracts the crack from the game itself, and can work on other platforms, so long as the distro layer stays the same. I've noticed some crack groups like RELOADED have tried to do the same, but fail horribly at it, treating the API calls so ham fistedly, causing the save files to be fucked, as was the case with Far Cry 3 when it got updated to 1.04. My solution also allows the cracking of DLC with nothing more than an INI update.

I mainly only crack Steam games as that's the only layer I've cracked myself, but CODEX has taken the same approach. I crack the steam_api.dll, which takes an existing AppID, spoofs it as the game you want to play, and just returns 1 for HasAppID call. Nothing spectacular, but all the Steam authentication code is done in that one function, and I simply just gut it. Since every game uses a different steam_api.dll, I wrote some extra layer inside my DLL to just call the original steam_api.dll called steam_api_original.dll, and so far has worked on every steam game I've thrown at it, and can even work to play pirated games on legit servers, so long as you know how to force the ISteamMatchMaking interface.

Anyway, their UPLAY solution is similar to my Steam solution, as they are cracking the UPLAY layer directly, instead of patching the UPLAY calls in the EXE. Brilliant work, Skidrow can suck a nutt.

As long as the exe itself isn't protected by SteamCEG or SteamStub, right? However, users that play "pirated" games still wouldn't be able to join any matches with legit users.

That is incorrect.

[x3r0]

I like CODEX's approach, and I try to incoporate it in my peronsal releases I pass around to friends.

I like to break the protection in an API layer, instead of the EXE layer, that way it makes it so patching the game for future updates abstracts the crack from the game itself, and can work on other platforms, so long as the distro layer stays the same. I've noticed some crack groups like RELOADED have tried to do the same, but fail horribly at it, treating the API calls so ham fistedly, causing the save files to be fucked, as was the case with Far Cry 3 when it got updated to 1.04. My solution also allows the cracking of DLC with nothing more than an INI update.

I mainly only crack Steam games as that's the only layer I've cracked myself, but CODEX has taken the same approach. I crack the steam_api.dll, which takes an existing AppID, spoofs it as the game you want to play, and just returns 1 for HasAppID call. Nothing spectacular, but all the Steam authentication code is done in that one function, and I simply just gut it. Since every game uses a different steam_api.dll, I wrote some extra layer inside my DLL to just call the original steam_api.dll called steam_api_original.dll, and so far has worked on every steam game I've thrown at it, and can even work to play pirated games on legit servers, so long as you know how to force the ISteamMatchMaking interface.

Anyway, their UPLAY solution is similar to my Steam solution, as they are cracking the UPLAY layer directly, instead of patching the UPLAY calls in the EXE. Brilliant work, Skidrow can suck a nutt.

As long as the exe itself isn't protected by SteamCEG or SteamStub, right? However, users that play "pirated" games still wouldn't be able to join any matches with legit users.

That is incorrect.

Which one of my statements is incorrect? Joining legit servers or additional exe protection by SteamCEG or SteamStub? Or both of them are incorrect?