Newer Protected files!

-----------------------------------------------------------------------
VMed Version!

API SetEvent+14 | DWORD AntiDump Check!

DLL Kernel32 FirstSection+10 | SizeOfRawData | DWORD AntiDump Check!

EDIT: It can also access other PE locations on Win7

-----------------------------------------------------------------------

So the script will not redirect this SetEvent and Kernel ADs automaticly!

So you will also get only a error message if you test your unpacked files
on a other OS or if your kernel32 dll was loaded with a other base [ASLR OS].

If these ADs was not fixed and your dump used VM Entrys from code to WL section
then these ADs will mostly checked and if the static addresses and values are not
there then you get a crash.You get no crash if both are still the same.

How to check & fix?

-----------------------------------------------------------------------
XP System situation: After Check & Fix Method

After your file is unpacked then set HWBP access on [SetEvent+14] API and also
a HWBP access on Kernel32.dll [FirstSections+10] and run.Be sure that also VM
Entrys
are used in your dump if not = no access of course.If now both addresses or one of
them
get a accesss then write down the address where you are in the VM + register values
and
hook this address to your own patch location and create a check & patch code.

How to redirect to prevent after check & fix?

-----------------------------------------------------------------------
So you can also redirect them both before but for this you need to find the VM
Entry in WL
code which does read and calculate the value of SetEvent & Kernel32.Also you need
to find the
Kernel32 Base store location.

1.) Find VM Entry: Use my "Catch and Log Export and GPA API callers from WL Code
script.txt"
script and check the log and find SetEvent API log.Use the last
one which
was found = VM Address code before it happen.If you stop on the
logged address
then you can see the SetEvent API in eax.Now change eax to a own
location address
of your patch code and at this patch code you also fill the
opcodes of the
entire SetEvent API into = Redirected now!

2.) Kernel32 Loca: To find the store location of the kernelbase you can set a HWBP
on the target
[Import Table address+10] so WL does not read the kernelbase
from system so it just
read a own kernel import and does some basic address check + PE
check to get the
base and after this WL does store this kernelbase into any WL
location.

So if you have found now both of them then you can start.So the SetEvent Entry does
also handle the
kernel part at once so this is good for us.

Fix Both at the same time: Now if you reach the SetEvent Entry then enter your own
patch address into
eax as I already wrote above.Now enter in the found
kernelbase location a
other address so for this you can also use the base of
your target so it also
has a PE struct.After this trace a little forward til
the command who does set
the VM Input / Output Marker to byte 01 and after this
set a HWBP on write on
this marker address and press run.Now the marker was set
to 00 = End of VM part
and now you can trace some command forward till the
return command.After this you
need now to change the entered targetbase into kernel-
location back again and
enter again the kernelbase into this location so it will
still used by WL.Also note
then you need to restore the used PE datas into your
target PE.

SetEvent Entry: - Enter your own SetEvent patch address

- Enter entire SetEvent Opcodes into your patch [address]
- Enter in kernel-location your target Base address
- Enter into VM Entry till I/O marker was set to 1
- Set HWBP write on I/O marker and run til it was set to 0
- Re-change kernel-location | [TargetBase] back to [kernelbase]

SetEvent Script: So for the script you only need to find the SetEvent VM address
and I/O address.

VM OEP | XBundler | NET FrameWork | DLL VM OEP / add Pushad | REG APIs! | Overlay |
Others | Windows 7 32 Bit
-----------------------------------------------------------------------------------
------------------------------

VM OEP: Exe
------------------
The script will not find always the right VM OEP datas mostly for RISC protected
files!Always check whether the
found and used VM OEP is right or not.Just trace forward in your unpacked file till
you step into WL section then
set memory BP access on codesection and press run and now you have to break on
codesection OEP or at the first code
command after stolen OEP bytes.If yes then VM OEP is right and working if not then
your file will crash and in this
case you have to find the VM OEP by yourself [see video exsample] or just use the
real OEP if used.

VM OEP: DLL
------------------
If your Dll used a VM OEP then it could be that you need to add a pushad command
manually before the VM push / jump
get executed.If you not do this then the stack paramter will overwritten by WL code
and your dll will fail to run and
also here just see the video!

Hint: Try to unpack your dll with a unique Base if needed!

XBundler:
------------------
If a XBundler signs was found then you get a message by the script about it but it
will not dump these files for you
so this you have to do manually on a another single process.Why?So the script could
also do this but I removed it
because there are already HWBPs / BPs used with labels.Anyway,so dumping XBunlder
files is very simple so that also you
can do this manually.So they can created "Before" or also "After" reaching the OEP
or also if your target runs = after
OEP so keep this in your mind.Check Olly log for a detailed description or check
the video!

NET FrameWork:
------------------
I also add a feature to handle NET targets on a simple way.So normaly I have
nothing to do with NET targets so they seems
to be unpacked very easy so I just added the feature to handle the WL code to bring
your NET target to OEP and also you
can use the script to bypass the HWID checks.

If the script finished then it will not create a unpacked file so this you have to
do manually!

- If you are at OEP then run the file!

- Now start WinHex tool choose the process and save it as new file
- For fixing the NET struct you can start the Themnet Unpacker tool by rongchaua
- After this you file should work and if not then check the NET resources with CFF
Explorer
- If you see some manifest data inside then remove it and save as new file

REG APIs:
------------------
If your target used REG APIs then you need to check them manually!Reg APIs of WL do
access in some cases also stored
dll / EMU dll APIs / EMU APIs from WL code.If so then you need to find the
locations and fill APIs into them which are
needed so for this you can make a extra manually patch.Other simple check Reg APIs
you can patch directly at the address
where they was found.Just check what they return in register / stack and also check
the return values they are using.

Overlay:
------------------
Some targets using a overlay which you need to dump and add again on your dumped
file so for this you can use any
overlay tools which can dump / add the overlay to your dump again.There can be 2
diffrent overlay versions!The first
is a basic overlay and the second is a advanced overlay where you need to adjust
the new pointers.Just check one of my
older tutorials / script tutorials about TM WL there you can find a advanced
exsample with a target called spotify.

Others:
------------------
Some targets can also use more or other checks to check whether the file is the
original or not.Mostly used are just some
filesize checks which can also be hidden in the VM itself and many more.Be smart
and find the reason.

WL CRC:
------------------
Find right VM Entry and play the Input Output game to find the CRC handling
routine.If you found it then at the end
after checking own WL code comes a check what checks a calculated DWORD in eax with
a address in code.If same = all ok
if not = wrong CRC.In this case you can patch the check directly or just exit this
code and you come out on a next VM
Entry and there you can set in eax the value 1.1 = CRC OK and 0 = CRC wrong.

R6002 Error
------------------------
If you get this error after unpacking then you can try to find the check inside the
target.Reason for this are the
changed Char flags of codesection from not writeable to writeable.Just set HWBP
access on Char of your codesection to
find where it checks.The code can look like this exsample.....

8B4024 MOV EAX,DWORD PTR DS:[EAX+24] ; Section char of

codesec to eax
004185AA C1E8 1F SHR EAX,1F
004185AD F7D0 NOT EAX
004185AF 83E0 01 AND EAX,1 ; If eax 0 then
R6002 Error

Special Script Feature:

------------------------
In some very very rarly cases it can happen that your unpacked file does crash
because some direct API commands was fixed
wrong!Normal targets using sortet API jump tables like this.....

JMP DWORD [ADDR]

JMP DWORD [ADDR]
JMP DWORD [ADDR]
etc

...in these rarly cases I mean these jump tables was modded by the app author to
something like this....

nop
nop
JMP DWORD [ADDR]
nop
nop
nop
nop
JMP DWORD [ADDR]
nop
JMP DWORD [ADDR]
nop
nop
etc

in your case it will look so....

nop
nop
JMP API
nop
nop
nop
nop
JMP API
nop
JMP API
nop
nop
etc

...so this are a unclean jump table and if you use the script just normaly then it
will not fixed these tables
correctly and fixed then to possible wrong addresses +/- 1 byte.So to prevent this
problems I have also added
a new jump table fixer called "Extra Direct API Commands Jump Fixer".Each time if
you unpack a file then you get
a message whether you wanna use this fixer or not.Just use it if you are unsure or
if you know that the script
fixed the tables wrong before.If you use this feature then all found direct API
commands will fixed at the found
address and will redirect to the PE_ADS section where the script created a new
clean jump table.

nop
nop
JMP API
nop
nop
nop
nop
JMP API
nop
JMP API
nop
nop

get fixed to....

nop
nop
JMP ADDR_1_to_PE_ADS
nop
nop
nop
nop
JMP ADDR_2_to_PE_ADS
nop
JMP ADDR_3_to_PE_ADS
nop
nop

///////////////////////
ADDR_1_to_PE_ADS:
JMP DWORD [ADDR]
///////////////////////
ADDR_2_to_PE_ADS:
JMP DWORD [ADDR]
///////////////////////
ADDR_3_to_PE_ADS:
JMP DWORD [ADDR]

Hidden Macros:
------------------------
In some cases there can be also used hidden macros which are VMed which then can
also check CRC values in the VM.
In this case you have also find it manually and patch it.

VM Entrys:
------------------------
So you always need to check whether your unpacked file still used VM Entrys!That
are just entrys from codesection
to WL section so this can be jmps or calls.So the script will also tell you whether
they are used or not.If they
are used then you need to check them in some cases like for some found and not
fixed "possible calls" or if WL REG
API entrys was found or if your target used some CRC checks.Just keep this in your
mind too!

Windows 7 32 Bit:
------------------------
The script does also support unpacking WL targets on Windows7 32 Bit!AntiDumps
fixing too.
So if you unpack a file on XP / Win7 then it will not run on a other OS etc then
read the first part of this text file
about SetEvent & Kernel AntiDumps.If you need a full all OS working unpacked file
and your target does check these
extra AntiDumps then you need to enable the option SETEVENT_USERDATA in the script
but just if you before got all 2
addresses!Just see the video again to see a exsample how to handle this feature!

Ok guys so that all for the moment what I have to say about it.Just have fun and
lern something with these infos.
------------------------
LCF-AT