nikolatesla20
December 10th, 2002, 20:22
Heh. Hope someone finds this useful/cool. Just got er done.
Hi all,
This is a tutorial about using armadillo to protect your own files without having to have a registered armadillo program.
I've been working with Armadillo for a little while now, just trying weird things to see how I can break it. I've been protecting my own test files, and then trying to load them into my own loaders, debuggers, etc, to edit memory during run time. Most of the time armadillo seems to catch something is wrong if it's too early, and it bombs out on you. I tried one very unique thing this morning however, and it worked, and I think it's quite hilarious......
When you download the armadillo evaluation, there really are no limits. You are allowed to use it as long as you wish, but you cannot distribute with it. The main item that prevents you from you doing so is a nice little nag screen that comes up before your protected app that says "This version of armadillo is not registerd..blah..blah..not licensed for distribution". Since CruSader already gave us such a nice tutorial on removing armadillo protection, I decided to try an opposite approach, so I could USE armadillo, but I'd have to kill this nag in my own protected apps. It really is no problem to dissassemble a protected file in IDA, but you won't find the nag in there anywhere. Why? Because it's in the DLL that gets decompressed into memory during runtime. This is the "arma.dll" that CruSader tells us how to dump from memory.
But still, that doesn't help us, because then the only way around it would be to patch that file in memory after it was unpacked during your protected program's startup. The only reliable way to do that would be to either inject code or put another wrapper around your already protected application. I tried those techniques and got away with some things (like adding another section, etc.) but not others (couldn't use a cave). Armadillo was pretty good at preventing any code redirection as well, with some sort of CRC checks and stuff.
Suffice it to say I got bored looking at doing it this way. What I really needed was a way to have the armadillo.dll file ALREADY be how I wanted it BEFORE it ever made its way into my protected application. Well, I found the way to do that.
CruSader seemed happy that he could dump the armadillo.dll from memory while in his protected app, but did you know that it simply sits naked inside armadillo.exe itself? Yes, its just a simple resource file. And lo and behold, its not even CRC checked. Can you believe it?
So for starters, if you don't have a dumped dll file from going through CruSader's tutorial, you can get one very easily by using eXeScope and opening armadillo.exe, and going to the resource section. The DLL's are under the "HEADERS" resources. Take the third one in the list, and export it as "whatever3.dll". Now you have a clean DLL. No memory dumping required ! It's not even encrypted ! *oops* Silicon Realms!
Open that sucker up in IDA. Go to "MessageBoxA" reference, and double click on the second call reference and you will see this code:
Notice that jump if zero on 1000E9E6? It will completely jump over showing the "unregistered" nag if it notices that there is no string in memory to show. We want that jump to jump always, in other words, change its byte from 0x74 to 0xEB. So let's do it!
Open up LordPE or PEditor and get the Hex offset in the file of that instruction and write it down. I came up with 0xE9E6.
Now, open armadillo.exe again in eXeScope. Go to the "HEADERS" resources again, and click on the third item (Resource ID 121 in my version). This is one of two versions of the armadillo.dll (ID 121 and ID 153). Anyway, notice it already has an offset in the file. Fire up Calc.exe and add (Resource offset + instruction offset). BE sure you are in HEX mode in Calc!. This is where you will find the offending instruction. Now, scroll down in eXeScope to the address. I have the latest armadillo evaluation version (2.65 build 2221) and the address I got was 0x97466. Once you get there, simply type in the new byte value "EB". Done!. Now you have to do the same thing for the second version of the DLL. The difference between them as I found was one uses SI detection, and the other doesn't.
The other DLL is Resource ID 153. I'll let you calculate the offset to the instrcution. REMEMBER tho that you will have to export and dissassemble this DLL to get the instruction's address again. Since its a different version it won't be in the same place. Once you have edited both resources, you are good to go! Go back out and protect your file, and test it. Wooot! No more nag screen. Now I must say that is quite sad that the Silicon Realms guys put so much work into "anti-crack", etc, but they never seem to bother checking their prebuilt code blox. Well I guess others can enjoy the mistakes eh?
'Til next time...
-nt20
*Remember you have to BUY software if you really want to use it so if you use this software please support the authors and purchase it*
Code:
********************** KILL THE NAG *************
***
*** Target: Armadillo 2.65 build 2221
*** Freed By: nikolatesla20
*** Date: December 10, 2002
*** Purpose: Freeing
***
*************************************************
Hi all,
This is a tutorial about using armadillo to protect your own files without having to have a registered armadillo program.
I've been working with Armadillo for a little while now, just trying weird things to see how I can break it. I've been protecting my own test files, and then trying to load them into my own loaders, debuggers, etc, to edit memory during run time. Most of the time armadillo seems to catch something is wrong if it's too early, and it bombs out on you. I tried one very unique thing this morning however, and it worked, and I think it's quite hilarious......
When you download the armadillo evaluation, there really are no limits. You are allowed to use it as long as you wish, but you cannot distribute with it. The main item that prevents you from you doing so is a nice little nag screen that comes up before your protected app that says "This version of armadillo is not registerd..blah..blah..not licensed for distribution". Since CruSader already gave us such a nice tutorial on removing armadillo protection, I decided to try an opposite approach, so I could USE armadillo, but I'd have to kill this nag in my own protected apps. It really is no problem to dissassemble a protected file in IDA, but you won't find the nag in there anywhere. Why? Because it's in the DLL that gets decompressed into memory during runtime. This is the "arma.dll" that CruSader tells us how to dump from memory.
But still, that doesn't help us, because then the only way around it would be to patch that file in memory after it was unpacked during your protected program's startup. The only reliable way to do that would be to either inject code or put another wrapper around your already protected application. I tried those techniques and got away with some things (like adding another section, etc.) but not others (couldn't use a cave). Armadillo was pretty good at preventing any code redirection as well, with some sort of CRC checks and stuff.
Suffice it to say I got bored looking at doing it this way. What I really needed was a way to have the armadillo.dll file ALREADY be how I wanted it BEFORE it ever made its way into my protected application. Well, I found the way to do that.
CruSader seemed happy that he could dump the armadillo.dll from memory while in his protected app, but did you know that it simply sits naked inside armadillo.exe itself? Yes, its just a simple resource file. And lo and behold, its not even CRC checked. Can you believe it?
So for starters, if you don't have a dumped dll file from going through CruSader's tutorial, you can get one very easily by using eXeScope and opening armadillo.exe, and going to the resource section. The DLL's are under the "HEADERS" resources. Take the third one in the list, and export it as "whatever3.dll". Now you have a clean DLL. No memory dumping required ! It's not even encrypted ! *oops* Silicon Realms!
Open that sucker up in IDA. Go to "MessageBoxA" reference, and double click on the second call reference and you will see this code:
Code:
.text:1000E9BD sub_1000E9BD proc near ; CODE XREF: sub_1000DE51+606p
.text:1000E9BD ; sub_1000E55A+33j ...
.text:1000E9BD
.text:1000E9BD var_4 = dword ptr -4
.text:1000E9BD
.text:1000E9BD push ebp
.text:1000E9BE mov ebp, esp
.text:1000E9C0 push ecx
.text:1000E9C1 push ebx
.text:1000E9C2 push esi
.text:1000E9C3 push edi
.text:1000E9C4 call sub_1000F40B
.text:1000E9C9 mov eax, dword_10022EC4
.text:1000E9CE mov esi, ds:MessageBoxA
.text:1000E9D4 mov ebx, 10040h
.text:1000E9D9 mov edi, offset aDistributionWa ; "Distribution Warning"
.text:1000E9DE mov eax, [eax+4ECh]
.text:1000E9E4 test eax, eax
.text:1000E9E6 jz short loc_1000E9EF <-- this checks for a good message string in memory
.text:1000E9E8 push ebx ; uType
.text:1000E9E9 push edi ; lpCaption
.text:1000E9EA push eax ; lpText
.text:1000E9EB push 0 ; hWnd
.text:1000E9ED call esi ; MessageBoxA
.text:1000E9EF
.text:1000E9EF loc_1000E9EF: ; CODE XREF: sub_1000E9BD+29j
.text:1000E9EF mov ecx, dword_10022EC4
.text:1000E9F5 call sub_1000B710
.text:1000E9FA test eax, eax
.text:1000E9FC jz short loc_1000EA10
Notice that jump if zero on 1000E9E6? It will completely jump over showing the "unregistered" nag if it notices that there is no string in memory to show. We want that jump to jump always, in other words, change its byte from 0x74 to 0xEB. So let's do it!
Open up LordPE or PEditor and get the Hex offset in the file of that instruction and write it down. I came up with 0xE9E6.
Now, open armadillo.exe again in eXeScope. Go to the "HEADERS" resources again, and click on the third item (Resource ID 121 in my version). This is one of two versions of the armadillo.dll (ID 121 and ID 153). Anyway, notice it already has an offset in the file. Fire up Calc.exe and add (Resource offset + instruction offset). BE sure you are in HEX mode in Calc!. This is where you will find the offending instruction. Now, scroll down in eXeScope to the address. I have the latest armadillo evaluation version (2.65 build 2221) and the address I got was 0x97466. Once you get there, simply type in the new byte value "EB". Done!. Now you have to do the same thing for the second version of the DLL. The difference between them as I found was one uses SI detection, and the other doesn't.
The other DLL is Resource ID 153. I'll let you calculate the offset to the instrcution. REMEMBER tho that you will have to export and dissassemble this DLL to get the instruction's address again. Since its a different version it won't be in the same place. Once you have edited both resources, you are good to go! Go back out and protect your file, and test it. Wooot! No more nag screen. Now I must say that is quite sad that the Silicon Realms guys put so much work into "anti-crack", etc, but they never seem to bother checking their prebuilt code blox. Well I guess others can enjoy the mistakes eh?
'Til next time...
-nt20
*Remember you have to BUY software if you really want to use it so if you use this software please support the authors and purchase it*
.
i agree with iwarez comment. thanks god people and board like this one exist!