Armadillo 1.83b

标题：请看..... (11千字)
作者：1212
时间：2000-8-3 21:53:14

How To Un-dillo A Program Protected With Armadillo 1.8X or
prior - The Silicon Realms Toolworks

------------------------------------------------------
Tools Needed
WinHex 9.0 or other memory dumper
W32DASM 8.7 or 8.9 (for Armadillo 1.8 - 1.8x protection)
Debugger Not Needed and must be disabled!
------------------------------------------------------
Whether or not you have an executable with the most recent version of Armadillo or not really doesn't matter. There is a slightly more involved procedure for un-dilloing the recent 1.80 - 1.8x versions but as you'll see it's really very simple.
The target application we are going to work on is going to be Stay On Pro 3.2. If you don't already have this file it should be available at the site www.stayonpro.com. This is a popular utility designed to keep you connected to your internet service if you happen to idle for a while doing nothing and is protected with Armadillo.
If you wish to read more about the internal armadillo workings read on.

If you wish to skip to how to dump out StayOnPro3.2 click HERE.

If you wish to skip to how to dump out Armadillo 1.8x or an Armadillo 1.8 - 1.8x protected program click HERE.

To begin I will explain the basic protection found in most Armadillo versions. No real knowledge of it's internal workings is necessary to crack the program but might help in other similar protection methods.

Starting an armadillo protected program will result in instantly creating a file either in the local directory where the program was started or in one of the temporary directories on your hard drive. This file is named ArmXXXX.tmp. This file is actually the Armadillo Access (security) DLL. This file may be copied while the program is running and then disassembled. In newer versions this file is hidden in the local user\local settings\temp directory.

Once the ArmXXXX.tmp is created with CreateFileA it is placed on the hard drive and loaded with the main program's LoadLibraryA function. All functions in Armadillo seem to be loaded on the spot in memory to help prevent direct text access.

Now, the main program calls the un-packing and un-encrypting function. In this particular version this function is named GetProgramInfo. GetProgramInfo also checks for the SoftIce hardware debugger, and any Windows debugger. It does this with a few functional steps:
---------------------------------------------------------------------
1.Calls CreateFileA 3 times with the file name parameters "\\.\SICE", "\\.\NTICE", and "\\.\SIWDEBUG" (which are internally encrypted). If they do exist or GetLastError doesn't return 2, a flag is set. This flag will be referred to as the DEBUG flag.
2.A call to IsDebuggerPresent is made to test if a windows debugger is present. SoftIce and other hardware debuggers do not test true to this function. If a Windows debugger is found the DEBUG flag is set to true
3.Depending on the version, a dialog may be shown here to warn any user who has a debugger in operation to turn it off and restart. This dialog displays under certain versions, if the DEBUG flag is true
4.If you now see a, "This program uses a secret key", at this point and it normally doesn't ask for a key, delete the Software\The Silicon Realms registry keys and start over. This happens if you screw up the steps and it catches a debugger or the program can't extract the main program's code right
5.INT 3. This is the final protecting method. A fake breakpoint set in the program to stop a debugger in it's tracks. But, SoftIce, doesn't respond to INT 3 unless you set I3HERE ON you say? Wrong, this is what baffled me for a while. SoftIce doesn't want to respond, but it does due to the fact that EBP is set to, "BCHK", not as a pointer, but actual text. When SoftIce is active it has a debug exception called bounds checker. With, "BCHK", loaded into EBP the breakpoint instruction (INT 3) calls the exception handler for SoftIce's bounds checker. SoftIce doesn't expect anything coming in and the stack isn't prepared or something similar because a page fault will occur after a return. To break this final protection you must set a breakpoint for IsDebuggerPresent not because you need to change the return value of that function, just because it's a good stopping point. Pressing F12 in SoftIce to return from that function and F12 twice again will get you back into the original program code and out of the security (armadillo) dll. Now F10 (trace over) a bunch of times and you'll get to the INT 3 instruction. You want to stop right after EBP is initialized. Type R EBP=4444444 in SoftIce. Now it's tricked and pressing CTRL + D to exit Ice will result in the target program running. So how does this really work? If there is no debugger present, Windows or SoftIce, the INT 3 causes an unhandled exception handler to trip. This unhandled exception handler is right after the JMP instruction. If a debugger exists program flow will continue after the INT 3. A bunch of code to crash the program intentionally is after this INT 3 instruction. If not it jumps over to the exception block and flow continues as if there were no debugger present
--------------------------------------------------------
Now you know the insides. Surprisingly, you don't need any of the above information. You can un-arm any Armadillo application in a few easy steps. It isn't necessary to figure out what version Armadillo is protection the program either. This you will know if you need to do extra 1.80 - 1.8x steps. You do however, need to know that armadillo is protecting the program. The above tips will let you know if this is the latter. Some other useful information is the use of GetPrivateProfileString, and it's brothers and sisters by protected applications to tell if they are for instance, "PAIDFOR". Dis-assemble the security DLL, Armadillo 1.8x, its protected programs and you can pick other variables out as well. Whoops, that makes it really hard to patch a un-dilloed application doesn't it? To think, some programmers are paying $89.00 for this! The only people is it working for is Silicon Realms Toolworks employees as they can easily use any application that uses it for free. Well, now, so can us all.
--------------------------
1. Without any debuggers present, including SoftIce, start the protected application. The file you need is the program's name you are running followed by a number and "ProgName.tmpX". So, if you are starting "StayOnPro.Exe" you'll see in the local directory, "StayOnPro.tmp0". Copy this file by selecting it and pressing CTRL+C and CTRL+V.
2. Rename this copied file ("Copy of StayOnPro.tmp0") to read, "StayOnPro(undilloed).exe".
3. Start WinHex 9.0 with the crack for it previously applied
4. Press ALT+F9 to start the process memory selection.
5. Select StayOnPro.tmp0 and select it's Primary Memory
6. Go to address 00400000H. This address should always be the starting point of the windows exe image. You'll always know you are at the correct position if you see "MZ" at the address.
7. Now you are going to select a large block of memory. Click next to the 00400000H address in the cell that shows 4D press and hold the shift key down while pressing page down (this works the quickest). Select the block all the way to address 4323D6. The same works for any other program. Ignore the first block of 0's after the program's header. This normally starts at around 400600H-401000H. The code starts at normally 401000. You want to select all the code till the block of zeros which separates a file section. In this case the second block of zeros starts at 4323D7 so we stop at 4323D6. Sometimes the code segment, the 401000H block starts at 0600H in the file. Armadillo gives the code section away by putting "X"s where the code segment starts. You can always check this first to make sure.
8. Press CTRL + C to copy the selected block into the clipboard
9. Choose File/Open and select the StayOnPro(undilloed).exe file to open it up
10.Leaving the cursor right where it is on the 4D block, choose menu Edit/Clipboard data/Write and press the okay button in the dialog telling you to write at offset 0.
11.Save the file
12.Stay On Pro is now almost completely un-armed. You may now easily disassemble and patch the file
13.Did you need a debugger? Nope. Say thank you GrandPa. ;-)
----------------------------------
Below is how to dump out Armadillo 1.80 - 1.8x itself and Armadillo 1.8 - 1.8x applications.
-------------------------------------------------------
1. Without any debuggers present, including SoftIce, start the protected application. The file you need is the program's name you are running followed by a number and "ProgName.tmpX". So, if you are starting "Armadillo.Exe" you'll see in the local directory, "Armadillo.tmp0". Copy this file by selecting it and pressing CTRL+C and CTRL+V
2. Rename this copied file ("Copy of Armadillo.tmp0") to read, "Armadillo1.8x(undilloed).exe".
3. Start WinHex 9.0 with the crack for it previously applied.
4. Press ALT+F9 to start the process memory selection
5. Select Armadillo.tmp0 and select it's Primary Memory
6. Go to address 00400000H. This address should always be the starting point of the windows exe image. You'll always know you are at the correct position if you see "MZ" at the address
7. Now you are going to select a large block of memory. Click next to the 00400000H address in the cell that shows 4D press and hold the shift key down while pressing page down (this works the quickest). Select the block all the way to and including address 41894B.
8. Press CTRL + C to copy the selected block into the clipboard.
9. Choose File/Open and select the Armadillo1.8x(undilloed).exe file to open it up
10.Leaving the cursor right where it is on the 4D block, choose menu Edit/Clipboard data/Write and press the okay button in the dialog telling you to write at offset 0
11.Save the file
12.Armadillo 1.8x or the program it's protecting is almost un-armed
13.Unfortunately, starting the program this time results in an exception. What happened? The program's header is modified to go to a different starting code location. What do we do to find a code location? Follow on...
14.In this case we'll need W32DASM so fire it up
15.Disassemble the file Armadillo1.8x(undilloed).exe. Neat huh?
16.Now the trick is to find the starting location of the program. Experience tells me almost all windows entry points have the functions GetCommandLineA, GetStartupInfoA, GetModuleHandleA, GetVersion, and ExitProcess. For this particular program do a search for GetVersion. Ignore the first and second find since that is only a reference to the import table. The third find isn't a correct match either, this is GetVersionEx which is not what we are looking for. The fourth find will be the correct location
17.Now look around. In this function do we have some or all of the above functions. Yes we do, this is most likely the windows entry point
18.The next step would be to trace backwards (move up) until a NOP or RET is found. In this case the RET is at 412D3D. That makes the entry point: 412D40. Close down W32DASM.
19.So let's plug this in and give it a try. Start WinHex up and load in the Armadillo1.8x(unarmed).exe file
20.Location E0 starts the program header. At location 108H is the entry point called by windows when the program starts
21.At 108H we are going to write the 32-bit number of the entry point but we have to do a little math first.
22.The entry point is 412D40. Subtract the virtual memory offset to get the correct value. This one loads in at 400000H. So 412D40-400000H=12D40. Make this a 32-bit number for ease and now it's 00012D40.
23.Large numbers (words, doublewords) in windows are normally written backwards for this reason the number written will be 40 2D 01 00. Write 40H @ file offset 108H, 2D @ 109H, 01H @ 10AH and 00H @ 10BH and save the file.
24.Armadillo 1.8x or it's protected program is now completely un-armed
25.Did you need a debugger? Nope. Say thank you GrandPa. ;-)