In Chapter 5, “Replacing and Patching Application Classes,” we talked about patching classes to alter the application logic. In this chapter we discuss changing the user interface elements such as messages, warnings, prompts, images, icons, menus, and colors. The same principles described in Chapter 5 apply here as well. The first task is to locate a resource that needs to be changed. Then a change can be made and the application updated to ensure that the new resource is used in place of the old one. Table 12.1 shows the association between UI elements and the resources to be patched.

Learning by example is one of the easiest ways to digest information, so let's take a hypothetical application and then mutate it according to our whims. You have seen a lot of appearances of the Chat application throughout the previous chapters and in continuation of a good tradition we will hack Chat to illustrate each of the techniques.

Chat uses the text Send message as the menu item text and the ToolTip hint for the toolbar button. Although it conveys the meaning of the action perfectly, it can be perceived by the younger generation of users as uncool. To satisfy this audience, let's hack Chat to use Unleash the fury instead of Send message. We will be working with the distributed version of the application pretending that we do not have access to the source code.

Because Chat comes packaged in a JAR file, the first thing we must do is unjar CovertJava/distrib/lib/chat.jar into a temporary working directory. We then have to find the classes that define the text strings currently displayed by Chat. Using FAR or a search tool, we do a binary search for Send message in all files located in the working directory and its subdirectories. The result of running the search should be the MainFrame.class file, which we decompile as described in Chapter 2, “Decompiling Classes.” Searching the decompiled source code for Send message takes us to the jbInit method, an excerpt of which is shown in Listing 12.1.

private void jbInit()
    throws Exception
{
    ...
    btnSend.setToolTipText("Send message");
    btnHelp.setIcon(imageHelp);
    ...
    menuEditSend.setText("Send message");
    menuEditSend.addActionListener(this);
    ...
}

Using the patching technique presented in Chapter 5, we can just replace Send message with Unleash the fury in the decompiled source code and add it as a patch to Chat. That was easy enough, and luckily in most real applications it should be just as easy. Complications can arise if the application code is obfuscated with string encoding, but with the knowledge gained from previous chapters, it should not stop us from finding the class to patch.

Good applications do not hardcode the text strings in the code. Instead, the messages are stored in resource bundles or configuration files, which makes maintenance and localization easy. As long as the strings are not encoded, the binary search performed on the contents of the working directory still yields the desired results. After the file containing the string is located, it can be updated with the new text. After that, the application needs to be repackaged for the change to take effect.

Working with images is a bit trickier than working with text. Unlike text, you can't just search for an image because you don't know what to use as a search criteria. The first step, therefore, is to find the name of the image and determine how the application is loading it, after which a patch can be applied. There is no direct and easy way of finding the name of the image. Most likely, the application loads it in the UI-related code, but many times developers use a framework or a manager class to help with the groundwork required to load an image in Java. Experience suggests exploring the exploded (that is, not stored in a JAR) application or maybe searching for all .jpg and .gif files. Most of the time, the image name is the best clue to where it is used. For example, a splash screen might be called something like splash.gif and the icon for the New toolbar button might be called new.gif. A typical Java application does not have many images, so you should be able to locate the one you are looking for easily. Obviously, viewing the image is the way to confirm that you found your guy. (I didn't really have to say that, did I?)

What if there are too many images, and the programmer who coded the application used filenames such as img0045.gif? You can still guess which image is yours by looking at the size of it or just going through all of them sequentially. Remember that the application might be storing images in a different JAR file, so you have to open all of them when doing the search.

Now look at a worst-case scenario: You can see that the application is displaying an image and you desperately need to change it, but after going through all the image files packaged with the application, you can't find it. You have several options for determining where is it coming from. Because the easy way didn't work, we'll have to dig deeper and get to the place in the code where the image is loaded. Again, previous chapters covered reverse engineering techniques, and I suggest searching the class files for .gif or .jpg as a starting point. I have never seen an application that stores GIF files with a .txt extension, and I surely hope to never live to see that day. For instance, to change the image in the About dialog box of Chat, we can search for all GIF and JPG files in the working directory. Doing so takes us to the covertjava.chat.images directory that contains several images. Because it contains just a few images, we can simply view them to determine which one is used in the About dialog box. Alternatively, we could have searched for .gif, which would have taken us to the MainFrame class file again. Decompiling it, we would have discovered that Chat uses saturn_small.gif for the About dialog box.

Finally, we can also search for the getImage method of java.awt.Toolkit, which is the most common way to load an image. The following are a couple of examples of Java code that loads an image:

/**
 * Creates an icon from an image contained in "resources/images"
 * directory inside a .jar file
 */
public ImageIcon createImageIcon(String fileName) throws Exception
{
    String path = "/resources/images/" + fileName;
    return new ImageIcon(getClass().getResource(path));
}
/**
 * Loads an image from "images" directory on disk
 */
public Image loadImage(String fileName) throws Exception
{
    return Toolkit.getToolkit().getImage("images/" + filename);
}

After you have found the code that is loading the image, you should be able to understand where it is coming from. If the image is not packaged with the application, most likely it is accessed via an external URL similar to http://mycompany.com/app/images/splash.gif. At this point, you (the educated hacker) know exactly how to attack the problem. Use your Web browser to download the image from the URL, save it locally, edit it, and package it with the application. Then patch the class that is loading it and, instead of the HTTP URL, use either the jar:file/ URL to load it from your JAR or Toolkit.getImage() to load it from a directory. Voilá—you've done it.

Configuration files are just another type of application resource, and the approach to hacking one is the same as for text and images. We are not talking about the configuration files stored in the application directory that can be easily modified; we are talking about the files that can be inside the .jar or .zip file and that are not necessarily intended for editing. As before, we will unjar the application archive and examine the directory structure looking for suspicious files. If the directory structure is large, we can search for all files with a .properties or .xml extension. Most likely this simple browsing will yield the results—if not, we can fall back to the reverse engineering techniques described in previous chapters to locate the part of code that is using the setting. Then we can trace our way to the code that is loading the configuration, which will provide enough information to determine the patching strategy.