|
#1
|
|||
|
|||
[C#] EADRM Encryptions & Few notes...
Well, first off - there are 2 major "encryptions" used in EADRM;
.PAR - the parameter file which contains the parameters the DRM itself reads, and uses together with the cipher-key found in the .DLF (the decryption information key file)... .PAR is "encrypted" with a simple Xor encryption w/key: Code:
private static byte[] Xor(byte[] orgBytes, byte[] keyBytes) { for (var i = 0; i < orgBytes.Length; i++) { orgBytes[i] = (byte)(orgBytes[i] ^ keyBytes[i % keyBytes.Length]); } return orgBytes; } .DLF is encrypted (yes, really encrypted) with AES-CBC w/zero padded IV: (also static Key by the way...) Code:
private static string AesDecrypt(this byte[] cryptText) { using (var aes = new RijndaelManaged { BlockSize = 128, KeySize = 128, Padding = PaddingMode.Zeros, Mode = CipherMode.CBC, Key = new byte[] { 0x41, 0x32, 0x72, 0x2D, 0xD0, 0x82, 0xEF, 0xB0, 0xDC, 0x64, 0x57, 0xC5, 0x76, 0x68, 0xCA, 0x09 }, IV = new byte[] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }) { var decryptor = aes.CreateDecryptor(); var encrypted = cryptText; var planeText = new byte[encrypted.Length]; using (var memoryStream = new MemoryStream(encrypted)) { using (var cryptStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read)) { cryptStream.Read(planeText, 0, planeText.Length); return Encoding.ASCII.GetString(planeText).CleanInput(); } } } } During my research towards making an unpacker for EADRM/OriginStub (without the need to patch any API's), I also discovered that there is currently 3 variations of the DRM/Stub: Quote:
Oh, and no tools will be given for this - just enjoy these few findings and write your own tools Last edited by n00b; 04-01-2016 at 03:52. Reason: Seems Command & Conquer has a slight different V2... |
The Following User Gave Reputation+1 to n00b For This Useful Post: | ||
niculaita (03-29-2016) |
The Following 6 Users Say Thank You to n00b For This Useful Post: | ||
chessgod101 (03-29-2016), e0qs (05-22-2016), gsaralji (12-10-2016), tonyweb (12-17-2016), zeytunak (03-31-2016) |
#2
|
|||
|
|||
.ooa section is just origin, no denuvo implied and are you just assuming .net entrypoint cos of the ff 25 jmp to activation.dll (its not .net at all)
|
The Following User Says Thank You to evlncrn8 For This Useful Post: | ||
tonyweb (12-17-2016) |
#3
|
|||
|
|||
Quote:
As I also said earlier, I don't claim its actually .NET assembly at all |
The Following User Says Thank You to n00b For This Useful Post: | ||
tonyweb (12-17-2016) |
#4
|
|||
|
|||
the funny thing too is that the actual license check boils down to a strcmp call (it was a real strcmp api call in the initial versions, which then became inline over the times, and i think the latest is a qt one.. same concept though), so with any valid license from any machine, patching the compare to return 0 (for success) works and has done for every single version of ea access ... amazing how all that digital signing, checking etc all boils down to one string compare heh.. slow clap @ ea, course denuvo (and securom) also have this license check in their code too so that needs found and smacked as well but for ea access, its a piece of piss
|
#5
|
|||
|
|||
Thats true, but doing a simple patch is always too easy - and thus, not that fun (can be said with most protections really, if you really dig deep enough)... Take for example the infamous Armadillo, they had an amazing protection against cracking - but since they solely relied on big crypto, it had to fail badly anyways; because it all boils down to one single compare in the end no matter what anyone thinks...
Its actually true, you can dig deep enough in absolutely every protection scheme that exists - and in the very end (most developers doesn't even realize this either, thats the worst part) you will find that tiny little compare function one way or another which more or less controls wether your key/serial/whatever is valid or not - its a simple fact of today's computing technology really... If our current computer technology had been based upon quantum tech already, we would have been seeing TRUE protection schemes that actually has lots tricks to stop us - but we won't see that in our current tech, cuz one bit/byte cannot and never will be able to reflect two different states at the same time Thus, the very end will always rely on 1 single fucking compare - and yes, this doesn't matter if it has 1 billion layers above to "protect" that 1 little compare :P |
#6
|
|||
|
|||
Some code that may aid you in creating an actual unpacker or unwrapper:
Yes, this is actual working sources (only partial!!) - and I've chosen to release this publically since EADRM/OriginDRM is more or less dead nowadays anyways...
(The code is crude, and not optimized at all!) Code:
/// Anywho; use this code as you wish, but credit me if you do |
Thread Tools | |
Display Modes | |
|
|