Experience and Discussions

When implement this DRM Wrapper, we encounter some issues that are not easy to overcome because of our method of the work. We address these issues below and bring up our solutions and experiences.

4.5.1. Rendering

Because of the method of the work that inject a DLL into the process, we need to know that the working flow of the process in order to make the execution of the process normal when we modify the parameters of some function call and return then to the process. Unfortunately, we can’t understand the work flow of a process because that the COTS Reader is commercial without source code and won’t release its detail implementation.

When implementing the ‘Render’ functionality, we decide to intercept the function, CreateFile(), and this function can creates or opens a file, directory, physical disk, volume, console buffer, tape drive, communications resources, mailslot, or named pipe, but we must fit in with the control flow of the process, so we must

With our example of IE rendering web pages, the object type we need is file, so there are many restrictions on the decision of the protection methods. When deciding the cipher algorithm, the streaming cipher is more secret than the block cipher because that there are no entity files existing in the computer, but we can not choose it because of the requirement we mentioned that ‘the object type we need is file’. So we use block cipher and store an entity file into a secret place in the computer.

But we think this method is not secret enough, we add a simple method on the file to increase the level of secret. We do exclusive-or on this entity file after decrypting because we need to fit in with the working flow of IE, that is, the object type and size are must identical with them after doing the exclusive-or method. Here we encounter two issues that how to do exclusive-or on the data in the memory because that the IE doesn’t read these data in the memory at a time and the rendering problems with the dynamic pages with other plug-in programs.

BOOL ReadFile(Handle hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped)

The ReadFile function will read the data in the memory that pointed by hFile witch gets from the return value of the CreateFile() into lpBuffer. IE calls this function to read the content into memory after a lot of setting steps after calling Createfile(). Our solution is to intercept this function and does exclusive-or on the lpBuffer, but the problem is how to know that what data are we want. We store and assign the return value of the CreateFile() to a global variable because that there are may many threads executing and we just have a shared source code and this situation will cause that a handle in a thread will be covered by the handle in another thread if we don’t store it as a global type and check the hFile of the ReadFile function with it

to see that if they are equal or not to overcome this problem. Figure 4-10 shows this problem. If they are equal, then we do exclusive-or on the lpBuffer, else we don’t.

Figure 4-10 The thread problem

We have mentioned the situation in 2 that the rendering problem of IE rendering a dynamic page using JavaScrip with multimedia contents. We don’t propose a useful solution to solve it. We just make a decision by judging that if this file is need a plug-in application to render or not. Now we only implement the decision rule of the .mid and the .mp3 files in the Helper.

4.5.2. Dialog box

We have mentioned in1.5 that we intercept the DialogBoxIndirectParam function.

This way of making this functionality is not good because that all functionalities relative to dialog box such as ‘save as’ and ‘open old file’ will be locked. We have no idea to solve this situation except that we take some redeeming actions in IE. We observe that there is a different part between the ‘save as’ and ‘open old file’ in IE.

The ‘save as’ function call DialogBoxIndirectParam() immediately, but the ‘open old file’ will call DialogBoxParam() before calling DialogBoxIndirectParam(). We can

Handle = A

Set handle Set handle

Thread B

Use handle

make use of this divergence to distinguish them, but this is a special case. When working with other applications like Adobe or Windows Media Player, this method is still not working.

4.5.3. Clipboard

We encounter some issues when we implement the ‘print screen’ function. As we mentioned in 1.4, the User Wrapper opens the clipboard preventing other applications from modifying the data in the clipboard, empties and close the clipboard to release the use right of the clipboard. The algorithm we mentioned in 1.4 seems workable, but there will be some problems happened when work with other applications that will use the clipboard such as the Microsoft Office Word. Figure 4-11 is an example.

Figure 4-11 The clipboard problem in our work

When we test this functionality together with the Microsoft Office Word, the intercept functionality sometimes works successfully but sometimes is not. We believe that this is a timing problem, that is, the system puts the picture into the clipboard after executing our program. We even try to intercept the key down and key up separately in order to fit in with the time difference, but still not work. Finally, we implement successful by disabling the warning message box we prompt because that we have observed that IE will call the warning message box many times since IE will re-call the same function many times when calling fail and the delay time needed by the warning message box is about five seconds (depend on the speed of the testing computer). We think that this is a very possible reason causing the time difference.

4.5.4. Other Experiences and Discussions

There are some limitations in our work. We can’t judge that the rendering content is protected or not in wrapped functions just in time because of the restrictions of applying the detours. Although we can access and change the parameters in the target functions, but we are still restricted by the information provided by the parameters. For example, we can’t get the URL from the parameters in ReadFile(), but we only can get the handle to the createfile() and the URL we needed is one of the parameters in createfile(). We can’t intercept the ‘view source’ functionality in FireFox. We suppose that the reason is that FireFox reads the decrypted content into memory and it will get the content in memory when doing the functionality, view source, but IE will send URL referring to the encrypted file to notepad for viewing source. Figure 4-12 shows this concept.

We also find out some issues when OpenDReaMS Wrapper works with the Acrobat 7.0 professional but it will work well with Acrobat 7.0 Reader. The

can work in IE. If the non-wrapped Acrobat is opened first, and then we will fail to wrap another one whether professional version or reader version, but IE does. We guess the reason is that the Acrobat will work as one daemon and IE works as a single instance, so there is one Acrobat daemon at a time and there can be many IE existing at the same time. This may need further work to understand it. Moreover, if we wrap IE, the any other IE opened by this wrapped IE are still under control of our User Wrapper.

Figure 4-12 view source working flow in IE and firefox

Read from memory

Createfile() Createfile()

Protected URL

IE FireFox