Armageddon v1.3.3 by CondZero
Armageddon is an Armadillo unpacking tool designed specifically to deal with the many protection features available in versions 3.78 thru 5.42
This Tool can strip Armadillo Protection from protected Exe's / Dll's
Tested on
---------
Various applications protected by versions 3.78 through 5.42
under Win2k, win2k3 Server, XP SP1 & SP2 and vista 32 bit. If you experience any problems running the program, you may need to download and install Microsoft Visual C++ 2005 Redistributable Package (x86) available here: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
Supported Features
------------------
Standard Protection
Minimum Protection
Memory Patching
Debugblocker
CopyMemII
Import Elimination
Import Redirection (Emulation)
Strategic Code Splicing
Nanomites
Shockwave Flash + applications that utilize overlays (minimize size option required)
Hardware locking (Standard / Enhanced Fingerprint support)
DLL support
-----------
Requires included dll loader.exe to load the target dll
Open / Save dialogs updated for exe / dll.
Full imports rebuilding
-----------------------
ARTeam Import Reconstructor 1.1.2 (ARImpRec.dll) by Nacho_dj
Coded in Delphi 7 Enterprise.
It performs the task of rebuilding the import table in a new section.
The main feature is that it ignores all thunks not valid found between valid ones, and then it rearranges the imports found, rebuilding for every module an only array of thunks. Thus, it can rebuild shuffled IAT.
* New - Reduce size of a dumped module
--------------------------------------
Now ARImpRec includes ARMinSiz code:
Tool designed for reducing drastically the size of Armadillo targets.
It deletes all sections added by the wrapper, adjusting the PE header.
It rebuilds the resources section.
It fixes relocation data in PE header. --> Only working for Armadillo,
in this release. When it exists, appends the overlay at the end of the optimized file.
* New
-----
It detects, when possible, the exact offset of the import table of virgin.exe. Then , the import table could be rebuilt in the same place where it was created in the first compilation by the developer.
This involves getting uniquely the functions used by the code section. So, it filters the imports found, choosing only the needed by the code section.
In this way the tool is providing a complete unwrapped target, free of protector code.
The import table gets rebuilt inside the existing sections.
These should have been fixed previously by the ARMinSiz.dll module.
It fixes relocation data in PE header, whatever the function called is.
* New dump .pdata section
-------------------------
Have you ever been curious about the internal data contained in this section?
This new option will decrypt / decompress this section and dump it. You will notice the security.dll (a.k.a ArmAccess.dll) plus a whole lot more.
Check it out!
Known issues
------------
When using the SearchAndRebuildImportsNoNewSection@24 it takes considerably more time than using the SearchAndRebuildImports@24 function, because of the process of filtering all needed apis among all the ones found.
Better don't use it in DLL. Some issues should be fixed before that.
In DLLs, The wrapper inserts some code in the .text section, and all targets contain references to some code in deleted Armadillo sections, so they won't get loaded properly.
To be done
----------
Rebuilding import table by ordinal.
Fixing DLLs issue to get reduced in size too.
* New
* Code Splicing:
----------------
Now the default option, although can be overridden by selecting Redirect CS
code splices (original default behaviour).
Integrated ArmInline revirgin's code protected by 'Strategic Code Splicing' by recursively identifying and removing the redundant opcodes, rather than dumping and patching in a VirtualAlloc. It is very clean and adds nothing to the size of your dump.
------ Code Splicing Specific:
Armageddon automatically detects the VM address and size and sends
this information to the Remove Code Splicing engine.
The log will display a running total of fixed splices. Once Armageddon has identified a splice, it will remove the redundant instructions, reassemble it, and patch directly into where it should be (over the redirecting JMP). Once Armageddon says it's done the resulting 'Target Code' memory is (in theory) identical to what it would be if the app was built without code-splicing. Hence the 'splices' segment is now redundant and need not be retained. The module is now ready to dump.
If Armageddon reports any warnings or errors, it may indicate that
there is a problem and you should either rerun the target or elect to use
the redirect code splices option (which used to be the default).
Occasionally the Code Splicing engine will fail when supplied with some code that contained a redundant opcode before Armadillo even got to it (and hence it doesn't know how much dead code to remove). Often (but not always) you will be alerted of any such failures, so make sure you check the log window before assuming everything went okay. Very occasionally Armageddon will think everything has gone okay when one or more code splices is incorrect. In either case, the number of remaining problem splices should be small and manual repair shouldn't take much effort.
The location of any such residues can usually be found by running the process after Armageddon has worked on it again (after you're finished dumping it) via the redirect code splices option and saving the dump to another name. Open this dump in your debugger to analyze the problem addresses and check for any exceptions that don't otherwise occur.
* New
Detach from (child) process
---------------------------
You can elect to detach from the running child process by selecting the radio button for the type of detach (DebugBlocker vs CopyMemII).
You must have WinXP or greater OS to use this option!!
Click "Cancel" to bypass creating a dump.
Note: If using Ollydbg to attach, make sure you invoke a fresh instance of Ollydbg AFTER Armageddon issues the detach message.
DO NOT CLOSE ARMAGEDDON when detaching!!!
Make sure no other instances of the target process are running prior to invoking Armageddon.
You may have to manually kill any "Active" target processes after using this option!!
SPECIAL NOTE:
You can elect to resolve nanomites prior to detaching. Very Useful!!
A messagebox will appear asking to resolve nanomites to continue.
Press OK to resolve or Cancel to bypass this feature.
This will resolve nanomites directly to the target process's memory.
Make sure you check the "Log" nanomites option prior to detaching if you wish
to resolve nanomites.
Known issues when detaching
---------------------------
Some applications are resistant to detaching. Because of this, Armageddon
sets the PAGE_GUARD protection attribute on the .text (Code) section.
When attaching to a process consider the following:
1. After attaching with a new instance of Ollydbg and reaching the system breakpoint (NTDLL.DLL), go into Olly's Threads window and "Resume" activate the main thread which is suspended.
You may have to do one of two things if the target application does not
respond normally after RUN:
1. Set a memory breakpoint on access to the .text section prior to running
the attached target, or
2. Set the .text section to "Full Access" in Olly's Memory Map window
* New
Override Hardware Fingerprint
-----------------------------
Use this feature to specifically change your machine's:
1. Standard HW Fingerprint
2. Enhanced HW Fingerprint
Enter a valid value in the appropriate text box, or use both if necessary,
in the format: XXXX-XXXX.
This value will be patched (changed) to the target process memory.
Nanomites processing
--------------------
Admiral's nanolib.dll, Rwb32.bin (handler), NanoView.exe (viewer)
* Nanomites:
Locates all of the Nanomites in a dump and uses the packed exe to analyse them, generating a Nanomite table containing all the necessary information to produce a working dump. Appends a small piece of vector exception handling code at the end of your dump which will deal with the Nanomites on the fly.
* New - Resolve Nanomites
-------------------------
This feature will automatically assemble instructions from the saved *.nan file which match the logged nanomites and patch the saved dump file (optionally patch the target process when option detached is selected)
for all recorded (logged) nanomites + certain nanomites that follow
any "TEST" instructions. Your sucess rate of resolving nanomites is dependant on the level of nanomites encountered while "Testing" (logging) the application. Any additional unresolved nanomites will need to be patched manually using your debugger plus the saved (*.nan) nanomite file for reference. Keep in mind that a dumped file may behave slightly differently from the packed / protected target. Nanomites that executed for the target, may not execute for the dumped file and vice versa!!
To use, do the following:
Dump application + analyze nanomites as normal (1st pass). If necessary,
you may need to rerun the target to specifically analyze nanomites. In
this case, skip creating the dump (press cancel).
Note: If redirecting code splices, then this option s/b checked
when analyzing nanomites!!
Save the analyzed nanomites to a *.nan file.
Rerun Armageddon for the target application skipping the create dump request.
check log nanomites option (2nd pass). Target application will launch.
Use all features / functions of the target application that may contain sections of code with imbedded nanomites. Do this as much as possible
before exiting the application. The nanomites processed are saved to
an internal sorted / unique address array. The log window displays the
number of logged nanomites encountered.
Make sure that "Log" nanomites option is checked.
Now load your saved *.nan file and press the "Resolve" button.
Armageddon will automatically apply the necessary assembled jmp instructions to their respective addresses based on the logged entries.
Make sure you select the fixed (IAT) dump.
You can choose to use the Resolve feature as many times as you want
to the same fixed dump file. The instructions (if already exist) are simply
overwritten.
You can also choose to repair the dump after resolving.
NanoView.exe
------------
Admiral's tool to view a *.nan file. Shows entire nano table
in listview that is appended to repaired dump file.
Unsupported Features
--------------------
Hardware locking (Standard / Enhanced Fingerprint support)
Security/Temporary keys
Expired Application (need to use Trial-Reset or TrashReg to
delete expired key)
Secured Sections
Custom Implementations
Nanomites
---------
This functionality was borrowed from Admiral's excellent Arminline
tool (latest Final build) and integrated into this tool. Some of the words
that follow are included from his Readme.txt file:
A separate external dll (Nanolib.dll) does the work of analyzing the target
process to determine valid vs invalid nanomites and generates an
internal table of valid nanomites which can be saved for later
use and/or loaded from a previous save.
The repair dump function appends a small piece of vector exception handling code into your dump which will deal with the Nanomites on the fly as well as
appending the internal nanomite table to produce a working dump.
If you suspect nanomites or want to troubleshoot existing nanomites, check the
log nanomites checkbox. This will log all actual nanomites as they are processed in a running target.
If you know or aren't sure of nanomites, check the analyze nanomites checkbox
which locates all of the Nanomites in a dump and uses the packed exe to analyse them on the fly (most accurate).
Nanomite File Format (*.nan)
----------------------------
Each Nanomite is described by the following structure:
struct Nanomite {
long Address
long Destination
long Size
long JumpType
}
The first dword in the file is the number of Nanomites described in the rest of the file. It is immediately followed by an array (with that number of elements) of the above structure. Once you've extracted this array you should be at EOF. Here are the details on the structure:
Address: The virtual address of the Nanomite. Each one of these should point to a 0xCC in your dump.
Destination: The virtual address to which the Jcc jumps (if the jump is taken).
Size: The size of the instruction in bytes (including the Jcc opcode and the relative/absolute address). I'm not entirely sure how this made it into the structure, if it's useful or even valid. On examining a few .nan files, this field seems to contain some strange-looking values. You shouldn't need to use this field, but if you choose to, be careful.
JumpType: An enumeration that describes what type of Jcc you're looking at. The values are:
JUnknown = 0
NotNanomite = 1
JMP = 2
JNZ = 3
JZ = 4
JB = 5
JBE = 6
JA = 7
JNB = 8
JG = 9
JGE = 10
JL = 11
JLE = 12
JP = 13
JPE = 14
JNP = 15
JPO = 16
JS = 17
JNS = 18
JCXZ = 19
JNCXZ = 20
JC = 21
JNC = 22
JO = 23
JNO = 24
A word of warning: Don't be tempted to iterate through the array, assemble the jumps and patch them into the dump. Although this will fix all the Nanomites, it will also destroy some other instructions (namely 0xCCs that weren't put there by Armadillo). This is because the array contains information for every occurrence of the 0xCC byte, not only ones which are Nanomites. Unfortunately it is impossible to determine (from a dead-listing) which Nanomites are genuine, so you're gonna have to either use a loader or dabble in VEH (unless you can think of a better way).
I'm aware that this file format could have been made a lot cleaner and smaller, but I had my reasons for sticking to unsigned longs.
* New DLL only - "DLL Use CreateThread API"
-------------------------------------------
For most dll's, the internal default logic should work (i.e. a memory
breakpoint on access to the .text section directly. No Software BP
is set on the CreateThread API.) Some dll's will not respond to this
treatment (i.e. They may hang on "Tracing to OEP" and simply do
nothing). In these cases, check the option for "DLL Use CreateThread"
and the problem should be resolved.
Other considerations
--------------------
Make sure all supplied components reside in the same folder!
You cannot use the minimize size option with the redirect code splices
option (mutually exclusive). Nor should you use the repair dump (nanomite VEH stub option) when using the minimize option.
The tool works fairly fast and efficiently,
but should the target application hang, you can terminate it gracefully,
since the GUI launches a separate thread to run the target process.
Some Notes
----------
As with any tool that removes protection, the resultant dump may
still not work properly. You may need to include the ArmAccess.dll in
the target application's folder. You also may need to consider custom protections and implementations.
Known Issues
------------
You are encouraged to use tools like ArmaDetach or ArmadilloFindProtected to determine version / features/ protection options.
While much effort has been made to determine Armadillo PE section names, it may be necessary to rename some of them before using this tool.
Should the Import Reconstructor fail, i.e. return code > 0, a workaround is (Rerun the program, when the program asks you to dump / save, press "Cancel")
to perform the dump and IAT yourself using a 3rd party dump tool (LordPE or similar) and ImpREC (or Magic_h2001's Universal Import fixer - UIF) to rebuild the imports.
Should the application appear to hang (do nothing) it could be that the process is taking some time to unpack, a resource conflict, a compatibility issue with your OS or, the version of Armadillo is not supported! In some cases, if you try again, it may work due to available resources (memory).
In some cases, it may be necessary to rerun the target application again
for strategic code splicing.
Note: Make sure there are no other instances of the target program running in Windows Task manager before proceeding.
Version History
---------------
June 2008 - v1.3.3
+ hotfix to resolve strategic code splicing issue
for last inactive MOV EDI,EDI instructions and
issue a warning message
===========================================
May 2008 - v1.3.2
+ hotfix to resolve nanomites
+ relocate base address of Nanolib.dll
===========================================
May 2008 - v1.3.1
+ hotfix to resolve CreateProcess API problem
in Nanolib.dll for target work directory
===========================================
May 2008 - v1.3
+ resolve relocations for dll files (Nacho_dj)
+ added new option to minimize the size of a dumped file (Nacho_dj)
Particulary useful for Shockwave Flash + applications that make use of an overlay. Of course this will also rebuild a normal target's PE structure.
+ improved import rebuilder v1.1.2 (Nacho_dj)
+ added new option to "Resolve" nanomite INT3 instructions with their original
jmp instructions and patch directly to the dumped target. Requires use of the nanomite "Analyze" + "Log" options. Note: you can also elect to resolve nanomites directly to a target process's memory if you elect to detach!!
+ integrated Admiral's Strategic Code Splicing removal engine into the tool.
This is now the (default) behaviour and can be overridden with new option to
redirect CS (code splices) instead
+ new option to dump / decrypt / decompress the .pdata section to a binary file
+ new option to detach from a process (choose: DebugBlocker or CopyMemII)
+ resolve problem for ArmAccess dll function:Installkey missing error msg
+ add support for UPX compressed single process targets
+ new option to change your Standard / Enhanced Hardware Fingerprint ID
+ resolve some minor bugs
===========================================
March 2008 - v1.2g [gabor edition]
+ add warning message for OEP call return VA not from Armadillo VM
Note: Informational, not usually relevant for dll's or exe's with copymem2,
but may be useful for troubleshooting invalid OEP's resulting
from custom implementations and/or packing / compressing of a file
prior to being protected by Armadillo
+ fix problem with copymem2 search string error
+ fix problem with createdump on error
===========================================
March 2008 - v1.2
+ improved PE section name resolution for internal use (thank's Ghandi)
+ improved ARTeam Import Reconstructor v1.2
===========================================
February 2008 - v1.1
+ added dll support (dll loader.exe)
+ added option "Use OpenMutext trick" to force a single process. Use only if normal "debug blocker" processing fails. This would occur when a parent process launches the child process, but doesn't debug the child process (i.e. use the WaitForDebugEvent API)
+ improve IAT elimination functionality
+ includes updated ARTeam Import Reconstructor
===========================================
February 2008 - v1.0 (initial release)
Born - 11/13/2007
Download: Armageddon_v133_by_CondZero.rar 340.91 KB
This Tool can strip Armadillo Protection from protected Exe's / Dll's
Tested on
---------
Various applications protected by versions 3.78 through 5.42
under Win2k, win2k3 Server, XP SP1 & SP2 and vista 32 bit. If you experience any problems running the program, you may need to download and install Microsoft Visual C++ 2005 Redistributable Package (x86) available here: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
Supported Features
------------------
Standard Protection
Minimum Protection
Memory Patching
Debugblocker
CopyMemII
Import Elimination
Import Redirection (Emulation)
Strategic Code Splicing
Nanomites
Shockwave Flash + applications that utilize overlays (minimize size option required)
Hardware locking (Standard / Enhanced Fingerprint support)
DLL support
-----------
Requires included dll loader.exe to load the target dll
Open / Save dialogs updated for exe / dll.
Full imports rebuilding
-----------------------
ARTeam Import Reconstructor 1.1.2 (ARImpRec.dll) by Nacho_dj
Coded in Delphi 7 Enterprise.
It performs the task of rebuilding the import table in a new section.
The main feature is that it ignores all thunks not valid found between valid ones, and then it rearranges the imports found, rebuilding for every module an only array of thunks. Thus, it can rebuild shuffled IAT.
* New - Reduce size of a dumped module
--------------------------------------
Now ARImpRec includes ARMinSiz code:
Tool designed for reducing drastically the size of Armadillo targets.
It deletes all sections added by the wrapper, adjusting the PE header.
It rebuilds the resources section.
It fixes relocation data in PE header. --> Only working for Armadillo,
in this release. When it exists, appends the overlay at the end of the optimized file.
* New
-----
It detects, when possible, the exact offset of the import table of virgin.exe. Then , the import table could be rebuilt in the same place where it was created in the first compilation by the developer.
This involves getting uniquely the functions used by the code section. So, it filters the imports found, choosing only the needed by the code section.
In this way the tool is providing a complete unwrapped target, free of protector code.
The import table gets rebuilt inside the existing sections.
These should have been fixed previously by the ARMinSiz.dll module.
It fixes relocation data in PE header, whatever the function called is.
* New dump .pdata section
-------------------------
Have you ever been curious about the internal data contained in this section?
This new option will decrypt / decompress this section and dump it. You will notice the security.dll (a.k.a ArmAccess.dll) plus a whole lot more.
Check it out!
Known issues
------------
When using the SearchAndRebuildImportsNoNewSection@24 it takes considerably more time than using the SearchAndRebuildImports@24 function, because of the process of filtering all needed apis among all the ones found.
Better don't use it in DLL. Some issues should be fixed before that.
In DLLs, The wrapper inserts some code in the .text section, and all targets contain references to some code in deleted Armadillo sections, so they won't get loaded properly.
To be done
----------
Rebuilding import table by ordinal.
Fixing DLLs issue to get reduced in size too.
* New
* Code Splicing:
----------------
Now the default option, although can be overridden by selecting Redirect CS
code splices (original default behaviour).
Integrated ArmInline revirgin's code protected by 'Strategic Code Splicing' by recursively identifying and removing the redundant opcodes, rather than dumping and patching in a VirtualAlloc. It is very clean and adds nothing to the size of your dump.
------ Code Splicing Specific:
Armageddon automatically detects the VM address and size and sends
this information to the Remove Code Splicing engine.
The log will display a running total of fixed splices. Once Armageddon has identified a splice, it will remove the redundant instructions, reassemble it, and patch directly into where it should be (over the redirecting JMP). Once Armageddon says it's done the resulting 'Target Code' memory is (in theory) identical to what it would be if the app was built without code-splicing. Hence the 'splices' segment is now redundant and need not be retained. The module is now ready to dump.
If Armageddon reports any warnings or errors, it may indicate that
there is a problem and you should either rerun the target or elect to use
the redirect code splices option (which used to be the default).
Occasionally the Code Splicing engine will fail when supplied with some code that contained a redundant opcode before Armadillo even got to it (and hence it doesn't know how much dead code to remove). Often (but not always) you will be alerted of any such failures, so make sure you check the log window before assuming everything went okay. Very occasionally Armageddon will think everything has gone okay when one or more code splices is incorrect. In either case, the number of remaining problem splices should be small and manual repair shouldn't take much effort.
The location of any such residues can usually be found by running the process after Armageddon has worked on it again (after you're finished dumping it) via the redirect code splices option and saving the dump to another name. Open this dump in your debugger to analyze the problem addresses and check for any exceptions that don't otherwise occur.
* New
Detach from (child) process
---------------------------
You can elect to detach from the running child process by selecting the radio button for the type of detach (DebugBlocker vs CopyMemII).
You must have WinXP or greater OS to use this option!!
Click "Cancel" to bypass creating a dump.
Note: If using Ollydbg to attach, make sure you invoke a fresh instance of Ollydbg AFTER Armageddon issues the detach message.
DO NOT CLOSE ARMAGEDDON when detaching!!!
Make sure no other instances of the target process are running prior to invoking Armageddon.
You may have to manually kill any "Active" target processes after using this option!!
SPECIAL NOTE:
You can elect to resolve nanomites prior to detaching. Very Useful!!
A messagebox will appear asking to resolve nanomites to continue.
Press OK to resolve or Cancel to bypass this feature.
This will resolve nanomites directly to the target process's memory.
Make sure you check the "Log" nanomites option prior to detaching if you wish
to resolve nanomites.
Known issues when detaching
---------------------------
Some applications are resistant to detaching. Because of this, Armageddon
sets the PAGE_GUARD protection attribute on the .text (Code) section.
When attaching to a process consider the following:
1. After attaching with a new instance of Ollydbg and reaching the system breakpoint (NTDLL.DLL), go into Olly's Threads window and "Resume" activate the main thread which is suspended.
You may have to do one of two things if the target application does not
respond normally after RUN:
1. Set a memory breakpoint on access to the .text section prior to running
the attached target, or
2. Set the .text section to "Full Access" in Olly's Memory Map window
* New
Override Hardware Fingerprint
-----------------------------
Use this feature to specifically change your machine's:
1. Standard HW Fingerprint
2. Enhanced HW Fingerprint
Enter a valid value in the appropriate text box, or use both if necessary,
in the format: XXXX-XXXX.
This value will be patched (changed) to the target process memory.
Nanomites processing
--------------------
Admiral's nanolib.dll, Rwb32.bin (handler), NanoView.exe (viewer)
* Nanomites:
Locates all of the Nanomites in a dump and uses the packed exe to analyse them, generating a Nanomite table containing all the necessary information to produce a working dump. Appends a small piece of vector exception handling code at the end of your dump which will deal with the Nanomites on the fly.
* New - Resolve Nanomites
-------------------------
This feature will automatically assemble instructions from the saved *.nan file which match the logged nanomites and patch the saved dump file (optionally patch the target process when option detached is selected)
for all recorded (logged) nanomites + certain nanomites that follow
any "TEST" instructions. Your sucess rate of resolving nanomites is dependant on the level of nanomites encountered while "Testing" (logging) the application. Any additional unresolved nanomites will need to be patched manually using your debugger plus the saved (*.nan) nanomite file for reference. Keep in mind that a dumped file may behave slightly differently from the packed / protected target. Nanomites that executed for the target, may not execute for the dumped file and vice versa!!
To use, do the following:
Dump application + analyze nanomites as normal (1st pass). If necessary,
you may need to rerun the target to specifically analyze nanomites. In
this case, skip creating the dump (press cancel).
Note: If redirecting code splices, then this option s/b checked
when analyzing nanomites!!
Save the analyzed nanomites to a *.nan file.
Rerun Armageddon for the target application skipping the create dump request.
check log nanomites option (2nd pass). Target application will launch.
Use all features / functions of the target application that may contain sections of code with imbedded nanomites. Do this as much as possible
before exiting the application. The nanomites processed are saved to
an internal sorted / unique address array. The log window displays the
number of logged nanomites encountered.
Make sure that "Log" nanomites option is checked.
Now load your saved *.nan file and press the "Resolve" button.
Armageddon will automatically apply the necessary assembled jmp instructions to their respective addresses based on the logged entries.
Make sure you select the fixed (IAT) dump.
You can choose to use the Resolve feature as many times as you want
to the same fixed dump file. The instructions (if already exist) are simply
overwritten.
You can also choose to repair the dump after resolving.
NanoView.exe
------------
Admiral's tool to view a *.nan file. Shows entire nano table
in listview that is appended to repaired dump file.
Unsupported Features
--------------------
Hardware locking (Standard / Enhanced Fingerprint support)
Security/Temporary keys
Expired Application (need to use Trial-Reset or TrashReg to
delete expired key)
Secured Sections
Custom Implementations
Nanomites
---------
This functionality was borrowed from Admiral's excellent Arminline
tool (latest Final build) and integrated into this tool. Some of the words
that follow are included from his Readme.txt file:
A separate external dll (Nanolib.dll) does the work of analyzing the target
process to determine valid vs invalid nanomites and generates an
internal table of valid nanomites which can be saved for later
use and/or loaded from a previous save.
The repair dump function appends a small piece of vector exception handling code into your dump which will deal with the Nanomites on the fly as well as
appending the internal nanomite table to produce a working dump.
If you suspect nanomites or want to troubleshoot existing nanomites, check the
log nanomites checkbox. This will log all actual nanomites as they are processed in a running target.
If you know or aren't sure of nanomites, check the analyze nanomites checkbox
which locates all of the Nanomites in a dump and uses the packed exe to analyse them on the fly (most accurate).
Nanomite File Format (*.nan)
----------------------------
Each Nanomite is described by the following structure:
struct Nanomite {
long Address
long Destination
long Size
long JumpType
}
The first dword in the file is the number of Nanomites described in the rest of the file. It is immediately followed by an array (with that number of elements) of the above structure. Once you've extracted this array you should be at EOF. Here are the details on the structure:
Address: The virtual address of the Nanomite. Each one of these should point to a 0xCC in your dump.
Destination: The virtual address to which the Jcc jumps (if the jump is taken).
Size: The size of the instruction in bytes (including the Jcc opcode and the relative/absolute address). I'm not entirely sure how this made it into the structure, if it's useful or even valid. On examining a few .nan files, this field seems to contain some strange-looking values. You shouldn't need to use this field, but if you choose to, be careful.
JumpType: An enumeration that describes what type of Jcc you're looking at. The values are:
JUnknown = 0
NotNanomite = 1
JMP = 2
JNZ = 3
JZ = 4
JB = 5
JBE = 6
JA = 7
JNB = 8
JG = 9
JGE = 10
JL = 11
JLE = 12
JP = 13
JPE = 14
JNP = 15
JPO = 16
JS = 17
JNS = 18
JCXZ = 19
JNCXZ = 20
JC = 21
JNC = 22
JO = 23
JNO = 24
A word of warning: Don't be tempted to iterate through the array, assemble the jumps and patch them into the dump. Although this will fix all the Nanomites, it will also destroy some other instructions (namely 0xCCs that weren't put there by Armadillo). This is because the array contains information for every occurrence of the 0xCC byte, not only ones which are Nanomites. Unfortunately it is impossible to determine (from a dead-listing) which Nanomites are genuine, so you're gonna have to either use a loader or dabble in VEH (unless you can think of a better way).
I'm aware that this file format could have been made a lot cleaner and smaller, but I had my reasons for sticking to unsigned longs.
* New DLL only - "DLL Use CreateThread API"
-------------------------------------------
For most dll's, the internal default logic should work (i.e. a memory
breakpoint on access to the .text section directly. No Software BP
is set on the CreateThread API.) Some dll's will not respond to this
treatment (i.e. They may hang on "Tracing to OEP" and simply do
nothing). In these cases, check the option for "DLL Use CreateThread"
and the problem should be resolved.
Other considerations
--------------------
Make sure all supplied components reside in the same folder!
You cannot use the minimize size option with the redirect code splices
option (mutually exclusive). Nor should you use the repair dump (nanomite VEH stub option) when using the minimize option.
The tool works fairly fast and efficiently,
but should the target application hang, you can terminate it gracefully,
since the GUI launches a separate thread to run the target process.
Some Notes
----------
As with any tool that removes protection, the resultant dump may
still not work properly. You may need to include the ArmAccess.dll in
the target application's folder. You also may need to consider custom protections and implementations.
Known Issues
------------
You are encouraged to use tools like ArmaDetach or ArmadilloFindProtected to determine version / features/ protection options.
While much effort has been made to determine Armadillo PE section names, it may be necessary to rename some of them before using this tool.
Should the Import Reconstructor fail, i.e. return code > 0, a workaround is (Rerun the program, when the program asks you to dump / save, press "Cancel")
to perform the dump and IAT yourself using a 3rd party dump tool (LordPE or similar) and ImpREC (or Magic_h2001's Universal Import fixer - UIF) to rebuild the imports.
Should the application appear to hang (do nothing) it could be that the process is taking some time to unpack, a resource conflict, a compatibility issue with your OS or, the version of Armadillo is not supported! In some cases, if you try again, it may work due to available resources (memory).
In some cases, it may be necessary to rerun the target application again
for strategic code splicing.
Note: Make sure there are no other instances of the target program running in Windows Task manager before proceeding.
Version History
---------------
June 2008 - v1.3.3
+ hotfix to resolve strategic code splicing issue
for last inactive MOV EDI,EDI instructions and
issue a warning message
===========================================
May 2008 - v1.3.2
+ hotfix to resolve nanomites
+ relocate base address of Nanolib.dll
===========================================
May 2008 - v1.3.1
+ hotfix to resolve CreateProcess API problem
in Nanolib.dll for target work directory
===========================================
May 2008 - v1.3
+ resolve relocations for dll files (Nacho_dj)
+ added new option to minimize the size of a dumped file (Nacho_dj)
Particulary useful for Shockwave Flash + applications that make use of an overlay. Of course this will also rebuild a normal target's PE structure.
+ improved import rebuilder v1.1.2 (Nacho_dj)
+ added new option to "Resolve" nanomite INT3 instructions with their original
jmp instructions and patch directly to the dumped target. Requires use of the nanomite "Analyze" + "Log" options. Note: you can also elect to resolve nanomites directly to a target process's memory if you elect to detach!!
+ integrated Admiral's Strategic Code Splicing removal engine into the tool.
This is now the (default) behaviour and can be overridden with new option to
redirect CS (code splices) instead
+ new option to dump / decrypt / decompress the .pdata section to a binary file
+ new option to detach from a process (choose: DebugBlocker or CopyMemII)
+ resolve problem for ArmAccess dll function:Installkey missing error msg
+ add support for UPX compressed single process targets
+ new option to change your Standard / Enhanced Hardware Fingerprint ID
+ resolve some minor bugs
===========================================
March 2008 - v1.2g [gabor edition]
+ add warning message for OEP call return VA not from Armadillo VM
Note: Informational, not usually relevant for dll's or exe's with copymem2,
but may be useful for troubleshooting invalid OEP's resulting
from custom implementations and/or packing / compressing of a file
prior to being protected by Armadillo
+ fix problem with copymem2 search string error
+ fix problem with createdump on error
===========================================
March 2008 - v1.2
+ improved PE section name resolution for internal use (thank's Ghandi)
+ improved ARTeam Import Reconstructor v1.2
===========================================
February 2008 - v1.1
+ added dll support (dll loader.exe)
+ added option "Use OpenMutext trick" to force a single process. Use only if normal "debug blocker" processing fails. This would occur when a parent process launches the child process, but doesn't debug the child process (i.e. use the WaitForDebugEvent API)
+ improve IAT elimination functionality
+ includes updated ARTeam Import Reconstructor
===========================================
February 2008 - v1.0 (initial release)
Born - 11/13/2007
Download: Armageddon_v133_by_CondZero.rar 340.91 KB
0 comments:
Post a Comment
We would appreciate if you as readers of our blog, show us some feedback by signing up to this site with Friend Connect.
This will encourage us to publish updates in the future.