Ulead DVD MovieFactory 4

Hi all today's lesson is about Ulead DVD MovieFactory release 4 cracking, this task is reached in interesting way by close looking at the protection scheme used in this nice application.

This tutorial will cover some basic concepts about loader, manual unpacking and API used to create/write a process, before reading this tutorial I strongly recommend to read also the Beginner series tutorial from our team to best know what is a process and related stuff (see section 6 for some reference).

There are following sections in the remaining of this tutorial:

   1. What we can do (brief explanation about the patching).
   2. Proof of concepts (understand the protection)
   3. Trial time patching part 1 (classical approach)
   4. Trial time patching part 2 (in-line patching)
   5 . Conclusion and remark
   6 . Useful reading

As usual we have to look on program behaviour after installing step and know if the target is packed or in a plain form.

To perform this test we can use classical PeID approach (and trust in your sense also because some protector is able to fool this file scanner and similar tools) then we start to scan the launcher application with name Quick-Drop.exe located into the
...\Ulead Systems\Ulead DVD MovieFactory 4.0 Disc Creator Trial\Ulead Quick-Drop 1.0
installation folder.

Fig. 1 PeID file scannig.

program isn't packed anyway then scan about some signature (press -> button then choose Plugins and finally select the Krypto ANALyzer tools):

Fig. 2 Crypto signature.

No crypto signature is present.

Well now is time to launch the program and see the behaviour, we have a starting nag which show the residual trial time, when trial is expired you've to buy the product and Try button isn't enabled.

Fig. 3 Starting nag.

Now you can press the Try button and then execute the program or Exit.

As usual, after looking the target behaviour we have to walk into the debugging stage in order to know in more deep manner the target, to do this load the target in OllyDbg, activate the IsDebuggerPresent plugin and then press F9 in order to show if this is runnable into the debugger. The nag arise and when you press the Try button current application will be closed and a new one take to run.

This behaviour is more likely to a loader because one application run another one and then when the work is finished the first one can be ended (really the last operation isn't needed to call one application "loader", this because the launcher can be still alive in order to do other task), but from our point of view we have to take one approach slighty different from classical plain code debugging and patching stage.

In other tut from our great team, we have also teach about loader and what's a loader, then in this tutorial we have to remind just some simply concept, first of all a loader is a program (or more simply a piece of code) able to create a process, modify and then run it.

Commonly used function is:

• CreateProcess
• WriteProcessMemory
• ReadProcessMemory
• ResumeThread

The first function, CreateProcess or CreateProcessA (ANSI version), is used to create in memory our process, from MSDN we have:

Fig. 4 CreateProcess/CreateProcessA API function.

There are many parameters, but for our purpose just look at lpApplicationName (the process patch and name) and the dwCreationFlags which is flags that control the priority class and the creation of the process (action which will be taken when the process is loader in memory). There are many flags, one of them is CREATE_SUSPENDED (value 0x00000004), with this option the primary thread of the new process is created in a suspended state, and does not run until the ResumeThread API function is called (we speak about thread because, from a general point of view, a process can be builded by many threads and one of this is the first, called on the process start-up, this thread, the first, is called main thread).

To run a process/thread just call the ResumeThread API, again from MSDN we have:

Fig. 5 ResumeThread API Function.

Another useful function for our stuff is about process writing, to do this you've to use the WriteProcessMemory API function, then again from MSDN we have:

Fig. 6 WriteProcessMemory API Function.

More interesting for our task is the lpBaseAddress and lpBuffer, either used into the following analysis.

With this little basic knowledge we can start to load the target in OllyDbg and then place a breakpoint into the CreateProcess API function, to do this you have to use the Command line plugin (press ALT+F1):

Fig. 7 Command Line plugin.


Fig. 8 Set a memory breakpoint on CreateProcessA API function.

now activate also the IsDebuggerPresent plugin and run the target (press F9), OllyDbg break in this API:

Fig. 9 Break in CreateProcessA API function.

look into the OllyDbg stack window we have:

Fig. 10 Stack detail.

then this API is called because a process with file name Quick-Drop.lod (please note also where this file reside, it's inside the same folder where is the Quick-Drop.exe main file which we have load in OllyDbg) will be load in memory with CREATE_SUSPENDED creation flags, this means then that this process is loaded and stopped in memory.
Now, by using again the Command line plugin (ALT+F1), we can set a memory breakpoint on WriteProcessMemory and ResumeThread API functions:

Fig. 11 Other useful breakpoint on API function will be place.

when you press F9 OllyDbg break again and now is time for WriteProcessMemory API function, stack window look like this one:

Fig. 12 WriteProcessMemory breakpoint and stack detail (first break).

from this you can easily understand what program is to do, a block of 221184 byte in length will be write into the created process memory from 0x00401000 (first block), now press again F9 and you keep another break related to WriteProcessmemory:

Fig. 13 WriteProcessMemory breakpoint and stack detail (second break).

another block of data, with size of 36864 bytes, is write into the created process memory from 0x00443000. If you press F9 OllyDbg stop in 0x004015A2 due to the ResumeThread API calling:

Fig. 14 ResumeThread API calling from 0x004015A2.

when executed this call run the process Quick-Drop.lod (look on the handle value, in my case I've 0x44, same value used by WriteProcessMemory, look to hProcess parameter on figg. 12 and 13 for more detail) and you can look the nag of figure 3.

Well bro, now we have enough information to make some consideration about (Quick-Drop.exe) target behaviour:

1. target Quick-Drop.exe create a new process from the file Quick-Drop.lod located into the same folder
2. apply some code injection into the created process memory space using WriteProcessMemory API function
3. run the new process Quick-Drop.lod and exit
4. the Quick-Drop.lod process show the nag and is also responsible for trial checking.

from this thinks the main target to crack isn't Quick-Drop.exe but Quick-Drop.lod which isn't a valid executble file because some portion of code is missing and will be completed at run-time by the launcher which is Quick-Drop.exe. To sure about this just load the Quick-Drop.lod file in OllyDbg and see the code at the Entry Point:

Fig. 15 Code at the Entry Point for the file Quick-Drop.lod

Now launch again the Quick-Drop.exe file and when the trial nag arise, attach OllyDbg at the Quick-Drop.lod process, goto on the address 0x00419A30 and you should be see this code:

Fig. 16 Code at the Entry Point for the file Quick-Drop.lod (attached in OllyDbg).

well this code look different from previous which we have see in figure 15, reason is because the missing code is injected into the Quick-Drop.lod by the Quick-Drop.exe process then, before take crack stage, we have first to fix the file Quick-Drop.lod with the missing code and check if this can be run freely; if this can run without problem we're able to work on the patching stage in order to skip the trial time limit.

Our goal now is about Quick-Drop.lod file dumping and patching and keep this new executable instead of the original one with the same name. To do this simply reload the Quick-Drop.exe in OllyDbg and sure about the breakpoint which we have see in our previous analysis, then when you stop into the first WriteProcessMemory look at the code which is into the buffer located from 0x00920048 (in my machine):

Fig. 17 Jump on the buffer address.

now into the dump window you've this data:

Fig. 18 Make dissassembling section.

when you choose the Disassemble option the code is put in dissassembling form:

Fig. 18 Dissassembled code.

but remember, if you refer to the Quick-Drop.lod process this code is related to offset 0x00401000.

Now we have to take a look into the code related to the OEP for the Quick-Drop.lod process, OEP is on 00419A30 (look at figure 16) then, because the block is writed from 0x00401000 we have an offset of:

0x00400000 (image base) - 0x00401000 = 0x001000

then in our buffer the OEP is on:

0x00920048 - 0x001000 + 0x0019A30 = 0x00938A78

Fig. 20 Code into the buffer related to the OEP.

Because we need to dump the Quick-Drop.lod process we have to stop this process into the OEP and then dump and rebuild the IAT in order to obtain a valid executable file. To stop process in OEP we can simply change the original OEP instruction with EB FE, this keep a infinite loop on the same instruction and the victim process, running in memory, is really blocked into the same address. Then just attach OllyDbg and dump the process.

In detail form, first change the original OEP instruction with EB FE (press CTRL+E into the dump window) then:

Fig. 21 Code into the buffer related to the OEP.

press OK and then F9 until OllyDbg stop because the process Quick-Drop.exe is ended.

Close OllyDbg and restart it again, attach the process Quick-Drop.lod (remember, now this process is running into the OEP then no nag arise):

Fig. 22 Quick-Drop.lod after the attach.

press F9 (run process) and F12 (stop process), you now can look the code on the OEP:

Fig. 23 Code snippet at the OEP (infinite looping).

change the EB FE instruction with the original instruction (see figure 20):

Fig. 24 Replace the looping instruction with the original OEP instruction.

Now fire the OllyDump plugin and dump the process (sure about uncheck the rebuild option):

Fig. 25 Dumping the process.

Fig. 26 Dumping options.

when you've press the Dump button and saved the file (e.g. with name Quick-Drop_Dumped.exe) don't close OllyDbg and don't run the process, but start Import REConstructor and pick up the process (1) , now is time to rebuild the IAT table.

Fig. 27 Rebuilding IAT.

Check about the OEP (2) and press the button IAT AutoSearch (3), then press GetImport (4) all entry is valid, now press the Fix Dump button (5) and select the previous dumped file (Quick-Drop_Dumped.exe), you now have a new file, with the IAT fixed, namely Quick-Drop_Dumped_.exe. Keep the Quick-Drop,exe in a safe place and rename with the same name the rebuilded dumped file and launch it, yeah it work :-).

In this chapter we cover the simple patching stage (just for phun) about trial time limit. All the analysis will be made by using the dumped and fixed file obtained with the step shown into the previous chapter. All the step is made with the Quick-Drop file but is also valid for all the other file into the ULEAD installation folder and subfolder which have the .exe and .lod file with the same name.

As usual load the target in OllyDbg . All the target installed have one evaluation time of 30 days, as first choice you can perform a search for all cosntant equal to 0x1E (30 in decimal base), but nothing useful can be found. Another things can be check for all referenced text string and again nothing of useful is found. Then simply run the target (F9) and when the nag arise stop execution (F12) and look the Call Stack (ALT+K):

Fig. 28 Call Stack after stop on the nag screen.

Our interesting point is on 0042A2DF, place a breakpoint on this address and run again OllyDbg (CTRL+F2), when OllyDbg stop the nag isn't popped, take a code step with F8, when you reach the 0042A397 address the nag arise, then place a breakpoint on 0042A397 and restart OllyDbg. Run again the target, when OllyDbg stop in 0042A397 jump into the call and start with code step analysis.

Fig. 29 Find the call where the nag is open.

step a little until you reach 0x0040DE85:

Fig. 30 Elapsed days calculation.

to skip the trial calculation you can apply this patches:

Fig. 31 Trial time patches.

with this patches trial time is fixed to 30 days forever.

As you can see, there is also other executable module with related .lod file, in each case you have to dump, fix and patch the file as in figure 31 in order to force full trial limit.

We have this file to fix (spreaded into the installation subfolder):

•    Quick-Drop.exe
•    uDVDErase.exe
•    BurnNow.exe
•    DiscDup.exe
•    DVDMF.exe
•    DVDTweakFit.exe
•    DvDPlayer.exe
  

In this chapter, following the result which we have collect from previous chapter, we cover another type of patching namely in-line patching. In-line patching avoid the need for unpacking the victim target because the patching code will be write inside the original .exe file. The patching code is executed every time the exe file is started and is able to patch the buffer data related to the .lod file before this is keep running by using the ResumeThread API function.

We have said about the .lod file which is the process involved into the trial time checking, into the following analysis we refer to the executable file Quick-Drop.exe, but same reason can be applied for all other file.

Unpacking isn't really needed to build a valid patching but we have used it just to know more about this protection technique. Now we know where is the data bytes to patch in order to skip the trial time checking (figure 31), but this bytes must be applied to the .lod process only when it is builded in memory from the .exe main process with the same name and before the ResumeThread API calling.

Well, solution is simple, look again at the figure 17, we have the WriteProcessMemory API which write the decrypted byte from some buffer into the .lod process memory area, some instruction below you've the ResumeThread API calling so, before start to run the .lod process, we have to apply the patches (which is equal to say we have to write some code able to inject the patch data into the .lod process memory).

Our work now is change the bytes into the buffer (starting from 0x00920048) just before the WriteProcessMemory calling, more simply we have to:

Let's go, first things is to look for some available space into the Quick-Drop.exe file, to search it simply scroll down until you reach the end of file, some space is available from 0x004224A6 then we can easily code our patch as below (for the patching value refer to the previous value shown in figure 31), later detailed explanation how obtain it:

Fig. 32 Injected code (trial time patching)

As the first point, you've to save the context of the main process (the Quick-Drop.exe) and this can be achieved by using the PUSHAD / POPAD instructions as guard to our injected code. The PUSHAD instruction is able to save all the registers value (namely the CONTEXT of the current process) into the stack and in the same manner, by using the POPAD instruction, restore the saved value back into the registers.

Then, after context saving (using PUSHAD), we have to write the data patches into the (.lod data) buffer. In order to write this data you need to know where the buffer is allocated in memory, is easy recognize that starting address is into the EDI register. To proof it just look at the OllyDbg registers window when OllyDbg stop into the WriteProcessMemory calling instruction (due to a breakpoint in 0x0040149F):

Fig. 33 Registers window in OllyDbg (breakpoint in 0x0040149F)

as you can see EDI is pointing to the start of the buffer, this address is mapped into the .lod memory space from 0x00401000, because our patches must start from 0x0040DE85 (into the .lod process) we have to find the offset from the buffer start before write our data patches, this is equal to:

Patch offset (.lod file memory space) = 0x0040DE85 - 0x00401000 = 0xCE85

Patch offset (.exe file into the buffer area) = 0x00920048 + 0xCE85 = 0x0092CECD

then, we have to write our patches from 0x00920048 + 0xCE85 but, from figure 33, we also have EDI = 0x00920048 then we can rewrite this expression like this one [EDI+0xCE85].

Last things is about the use of WriteProcessMemory, from the previous chapter we know that this function will be call two time before the ResumeThread execution, then we have also to recognize when the patches was applied (only into the first WriteProcessMemory cycle) , this task is easily solved by checking the first patch then comparing the readed value with the patch value, if this compare is true all the patch was write into the first cycle then we can skip all the injected code and just make the only WriteProcessMemory calling.

Last work to do is jump to our injecting code then:

Fig. 34 Jump to the injected code.

Nothing else will be write about full cracking, do it yourself and then this is really the end of story ;-P.

[MAIN TEAM]
[Nilrem][MaDMAn_H3rCuL3s][Ferrari][EJ12N][Kruger]
[Shub-Nigurrath][Teerayoot][R@dier]
[JDOG45][Eggi][ThunderPwr][Gabri3l]

[Support]
[Bone Enterprise]

[Groupz]
[TSRh][SnD][LUCiD]

Thanks to all the people who take time to write tutorials.
Thanks to all the people who continue to develop better tools.
Thanks to Exetools, Woodmann, SND, TSRH, MP2K and all the others for being a great place of learning.
Thanks also to The Codebreakers Journal, and the Anticrack forum.
..and also a special thanks to Shub-Nigurrath..