Manually unpacking Fusion v3 build 2.0.1.0 by Bit Arts

Written by Heathcliff



Disclaimer:

This document is only for educational purposes and if you want to use the software
I recommend to buy it.



Target:

Fusionv3.exe is the name of the installation package. You might find it on
www.bitarts.com or in the package along with this tutorial. When you install it,
the main executable is installed in the program folder and it is also called
Fusionv3.exe. This is the file that needs to be unpacked , patched and cracked.
This is what Bit Arts say about Fusion v3:

A unique patent-pending utility that allows any Win32 executable to have its
dependencies directly injected into it's code including ocxs. Fusion allows
static, virtual or dynamic linking with sophisticated version control that checks
required dependencies on the target pc at runtime. Fusion also compresses &
encodes the modules by up to 70% using Assembly language for lightning fast
execution.

Fusion v3 is protected with Titanium v3 which is also a product of Bit Arts. This
is what Bit Arts say about Titanium v3:

Titanium is an ideal choice for professional software developers wishing to create
trialware protected versions of software for distribution via the internet, disk
or cd-rom. Titanium features a number of patent pending technologies that provide
a strong barrier of security around digital content without hindering operation.
Titanium utilises an intuitive graphical process flow called LicenseFlow™ to help
you turn your licensing model into a protected version of software within minutes.
Titanium has by far the greatest array of cutting edge features in the software
security market and all designed to be intuitive and easy to use. Titanium allows
full connectivity into the BitArts ChargeKey service to allow your software to be
purchased and unlocked automatically via the internet 24/7. Titanium is the
leading choice for professional software developers requiring industry leading
functionality with high levels of security.



Software and tools we need:

Windoze 98 (Only working combination)
SoftIce (NuMega Driver Studio v2.6)
IceDump v6.025
LordPE v1.31 or any other good PE Editor
IDA Pro 4 (WDASM not recommended)
ReVirgin v1.3 (v1.5 not recommended for Win 9x)
Hex Workshop v3.1 or any other good hex-editor



First a little introduction:

I, Heathcliff, am an application-programmer and do not have any cracking-
background. I am not a member of any cracking-crew either. Until a little while
ago I just downloaded cracks for the programs I use at home. I recently downloaded
Fusion v3 from Bit Arts. Unfortunately I couldn't find a crack for this neat
program. I noticed the program was protected with Titanium v3 which is protection
software from Bit Arts. So I tried to find cracks for Titanium v3. But I couldn't
find them eiter.

When I came to read messages on forum's I understood that this protection system
is not easy. So I thought this to be a challenge. I mean, I never cracked a
program before. In about a month time I read many cracking-tutorials, learned
assembly, downloaded and tested many tools like: SoftIce, Icedump, PE editors,
Revirgin and IDA Pro. I made 23 pages of notes while wandering through the code.

I finally managed to defeat all of the Titanium protections, but I am not planning
on doing more cracks, because I am dreaming in hexadecimal now and my girlfriend
is complaining that I am behind the computers all night, instead of enjoying her
or getting some sleep. I will only write this tutorial. I'll have to excuse myself
in advance for in case I write some lame comments. It is very well possible that I
didn't handle a problem in the usual way, because I haven't done this before. If
you have comments, leave the on the message board, so I can improve this tutorial.



Now let's take a look at our target. The demo version has some limitations:

Nag screen.
Time limit.
Your saved work will be renamed.



Here's a short summary of the protections that we will encounter:

There is a Titanium shield with time limit and nag-screen, which encapulates the
target executable. This shield has also anti-softice and anti-frogsice routines.
The targed executable is packed and encoded. On entering the target executable the
IT is destroyed. The target executable is mutated by titanium. The original code
needs to be restored and the mutation code must be disabled. The mutation code
contains anti-disassembling and anti-trace protection through insertion of corrupt
code and data, runtime decoding and encoding of critical code and messing with the
stack. The mutation code also contains anti-patch and anti-relocation code by
doing header-checks, using instruction-pointers for decription-keys and calling
memory-messing routines. In the target executable are registration-checks that
need to be fooled.



Step 1: Get Fusion in the debugger.

When we run the executable for the first time it might occur that nothing seems to
happen. In this case you probably have SoftIce enabled, haven't hidden it well
enough for Titanium. When Titanium detects SoftIce or FrogsIce it will freez the
task. The only working combination I got to work (thanks to +Splaj) was Windoze 98
with SoftIce 4.26.922 and IceDump 6.025. I also have a win XP machine, but it
couldn't do the job because I could not find any anti-softice-detection patch for
the XP version of SoftIce that could hide SoftIce good enough for Titanium.
Remember to have you winice.dat file changed to enable breaking on Win32API calls.
Otherwise IceDump won't work and you wouldn't be able to find the entrypoint.

When the right tools are installed you can run Fusion. After a moment you'll see a
registration screen. It shows the time you have left to use the demo version. This
registration screen is part of the Titanium shield. When you click 'Next' the
target executable will be unpacked and run. Close Fusion and run again until we
are at the regsitration screen again. To get to the entrypoint of our target we
need to break when Titanium has unpacked passed control to the target. After
setting some breakpoints GetVersion seems to be the one to BPX. When the program
hits the breakpoint hit F11 to get to the Fusion code.



Step 2: Create an executable.

This code looks like the starting point of a program. scroll a little bit up and
there's our original entrypoint at 432377h. Lets dump:

/pedump 400000 32377 c:\dumped.exe

We'll have to get back to the original assembly, but we first have to know what's
in our dump. So for now clear the breakpoint, continue Fusion and close it. We
open our PE Editor and first we load the original, protected executable. Here the
entrypoint is E7000h, which is the start of the .edata section. So we can assume
that all of the Titanium shield is in the .edata section. Now when we load our
dumped.exe. Look at the sections and note that the original entrypoint is in the
.text section. Also note that we have one extra section called .idata in our
dumped executable. This section is added by IceDump for the IT which was generated
by IceDump. Write down the adresses of this section. Virtual offset and size are
1DB000h and 3000h. And the raw offset and size are 1D1E00h and 2200h. This new IT
is useless, because it was based on the IAT of the protected executable, so we'll
have to replace it. Now look at the directories. The IT and the IAT are both in
the .edata section of Titanium and are not part of our packed target executable.
In our dumped executable the IT is already messed up, so we need to rebuild it.
We could try to set other breakpoints in the protected executable to find the
place where the original IT is decoded and destroyed, but since I am a newbie and
this job is hard enough as it is, we use the Revirgin tool of +Tsehp to do the
trick.

Start the protected executable again and when the registration screen appears BPX
GetVersion again and continue. Press 'Next' and when SoftIce breaks hit F11. We're
in Fusion again. Let's take a look at the call to GetVersion in hex:

d eip-6

It shows that a jump is made to 47132Ch. Let's have a look there:

u 47132C

This must be the IAT because of all the jumps. Scroll a bit up and scroll a bit
down. The IAT seems to be located between 471000h and 47176Fh. Now that we know
where the IAT is we can use Revirgin to recreate the IT. The only problem is, that
we can't let Fusion continue while we're Revirgining. So let's set Fusion in a
holding position.

a eip
jmp eip

Hit escape and F5 and Fusion is freezed. Now load Revirgin and select the Fusion
proces. We could let Revirgin find the IAT, but Revirgin doesn't get the size of
the IAT right. So just fill in the adress 71000 and for the size fill in 76F (you
actually need the size - 1 for Revirgin). For OEP fill in 401000 (this always
seems to work). Hit the 'IAT resolver' button and all the addresses in the IAT
are matched. Now we have to save the new IT. First uncheck the option 'Autofix
sections + IT paste'. Revirgin messes up if we don't. I think that the reason for
this is that the Virtual Offsets and Raw Offsets of the sections in our dumped
file don't match. We have to add the new IT ourselves. We want the IT to be add at
the end of the file image, so the RVA for the IT in Revirgin should be 1DB000
(remember). Now write down the size of the new IT, which is given by Revirgin.
It is 118h. Now hit the 'Generate' button. Save the file as IT.bin or something.
Now close Revirgin and hit CTRL-ALT-DEL to kill the freezed Fusion proces.

Now we'll have to add the IT. The total size of our new IT is 2972h, which is
bigger than the raw size of the IT in our dumped executable. Open the dumped
executable in Hex Workshop and remove the last 2200h bytes. Insert our Revirgined
IT at the end of the file. The total filesize is now 1D4770h. The file alignment
is set to 200h, so insert 8Eh zero's at the end of the file. Now open the PE
Editor again. Change the size of the IT to 118 (remember) and change the raw size
of the .idata section to 2A00 (2972h + 8Eh). Validate the chacksum, save the
executable and exit the PE Editor.



Step 3: Try to run the executable.

Run the executable. Damn, page fault. Return to SoftIce, enter 'exit', press
return and click away the error message. Now we need to find the point in the code
where the page-fault was made. I know there is a backtrace buffer in SoftIce, but
I don't understand it or I just can't get it work the way I want, so I had to try
another way. I just ran the dumped executable a few times and every time I breaked
on GetVersion to get into Fusion and the hit F10 until I encountered the call that
causes the page-fault. While I do that I'll write down the addresses of the calls
that fail and the next time I try I BPM X on the call that caused the fault and I
dive into that call by hitting F8. Then hitting F10 again until the fault occurs.
After a few times I am at 44CB77 CALL 4E3D22. This is weird. This is a call to
code in de .reloc section. We need to examin this code. So forget what I said
before about the way I found this code, just BPM 4E3D22 X and run the dumped
executable.

One hint before I go on: don't use F10 and F12 here so much, because here's some
weird code that SoftIce don't really understands. Look at this code. First some
registers and flags are pushed to the stack. This is obviously done to be able to
restore the state at the end of this routine. Then there is a call to the next
command, which pops from the stack. This is a contruction to get the eip in a
register and it's not a real call. Hit F8 until you have poped the eip. With the
next commands more registers are pushed to the stack and then filled with some
addresses relative to the entrypoint of this routine. Then there's a call to the
address in EBX. Now slowly walk through the code hitting F8 and see the values in
the registers change until you are at CALL EBX. Did you see the address that was
in EAX. Yes, it was 400000h, our imagebase. Might be interresting. Now we are at
CALL EBX and EBX contains the address 4E3DE0h. Let's see this routine:

u 4E3EDE0

Hmm.. straight forward routine; one loop, no calls and.. some XOR. This routine
does something on the addresses you can now see in the registers. Let's go where
we were:

u eip

Now look at the code under the CALL EBX. Very weird code. First a jump to 4E3D8Fh,
then a mess. Oh well. Hit F10. Look again. Our code is changed! The jump is now to
4E3D5Ah and the other code has changed too. This routine decodes itself
on-the-fly, so it has to contain important code. Now hit F10 until you are at the
next call. Meanwhile notice that the addesses that are played with in the
registers point to the beginning of our imagebase, which contains the PE Header,
that we have modified. When you are at the call, EAX contains 32377h. Ringing a
bell? This is our new entrypoint! So the code we just executed was to get the
entrypoint of this executable in a register. Not hit F8 until we are at
SUB EAX, EBX. EBX was just read from an address and contains E7000h now. This is
the entrypoint of the protected executable. By substracting these values the zero
flag would be set in the protected executable, because the values would be equal
then. But now, in our executable the zero flag will reset. Hit F8 two times. This
jump will be made in the original executable, but not in ours. This call should
scipt the following lines of code which I will call the 'Fuck-up-code'. This code
is only executed if executable has a changed entrypoint and moves almost randomly
a section of memory. This messes up the executable and can cause a page-fault.
So we'll skip this:

r eip=4E3D95

Now there is some playing with the stack. First a few registers are restored. Then
the address in the stack on ESP+0C is stored in EBX. Did you count all the calls,
pushing and popping on the stack? No? Well, never mind because I did it for you.
ESP+OC contains the address that was pushed when calling this routine, which is
44CB7Ch (remember 44CB77 CALL 4E3D22). This is weird. Why does this routine use
the address from which it is called from? Bit Arts use this also to check if a
protection routine is called from it's original location and not by some patch
engine. But not here. In the next command the address is copied into the code at
the end of the routine, where it will be pushed on the stack again before
returning from the call. After a little bit of studying this code I understood
that this was done to be able to remove this value of the stack, if nessesary.
Then the value in ESP+04 is copied to EBX. ESP+04 contains the value of the flags
register, which was pushed on entrance of this routine. Now the flag values are
copied back to ESP+0C which was the stack position where return address of this
routine was stored. This is all done without changing the stack pointer. Getting
weirder. Now hit F8 until you are for the on the second POPFD. At this moment all
registers and flags are restored in the position as they were on entrance of this
routine. Now we are on the second POPFD. The value that is popped from the stack
here would normally contain the return address of this routine, but is now
overwritten with the flag values, so this doesn't affect the flags. By popping
this value, not only the registers and the flags, but also the stack is now in
the same state as it was just before the call to this routine was made. And that
is an important fact. All of this could have been done much easier, but it was
just done in this way by Bit Arts to try to fool us.

So everything is the same as before the call to this routine, but this routine is
not finished yet. Why? It took me a while to understand what was happening in the
next code. I only saw what was happening when I counted all the calls, pushing
and popping on the stack in the following code. It seemed that the value that was
pushed on the stack (PUSH EDI) where we are now is never popped again in this
routine. So the value that is now in EDI is later on used when we have returned
from this routine. Just like the value that is copied into EDI with the next
command. When counting the pushes and the pops we see that the following code
between the PUSHFD and POPFD is another routine. After that the original return
adress of this routine is pushed to the stack again and the routine will then
actually return.

So actually those two commands where we are now (PUSH EDI and MOVE EDI, [ESP+0C])
are executed in the context of the code that was calling this routine. In the
commands after that, the everything is pushed to the stack again, the same kind of
code as we saw at the start of the routine is done again. Hit F8 until you are at
CALL EBX. Hit F10 and see the mid-section of this routine being scrambled (or
encoded) again.

So what happened in this routine? First everything is pushed to the stack and then
the mid-section of this routine is being decoded. Then there will be checked of
the entrypoint of this executable is still original. If it is not, the memory will
be fucked. The state of the registers, flags and stack are being restored as the
were before this routine was called and then two commands are executed in the
context of the code which is calling this routine. Everything is pushed to the
stack again, the mid-section is being encoded, everthing is pulled from the stack
and the return address is pushed back to the stack. End of routine.

Now I ask again: what happened effectively in this routine if we don't count the
decoding and encoding of the routine itself and we don't count the header-
checking. Right! Only PUSH EDI and MOV EDI, [ESP+0C] happened! In hex these
commands are: 57 8B 7C 24 0C. When we look at the location where the routine is
called we see 44CB77 CALL 4E3D22. This command is also 5 bytes long. So let's
replace this call by code it effectively executes:

e 44CB77
57 8B 7C 24 0C (and press enter)

Now we should have defeated this protection routine. Hit F5. Damn another page-
fault. Return to SoftIce, type 'exit', hit return and close the error-message. I
patched the dumped executable the way I just did in memory and did al the above
again until I came in routine at 4E39CEh. Also in the .reloc section. This routine
looks very similar to the routine we just walked through before at 4E3D22h. I
started scroll through the code in the .reloc section and found 30 different
routines that all looked very similar. Later on I found one last similar routine
at the end of the .text section. The routines are all different, because they use
different registers and different header checks, but if you understood all we did
until now, you'll understand the rest of the routines aswell and it's easier to
explain, because they all use the same type of protections that we've seen until
now:

- Decode the mid-section of the routine itself
- Do some form of header checking (not only the entrypoint is checked, but also
  other values in the header)
- Restore the state of registers, flags and stack
- Execute a few lines of code that would normally have executed in the context of
  the calling code, but are now replaced by the call to this routine.
- Encode the mid-section of the routine again



Step 4: Start patching.

We've seen the basics of the Bit Arts protection routines. But some of the
routines have another feature. They can decode or encode a piece of code in the
.text section, which is our target executable code. BPX GetVersion again, run our
dumped executable, wait for the break and hit F5 and F11 until we are back in
Fusion. Now take a look at some code in the .text section:

u 4310E0

We'll see this:

4310E0 CALL 4E39CE ; Protection routine
   |               ; Some garbage
431103 CALL 4E3AF3 ; Protection routine

The routines at 4E39CEh and 4E3AF3h both do the header checking, execute replaced
commands and all of the above, but the routine at 4E39CEh also decodes the code
between 4310E5h and 431102h, which is the code between the call to the protection
routines. And the call to 4E3AF3 encodes the same code again. So if this code is
executed actually first the code that has been replaced by the call to 4E39CE is
being executed, then the decoded code between the two calls and then the code that
was replace by the call to 4E3AF3. If we want to patch a section like this we
would have to patch the whole section from the first to the last call. So we need
the hex-code of the code that was replaced by both calls and we need the hex-code
of the decoded section of code. I located 31 mutation routines, but I don't know
when they are being executed. And to be able to patch the calls to their original
values I need to run the routines from their original location because the address
of the section to decode in the target executable, the return address for the
decoding protection routine is used. This is kind of decoding and encoding is
also a good way to fool disassemblers like IDA and WDASM. The calls to the
protection routines relative calls, so the addresses of the positions in memory
where the protection routines are called can't be found by searching for the
address of the protection routine as hex or as text. The only way to find them is
to do a pattern seach on E8 ? ? 09 00. If you seach the file you will fond a few
occurances. These are calls to the protection routines. Then do a pattern search
on E8 ? ? 0A 00 and so on to E8 ? ? 0E 00. You should find 30 occurances. After
I patched everything all of these I noticed that there was one similar protection
routine at the end of the .text section which was called on 4485E9 CALL 470ED2.
I've ran all of the routines to see the code that needs to be copied back to the
positions of the calls to the protection routines and the positions in between. I
did that by setting the eip to the address where the routine was called, for
example (don't do that now):

r eip=4E39CE

And then I hit F8 to enter the code and see the code that needs to replace the
CALL command when the routine decoded some code in the .text section I dumped that
code when it was decoded. I am not going to explain all 31 routines, I'll just
tell you what to patch. You're still in Fusion. Type the following:

e 44C771
(hit enter)
89 06 83 C0 F4
(hit enter)

e 4310E0
(hit enter)
55 8B EC 6A FF 68 98 AD
47 00 68 0C 5A 43 00 64
A1 00 00 00 00 50 64 89
25 00 00 00 00 83 EC 10
53 56 57 33 C0 89 45 E0
(hit enter)

e 431116
(hit enter)
8B 75 08 8B CE
(hit enter)

e 44CA5B
(hit enter)
A1 E4 D3 48 00
(hit enter)

e 44CA6F
(hit enter)
8B C3 C1 E8 10
(hit enter)

e 44CC28
(hit enter)
A1 E4 D3 48 00 83 65 EC
00 56 89 45 F0 8B 45 10
8B 4D 0C 6A 01 8B 00 8B
09 5E 50 89 75 FC
(hit enter)

e 44CB27
(hit enter)
57 8B 7C 24 0C
(hit enter)

e 44CB63
(hit enter)
89 06 83 C0 F4
(hit enter)

e 44CB77
(hit enter)
57 8B 7C 24 0C
(hit enter)

e 405788
(hit enter)
68 D8 C2 46 00 50 64 89
25 00 00 00 00 83 EC 08
56 8B 74 24 1C
(hit enter)

e 4057AE
(hit enter)
5E 8B 4C 24 08
(hit enter)

e 40155E
(hit enter)
68 A0 14 40 00 6A 64 8D
8E F4 01 00 00 6A 14 51
C6 44 24 2C 07
(hit enter)

e 401585
(hit enter)
C6 44 24 1C 0C
(hit enter)

e 401592
(hit enter)
C6 44 24 1C 0B
(hit enter)

e 40159F
(hit enter)
C6 44 24 1C 0A
(hit enter)

e 4015AC
(hit enter)
C6 44 24 1C 09
(hit enter)

e 41233E
(hit enter)
8B F1 89 75 F0
(hit enter)

e 41234E
(hit enter)
33 C0 8D 4E 44
(hit enter)

e 41281F
(hit enter)
51 53 56 8B F1
(hit enter)

e 412833
(hit enter)
33 DB 8D 4E 3C
(hit enter)

e 41284F
(hit enter)
89 5E 7C 6A 0F
(hit enter)

e 412895
(hit enter)
89 5E 58 8B C6
(hit enter)

e 444B01
(hit enter)
0F B6 4C 24 08
(hit enter)

e 4460FA
(hit enter)
8B F1 89 75 F0
(hit enter)

e 44860A
(hit enter)
0F B7 C8 89 07
(hit enter)

e 401382
(hit enter)
8B 4C 24 08 5E
(hit enter)

e 4485E9
(hit enter)
8D 7E 3C 6A 20
(hit enter)

Now dump the patched section:

/dump 401000 70000 c:\text.bin

Hit F5! Error message 'Can't find file fengine.dat'. But it runs! Close Fusion.
Load the dumped executable and our patched section both in Hex Workshop. Select
the area 400h to 7043FFh in the dumped executable which is the raw location of the
.text section. Now switch to the patched section, select all, copy, switch back to
the executable and paste. Now save. Open it again in the PE Editor and validate
the checksum. Save it, copy it to the program folder of Fusion and run. YESS!! It
works.

These are the titanium tricks for protecting the executable for tempering with it.



Step 5: Make Fusion registered.

I discuss this step very quick because I think this is more regular cracking work.
With Fusion it is possible to pack an executable and it's dependent dll's into one
executable. We can select for example Word.exe and scan for it's dependencies.
Then we run the fusion engine and a new executable is created containing the
original Word.exe and all of it's dependencies. While the Fusion engine is running
you'll see a status window. When the engine is done you'll see a message in the
status window:

The output file has been renamed to bitarts_evaluation.exe because this product is
not registered.

After some wandering through the code I was at 40218Fh:

40218F CALL 410130 ; Get the registration level and put it in EAX
402194 PUSH 403770 ; Call back function that updates the status window
402199 PUSH EAX ; Push the value of the registration level to the stack as
                ; argument for the call to the Fusion engine
40219A LEA ECX, [EBP+FFFFE3E8]
4021A0 CALL 410DE2 ; This is a call to the Fusion engine in a dll
4021A5 MOV ECX, [ESI+000001B0]
4021AB CALL 410130 ; Get the registration level in EAX again
4021B0 TEST EAX, EAX
4021B2 JNZ 402226
4021B4 ; Some code that displays the registration message in the status window
402226 ; Continue as normal

I understood what the routine at 410130h did thanks to IDA Pro, because IDA shows
the call to the C++ routines and classes in assembly. This routine get the
contents of the environment variable called 'STATUS' as a string. This string
represents a value. The string is being converted to a value and placed in EAX. I
sought the code in IDA for GetEnvironmentVariable and SetEnvironmentVariable. I
found out that the STATUS-variable is never said in this code, so I assumed it
should have been set by the Titanium shield. The call to 410130h is first made to
get the registration level to parse to the fusion engine which will or will not
rename the file. Then it is called to determine wheter or not the message is
displayed. In our case the result of the routine in EAX is 0. As we can see in the
code above, the registration message is only displayed when EAX is 0. So I patched
the routine that is called for getting the registration level:

a 410130
mov eax, 1
ret

Hit escape and F5 and try to run the Fusion engine on Word.exe again. The savename
will be Word2.exe. YESS!! No message registration message and if we look in
Explorer there's our Word2.exe. So it is not renamed! We have now all options
enabled!

Let's make this last patch. Open the dumped.exe in Hex Workshop. Go to F530 which
is the raw offset of the registration routine at 410130h. Enter these hex-values:

B8 01 00 00 00 C3

Save it, open the executable in the PE Editor, validate the chacksum, save it
again and you're done!



Greetz to all the people that wrote the great tools and tuts like yoda, G-Rom,
+Splaj, +Tsehp and many others. If you want to contact me for anything, leave a
message on the RCE Messageboard at Woodmann's. See you around,

Heathcliff.