Didier Stevens

Friday 7 July 2006

Viewing strings in executables

Filed under: Reverse Engineering — Didier Stevens @ 8:30

I was having an interesting chat with a colleague. He is developing a VB6 application for his personal use, and has some of his friends beta-testing it. At one point in the conversation he asked me if it’s possible to view the strings in the compiled application, because he tried and didn’t see them. It turns out he implemented a popup message to remind his beta testers to check for an update, and wondered if this would be easy to circumvent.

It’s usually easy to circumvent, I’ll explain it here for my colleague and you.

Strings used in the source code of VB6 are stored as UNICODE strings in the compiled executable. UNICODE strings are usually encoded in UTF-16 on Windows, as UTF-16 is the standard format for the Windows API. ASCII characters are encoded with 2 bytes in UTF-16.

So for example, the string “Hello” is represented as 48 00 65 00 6C 00 6C 00 6F 00 in UTF-16. It’s because of the 2 bytes per character that my college didn’t remark the string.

There are many free utilities on the net to view strings in executables, I use these:

Consider this simple VB6 program (it will display a message box “Hello” when executed after 1/1/2007):

    If Now > DateValue("1/1/2007") Then 
        MsgBox "Hello" 
    End If

You can view the strings in the compiled program, hello.exe, with the Sysinternals tool strings like this (it’s a command-line tool):

strings hello.exe

The result will be this:

    Strings v2.2 
    Copyright (C) 1999-2005 Mark Russinovich 
    Sysinternals - www.sysinternals.com                         

    1/1/2007 
    Hello 
    VS_VERSION_INFO 
    VarFileInfo 
    Translation 
    ...

You can see strings “1/1/2007″ and “Hello” listed at the beginning.

The BinText utility has a GUI, has more options and provides you with more info. Start BinText, use the Browse button to select the executable to analyze, and press Go to display the strings:

 

The red U indicates that it’s a UNICODE string. The first hexadecimal number is the position of the string in the file (hello.exe), and the second hexadecimal number is the position of the string in memory when the executable is executed.

So you will find string 1/1/2007 at position 000016D0 in the file and position 004016D0 in memory.

BTW, this technique to dump files will almost always fail when analyzing malware, because these files are often packed or encrypted. A simple trick to view the strings of such malware code is done with Process Explorer by Sysinternals. When the malware is running (you’ll want to run it on an isolated machine, like a virtual machine), start Process Explorer and display the properties of the running malware. The Strings tab will show you the strings in the file (Image) and in memory (Memory). Since the malware as unpacked/decoded itself when it started, you’ll be able to view the strings in memory.

The strings in an executable will give you an idea of what this program will do: you’ll recognize registry keys, URLs, filenames, …

Back to our example, hello.exe. We recognize a date, 1/1/2007. When you run the program (on a day before 1/1/2007), nothing happens. When you run the program after 1/1/2007 (by changing your computer clock), the Hello message box appears. So now we have clearly established that the string 1/1/2007 is indeed the date after which the message box is displayed.

How would someone modify this program to avoid the message box? A simple trick, which requires no programming skills, is to change the date 1/1/2007 to a later date, say 1/1/3007.

You’ll need a hex editor to do this, like the free XVI32.

  1. Start XVI32 and open the file hello.exe
  2. We know that string 1/1/2007 is at file position 000016D0: type CTRL+G, select hexadecimal, type 000016D0 and click OK
  3. The cursor is know positioned at the beginning of string 1/1/2007.
  4. Select digit 2 in the right pane:
  5. Type 3, this will replace digit 2 (32 hexadecimal) with digit 3 (33 hexadecimal)
  6. Save the file hello.exe

One can argue that this technique can only be applied to very simple programs, which have few strings and which store dates as strings. This is partially true, because it’s still easy to find dates in programs that don’t use dates for their normal operation. Like the program of my colleague. It’s almost 1 Mb large, but it only uses dates to decide when to display the message box. So they are easy to find, and easy to modify.

In fact, I didn’t use this string patching technique to show him how his message box could be disabled, but I changed the program logic by analyzing the assembler code and patching a few bytes. I will explain this in a next post.
But this shows my colleague how easy it is to disable his message box.

He can make it more difficult by hiding the dates:

  1. don’t use strings to represent dates
  2. use string manipulation to hide the date
  3. encrypt the strings and decrypt them at runtime
  4. pack the executable
  5. protect the executable with specialized software (e.g. ASprotect)

But this will not stop a determined attacker, there are even generic unprotection tools for ASprotect.

9 Comments »

  1. Hi,

    I was inspired to discuss this further on my blog. Lemme know what you think!

    Comment by Ryan — Thursday 13 July 2006 @ 0:15

  2. [...]   « Viewing strings in executables [...]

    Pingback by Didier Stevens » Blog Archive » Update: Viewing strings in executables — Thursday 13 July 2006 @ 17:59

  3. does any one know how to decompile .exe application design by visual basic.net 2003 and made with dotfuscator (preemptive.com)?

    Comment by nagi — Wednesday 16 August 2006 @ 21:32

  4. [...] However, leaving the file unpacked would be leaving it’s functionality naked. Many people would strings an executable before running it, especially IRC bots would have a lot of easily identifiable [...]

    Pingback by Unubot’s new clothes, pretty? | Naked Security — Monday 18 October 2010 @ 20:20

  5. None of the links given in the article point to the correct web page (BinText or Strings). Thanks for the useful information :)

    Comment by Romeo29 — Sunday 14 November 2010 @ 4:17

  6. Updated links for Strings and BinText:

    http://technet.microsoft.com/en-us/sysinternals/bb897439

    http://www.mcafee.com/es/downloads/free-tools/bintext.aspx

    And other utilities and tools from those sites:

    http://technet.microsoft.com/en-us/sysinternals/bb795533

    http://www.mcafee.com/es/downloads/free-tools/index.aspx

    Hope that helps someone! :)

    Comment by Gliktch — Thursday 10 February 2011 @ 10:53

  7. Please Tell me what about Encrypted String

    Comment by yogesh — Saturday 9 February 2013 @ 20:05

  8. very helpfull information. Thanks

    Comment by Anonymous — Tuesday 20 August 2013 @ 19:42

  9. “Please Tell me what about Encrypted String”

    There’s no unique answer, it depends how it’s encrypted, and is not a simple task. Unless you know how to decrypt it (unlikely), the best approach is probably to run the program in a debugger and trace through. Requires a lot of skill, and even then will take a lot of time and work.

    Comment by MichaelS — Saturday 24 May 2014 @ 15:05


RSS feed for comments on this post. TrackBack URI

Leave a Reply (comments are moderated)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 227 other followers

%d bloggers like this: