While analyzing a program quite often we want to know if it uses any crypto algorithm. Knowing the algorithm name would be useful too. Here is the plugin which can help us answer these questions.

The idea behind it pretty simple: since almost all crypto algorithms use magic constants, we will just look for these constants in the program body. Here is how we would do it manually:

http://www.sockpuppet.org/tqbf/log/2006/01/two-things.html

This approach will fail if the S-boxes have been altered but in most cases they are untouched (can you admit that you understand all consequences of modifying an S-box, say, in AES?)

The plugin supports virtually all crypto algorithms and hash functions. I also added the zlib library constants to the list just for the user convenience. Here is the full list:

• Blowfish
  
• Camellia
  
• CAST
  
• CAST256
  
• CRC32
  
• DES
  
• GOST
  
• HAVAL
  
• MARS
  
• MD2
  
• MD4
  
• MD5
  
• PKCS_MD2 (byte sequence used in PKCS envelope)
  
• PKCS_MD5 (byte sequence used in PKCS envelope)
  
• PKCS_RIPEMD160 (byte sequence used in PKCS envelope)
  
• PKCS_SHA256 (byte sequence used in PKCS envelope)
  
• PKCS_SHA384 (byte sequence used in PKCS envelope)
  
• PKCS_SHA512 (byte sequence used in PKCS envelope)
  
• PKCS_Tiger (byte sequence used in PKCS envelope)
  
• RawDES
  
• RC2
  
• RC5
  
• RC6
  
• Rijndael
  
• SAFER
  
• SHA-1
  
• SHA-256
  
• SHA-512
  
• SHARK
  
• SKIPJACK
  
• Square
  
• Tiger
  
• Twofish
  
• WAKE
  
• Whirlpool
  
• zlib
  

The plugin is very easy to use - just select it from the plugins menu and it will do its job. At the end it will display a message box like this:

It also will rename all found arrays and put them in the marked location list:

The same approach can be used to find other magic constants and strings. The plugin can also be automated - just hook to the ph.newfile processor module event and run the search.

The source code, as usual, comes with the plugin: findcrypt.zip
Have (cryptic) fun!

Posted by Ilfak Guilfanov at 12:38 AM | Permalink | Comments (14)

The last week Ero Carrera in his blog linked to this spectacular site:

These eye catching images evoked an old question in me. Briefly it can be formulated as "text vs graphics".

Everyone would agree: graphic images are much nicer and more powerful than simple text. There are no limits for images while text is a sequence of predefined symbols. Images are accessible for illiterate while reading text is impossible without knowing its language. One glance at an image is sufficient to grasp its idea while text requires careful deciphering of letters and words. Images can easily affect conscious and subconscious parts of mind. Text can do it too, but to much less degree.

Yet many, if not most, of our data is in the text form. Programmers write programs in text files. Data kept in databases is mostly in text form. If data is not in the text form, we have to process it to extract text or some textual description from it. Web pages are essentially text files with links to graphic images. Ubiquitous XML files are kept in the text form. Even the graphs from the above site are represented in a text language like GDL or DOT or something similar.

How strange that we still continue to use text as the fundamental form of our knowledge. Why is it so? Why this awkward and unnatural device has not yet been replaced by something better? Why is this

more widely used than this? ;)

Posted by Ilfak Guilfanov at 10:02 PM | Permalink | Comments (12)

A decompiler is commonly viewed as a tool to recover the source code of a program, the same way as a disassembler is a tool to convert a binary executable program to an assembler text.

This is true in some cases but only in some.

Most of the time the goal is not to get a compilable text. What would one do with such a text? Recompile and link it to get a copy of the input binary program? The only legitimate situation I can imagine is when the source text has been lost and the owner of the program tries to recover it. Even in this case I personally would rewrite everything from scratch because the disassembler/decompiler output is a nightmare to maintain: it lacks comments, inline functions, preprocessor symbols, abstractions, class inheritance, etc.

In short, I wouldn't consider obtaining a compilable text as a major goal of a binary reverse engineering tool (RET).

One goal of a RET is to represent the program logic in the most precise and clear way. This representation should be easily understandable by a human being. This means that the fundamental blocks comprising the program logic should be easily visualized on request. Questions like "what is the function called from the current instruction", "where is the current variable initialized or used", "how many times is the current instruction executed" arise continuously during the analysis of almost any program. In simple cases a disassembler can answer these questions, a decompiler is more intelligent and can perform deeper analysis (e.g. pointer analysis and value propagation could help to find the answer even in the presence of indirect addressing modes and loops). In both cases the RET helps the analyst to grasp the meaning of the program and convert a sequence of instructions into very high level descriptions like "send a mail message to all contacts" or "get list of .doc files on the computer". The clearest program representation is of a paramount importance to understand its purpose.

Another important goal of a RET is to automate program analysis and instrumentation. In this case RET can be used as a basic building unit for another program. We could analyze the input program in order to:

• find logically equivalent blocks (copyright breaches; recognition of library functions)
  
• find logical flaws (automatic vulnerability search; code quality assessment)
  
• deobfuscate it (malware analysis)
  
• add profiling instrumentation (optimization; code coverage)
  
• prepare various inputs (testing)
  

Obviously we do not need to have a nice and readable program representation to achieve the second goal. Everything can stay in the binary form because the result of the analysis will be used by another computer program. One may even ask himself, "is it a decompilation, after all?" The input program is not converted into a high level language (HLL). More than that, the program text may even not be generated.

However, both cases use the same fundamental algorithms to analyze the input program. These algorithms are similar to the algorithms used in HLL compilers. The core of a RET builds an intermediate internal representation (usually a tree or graph-like data structure) which can then be either converted to an HLL text or used to discover interesting properties of the input program. In the same way a compiler builds an intermediate representation which is used to generate machine code.

Maybe we should stop using the word "decompiler" so widely to avoid confusion and to stop mixing concepts.

Posted by Ilfak Guilfanov at 06:28 PM | Permalink | Comments (20)

I restored the old configuration and the blog will continue its normal operation now. The hotfix can not be downloaded from the site anymore but its source code is still available.

Thank you all for the support! I'd like to say thank you once more to the guys who mirrored the files!

P.S. Next week we will talk about some decompilation problems.

Posted by Ilfak Guilfanov at 12:30 PM | Permalink | Comments (17)

The new version is suitable for automated setup (for example, in logon scripts).

Due to popular demand the new version of the setup can work in fully silent mode. If run without command line parameters, it will behave normally - display the welcome window, ask for confirmations, etc. To run it silently, use the following command line:

wmffix_hexblog14.exe /VERYSILENT /SUPPRESSMSGBOXES

In the case of a successful install, the computer will reboot. Otherwise the setup will exit with one the following codes:

• 1 Setup failed to initialize.
  
• 3 A fatal error occurred while preparing to move to the next installation phase (for example, from displaying the pre-installation wizard pages to the actual installation process). This should never happen except under the most unusual of circumstances, such as running out of memory or Windows resources.
  
• 4 A fatal error occurred during the actual installation process. Note: Errors that cause an Abort-Retry-Ignore box to be displayed are not fatal errors. If the user chooses Abort at such a message box, exit code 5 will be returned.
  
• 5 The user chose Abort at an Abort-Retry-Ignore box.
  
• 10 The fix is already present on the system
  
• 11 The fix can not be installed because the system is not supported
  

If you already have any previous version of the fix installed, there is no need to reinstall. Old hotfixes are as good as the new one in protecting your computer.

Second good news is about the vulnerability checker. It too understands the /SILENT command line switch and in the silent mode it does not display anything on the screen. The errorlevel can be checked from a batch file.

We wish you easy installation of the fix and safe computing!

P.S. I had to turn off the comments to save the bandwidth. A discussion forum is open here.

Here is a sample batch file to check the fix:


@echo off
rem Batch for to illustrate how to use wmf_checker in the silent mode
wmf_checker_hexblog /SILENT
if errorlevel 2 goto bad_error
if errorlevel 1 goto vulnerable
echo You system seems to be invulnerable
goto end

:end


The files can be downloaded from the following links:

http://www.hexblog.com/security/files/wmffix_hexblog14.exe
(md5: 15f0a36ea33f39c1bcf5a98e51d4f4f6)

http://www.hexblog.com/security/files/wmf_checker_hexblog.exe
(md5: ba65e1954070074ea634308f2bab0f6a)

http://www.hexblog.com/security/files/wmfhotfix.cpp
(source code of the hotfix)

http://www.hexblog.com/security/files/wmf_checker_source.zip
(source code of the checker)

Posted by Ilfak Guilfanov at 12:22 AM | Permalink | TrackBacks (2)

It seems that many users installed the hotfix for the WMF vulnerability on their machines.

The fix was first mentioned by F-Secure in their useful blog

http://www.f-secure.com/weblog

and its technical details were explained in precise detail by Steve Gibson (Thanks, Steve!)

http://www.grc.com/groups/securitynow:423

However, there is no safe way to tell if your system is vulnerable. Here is a small utility to address this problem. You can download it from the following link:

http://www.hexblog.com/security/files/wmf_checker_hexblog.exe

When run, it displays this dialog box:

and then proceeds to testing.
If your system is vulnerable, you will see this dialog box:

and if your system is not vulnerable, another dialog box will be displayed:

Please note that when the second dialog box appears on the screen, it just means that this particular attack against your computer failed. There might be other attacks we are not aware of.

Do not use this check as a definite answer to the WMF vulnerability question. But if your system was vulnerable, it should be invulnerable after installing the hotfix and display the second dialog box. In other words you can use this checker as a means to verify that the hotfix is doing its job. One more word of caution: do not forget to reboot your computer after the installation. If you do not reboot it, the checker will tell you that the system is invulnerable while some system processes will still be.

I have tested the checker on XP SP2 and XP 64bit. If you try it on other machines, please let me know about the results.

Files: wmf_checker_hexblog.exe
wmf_checker_source.zip

UPDATE: New version which does not use a drop file. The checker is now small.

Posted by Ilfak Guilfanov at 11:55 PM | Permalink | Comments (54) | TrackBacks (12)