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.