You can see a high resolution of the images below by clicking on them.

Step 0: what tools you need – a long Philips (“cross”) screwdirever, preferably one with magnetic tip (but you can manage without it).

Step 1: disconnect the antenna from the wireless card. This is important, since it is connected to the LCD panel, which we need to remove. Do this by pulling carefully upwards on the connectors (not the wire). Don’t worry about knowing which wire goes where when reassembling, since it is clearly marked (with small white / black arrows).

Step 2: tilt the screen all the way backwards (so that it is parallel with the bottom part) and remove the upper part of the cover. There is a small opening where the marking is on the image, you can start there. Carefully remove the whole cover. It has a couple of plastic “ears” which you have to be careful not to break.

Step 3: remove the battery, hard drive, optical drive and bluetooth adapter. You eject the battery by sliding the middle lever. Remove the hard-disk by removing the two screws marked at the right. You can also remove the bluetooth adapter, which is near the harddisk. Sidenote: except the screws from the harddrive, you can distinguish the screws from the lower part and the upper part by their length. The rule is: lower part – long screws, upper part – short screws. To remove the optical drive, first remove the screw marked by a lock, and then push on he metal part with the screwdriver. This should pop it out just enough that you can pull on it.

Step 4: remove the screws holding the screen and the two screws holding the keyboard.

Step 5: disconnect the CMOS battery (this will result in you loosing your BIOS settings, which you will have to reset at the first boot after assembly). Also, disconnect the keyboard. This is a tricky connector: you have to flip the upper part open to remove the cable. Also, when putting it back, you first have to make sure that you’ve properly aligned the cable with the connector, and then push down on it. If it doesn’t go easy, don’t force it, rather take it out and try again, making sure that the alignment is correct (straight).

Step 6: disconnect the LCD panel and remove it. Unscrew the upper part, in the locations marked with “P”. Disconnect the two cables linking it to the mainboard (the ones towards the middle). Flip the base over and remove the bottom screws also. At this point you can separate the upper and lower part of the base.

Step 7: You can remove the PCMCIA adapter.

Step 8: The laptop is almost completely unassembled at this point. You can continue removing parts if you need to, however take care when working around the coolers: tightening them too much can result in the CPU/GPU cracking. Make them too loose however, and your cooling will suffer.

Happy hacking!

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.

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.