The first one is 0x41414141.com. Just go to the site and you can start directly. As far as I know, this is not time-bound.

The second one is spargecoduasta.com (“break this code”). It is put up by BitDefender and I don’t know if it has a time limit. The levels I’ve seen seem to focus on C/C++. It is available in both Romanian and English.

Finally, a little off-topic, but still a challenge: The Science Knowledge Quiz – with the tagline “Are you more science-savvy than the average American?”. Via Pat’s Daily Grind (I’ve got 11 out of the 12).

Have fun!

To get the bad stuff straight out of the way:

• The authors define a very wide scope for the book in the introduction (something along the lines of “everyone should read it” – of course I’m paraphrasing). There is stark contrast however between this statement and the level of knowledge required to be able to understand the book, knowledge mostly isn’t covered in the book
• A large part of the book is monospaced textual content. They don’t use a typeface however in which you can easily differentiate between the letter l and the digit 1 (like Monaco), which makes many of the examples ambiguous
• The chapters have a certain feel of disorganization to them in my opinion, and frequently they seem to be more of a “tips & tricks” collection than complete whole. I assume that a large reason for this is the fact that the WinDBG commands evolved over time, so there isn’t a simple logic which can “decode” all of them (similar to the MS-DOS/MS Windows batch language). Still, a summary of the commands (in cheat-sheet fashion) would have been nice.

One positive aspect of the book is its low error rate. In fact I’ve seen only one error in the whole book (there might have been more, but not many more): a drawing shows the end of the SEH chain as being 0x00000000, while in fact it is 0xFFFFFFFF (the correct value is used however in the text). An other positive aspect is the thoroughness: after reading trough all off ~750 pages, you will get a very good idea about the capabilities of WinDBG and other related tools.

So would I recommend reading this book? If you want to use WinDBG (or other debuggers from the Windows Debugging Tools) yes, but only after reading at least the Windows Internals and an assembly book (I’ve heard that Art of Assembly would be good, although I’ve didn’t read it myself). It should have a warning sticker: for hard-core enthusiast only.

Full disclosure: the links in the post contain my Amazon Affiliate ID.

API-MS-Win-Core-RtlSupport-L1-1-0.dll
API-MS-Win-Core-ProcessThreads-L1-1-0.dll
API-MS-Win-Core-Heap-L1-1-0.dll
API-MS-Win-Core-Memory-L1-1-0.dll
API-MS-Win-Core-Handle-L1-1-0.dll
API-MS-Win-Core-Synch-L1-1-0.dll
API-MS-Win-Core-File-L1-1-0.dll
API-MS-Win-Core-IO-L1-1-0.dll
API-MS-Win-Core-ThreadPool-L1-1-0.dll
API-MS-Win-Core-LibraryLoader-L1-1-0.dll
API-MS-Win-Core-NamedPipe-L1-1-0.dll
API-MS-Win-Core-Misc-L1-1-0.dll
API-MS-Win-Core-SysInfo-L1-1-0.dll
API-MS-Win-Core-Localization-L1-1-0.dll
API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
API-MS-Win-Core-String-L1-1-0.dll
API-MS-Win-Core-Debug-L1-1-0.dll
API-MS-Win-Core-ErrorHandling-L1-1-0.dll
API-MS-Win-Core-Fibers-L1-1-0.dll
API-MS-Win-Core-Util-L1-1-0.dll
API-MS-Win-Core-Profile-L1-1-0.dll
API-MS-Win-Security-Base-L1-1-0.dll

I guess somebody found an OOP book and started applying the “single responsibility principle” to kernel32 :-). What does this mean to you? If you are an end-user, nothing. If you are a RE or a low level programmer, take care because many functions from kernel32.dll are now forwarded into these DLLs instead of being directly implemented.

Update: here is a little more detailed post on the Avert Labs / McAfee blog.

So I said: detecting it can’t be that hard! And generated all the combination of payloads and encoders (plus some triple encoded ones – since this also seems to be considered “a better way” to hide the payloads) and written up the following python script using pefile and pydasm:

import pefile, pydasm
import sys, glob, operator, re

def countFInstr(buffer):
  offset = 0
  fpoint = 0
  rx = re.compile("0x[0-9a-f]+")
  while offset < len(buffer): 
    i = pydasm.get_instruction(buffer[offset:], pydasm.MODE_32) 
    instr = pydasm.get_instruction_string(i, pydasm.FORMAT_INTEL, 0)
    if (instr and rx.search(instr)): fpoint += 1
    if not i:
      offset += 1
    else:
      offset += i.length
  return fpoint

def scan(filename):
  try:
    pe = pefile.PE(filename, fast_load=True)
  except pefile.PEFormatError:
    return False
  execSectionSize = 0
  foundRWXSection = False
  rw = 0x40000000 | 0x80000000L
  for section in pe.sections:
    if (0 == section.Characteristics & 0x20000000): continue
    execSectionSize += section.SizeOfRawData
    if (rw == section.Characteristics & rw):
      # print section.Name
      buffer = section.get_data(section.VirtualAddress, 128) 
      # for c in buffer: print "%#x" % ord(c),
      # print ""
      # print countFInstr(buffer)
      if (countFInstr(buffer) < 16): return False
      if (len(buffer) < 128): return False
      foundRWXSection = True
  if (not foundRWXSection): return False
  if (execSectionSize > 4096): return False
  return True

sys.argv = reduce(operator.add, map(glob.glob, sys.argv))

for filename in sys.argv[1:]:
  print filename, " ",
  if scan(filename):
    print "Metasploit!"
  else:
    print "-"

It has a detection rate of 100% and a false positive rate of 0% (although I didn’t have access to executable files packed with more “exotic” packers which would have given me a more accurate FP rate – even so I consider that the detection method is not really prone to false positives).

So how does it work? What does it take for it to say “Metasploit”?

• The executable must have at least one section marked with Read/Write/Execute (typical for packers)
• The beginning of the given section (the first 128 bytes) must contain at least 16 instructions with hardcoded constants (immediate instructions)
• The total number of raw data loaded into executable sections must be less than 4k

But wait! – you might say – you are not detecting the actual payload! You are detecting some particular characteristics of the file which are relatively easy to change! And my reply is: correct. But discussion about the “correct” way of doing things is a philosophical one as long as the presented solution has a low FN/FP rate and is efficient. You might get into an argument about how “future proof” it is, but then again, most AV products are black-boxes and it wouldn’t be so straight forward to find the particular detection algorithm and then circumvent it.

An other thing I remarked is that the given code doesn’t try to defend against emulators (for example by doing multiple loops, calling different windows API’s, etc). While the code is sufficiently complicate to create a problem for IDS’s, AV software which has emulation capability (and almost all of the “big guys” and even many of the smaller guys do) will go trough the decryptor like a hot knife trough butter.

So why then doesn’t AV detect these executables? Because they occur in very low numbers, and unfortunately today AV is a numbers game.

Please, the next time you p0wn the client with a metasploit-payload-executable, don’t say “AV is worthless”. Rather say: “this demonstrates what an undetected malware can do, so you should use multiple layers of defense”.

Picture taken from fazen’s photostream with permission.

The book is structured into 26 chapters which cover every aspect of IDA, no matter how exotic :-). A word of caution: this book isn’t an “introduction into reverse engineering”. A prerequisite to reading it is at least some basic knowledge of the PC and the OS (things like CPU registers, memory addressing, paging, etc). For obvious reasons (like size limit – the book is already 500+ pages long) it is presumed that the reader posses this knowledge.

The chapters are well structured and can be read in a maximum of two hours by my estimation, so you could read trough the whole book in a month easily by looking at one chapter a day.

A very large percentage of what is described can be directly applied to the freeware version (4.9), and even more, the book contains a separate appendix listing the differences between the version covered in the book (5.2) and the freeware version (4.9).

An other positive aspect of the book are the warnings inserted in the correct places (when it talks about debugging malware for example), which is very important to avoid unpleasant surprises (like infecting the local network, having to rebuild your machine to ensure that it is not infected, etc).

I have very few negative things to say about the book and all of them are a matter of taste/personal preference. For example I feel that too little emphasis was put on the usage of shortcut keys and everything was presented by using the menus. Then again, shortcut keys can change from installation to installation, but the menus are always in the same place and you can easily find out the associated shortcut key. An other quibble of mine would be the usage of IDC (the built-in scripting language) despite of the existence of much better options like IDAPython (the difference between the two beeing – IMHO – wanting to kill yourself and enjoying your work IMHO :-)). Then again, IDC is directly available upon installation, while IDAPython (and its brethren) need to be installed separately (which can be difficult, especially if you are not running Windows).

So, should you buy this book? If you already have (some) RE knowledge and plan on using IDA (even if only the free version), the answer is a resounding yes. It will give you a big productivity boost, so it is definitely worth its price. Also, how can you go wrong if Ilfak say: “I wholeheartedly recommend The IDA Pro Book to all IDA Pro users” and displays it on his blog :-).

Full disclosure: the links provided contain my Amazon affiliate id so that I can give you more and more useful reviews (or at least buy myself some quality black tea :-)).

PS. You can find a sample chapter and further material on the site of the book.

Picture taken from Joachim’s photostream with permission.

• GlobalFlagsClear – The global flags that control system behavior. For more information, see Gflags.exe.
• GlobalFlagsSet – The global flags that control system behavior. For more information, see Gflags.exe.
• LockPrefixTable – The VA of a list of addresses where the LOCK prefix is used. These will be replaced by NOP on single-processor systems. This member is available only for x86.

The first two might be interesting to turn off some debuggers, or conversely, register itself as a debugger and launch a new process with this… The last one might be similar with the TLS trick because it can (in theory) overwrite arbitrary bytes (although only with the fixed value of 0x90 and I don’t know if it check that the byte is 0xF0). I couldn’t manage to get it to work, probably because I’m not giving the list correctly…

First of all, what is executable packing? In short it is similar to self-extracting archives, where as a result of the process an executable is generated which contains some unpacking code and the original code in a compressed form. A free (as in speech) one is UPX, which you can check out over at sourceforge and play around with it.

Why would you use such a thing? First of all it makes your program smaller without any noticeable effect for the end user (that is s/he doesn’t have to extract the executable from an archive before running it, s/he can just double click on it and run as if nothing has changed). Second of all it protects your code from the very beginner reverse engineers (to see all the options available to a more experienced one, just listen to the podcast mentioned above). A third argument used is that the load time of your executable is smaller (it loads faster) because a smaller amount of data must be transferred from disk. This may or may not be true depending on the usage pattern, but as I describe later it definitely has an effect on the memory usage (in the negative way).

Now why shouldn’t you pack your executable? First of all it will look suspicious. One of the best task-manager replacements out there even marks it with a different color. Some AV products will flag your executable as suspicious if you use certain packers to compress it (like Morphine) because these packers are known to primarily be used in malware.

Now for the biggest reason to avoid packing programs and libraries (DLLs): it consumes more memory. Under Windows (and probably under Linux too), portions of the memory can be marked as being a mapping of a portion of a given file. When such a mapping is created, just the portions of the file which are actually accessed are loaded in memory. The rest is just marked by the memory manager as being available when needed from the file. What this means that during the loading of a normal, non-packed executable, it is mapped to memory, but only the parts are actually loaded from the disk which contain code that needs executing. Now in the case of a packed file the whole file needs to be loaded in memory, because the unpacker needs to go through every bit of packed data to unpack it before it can run the original code. Even worse, when the system is running low on memory, if you have an upacked executable, it can just throw out the memory pages it occupies (if the process is idling), because it knows that it has the exact same data on the disk. In the case of a packed executable it first has to write out the memory pages to the swap file, because they are different from the contents of the file on the disk. Now for the last point (but the most important one in the case of DLLs): the Windows memory manager is able to share memory pages across processes if their content hasn’t changed since their loading. Specifically in the case of DLLs, you will have the same code loaded in each process which uses them. So the memory region in which the DLL is loaded is shared between all the processes using it (there are some exception, but for sake if simplicity we’ll ignore those). How does Windows define unchanged memory pages? Those pages which map to the same area of the same file and hasn’t been written to. This means that as soon as you have a packed DLL, it will have a separate copy for each process using it, because what is in memory doesn’t mach what is on disk and thus Windows can’t share the given memory pages between processes. This means that each process that uses your DLL will have a separate copy of it. This effectively multiplies the memory needed by your DLL by the number of processes which use it! Oops…

Update: fixed typo.