Interesting write up discussing the infection of Mach-O files including a link to the MachoMan virus.
9d69c3b4907c8e1936994a2ecc946ac572b798554a5137dca2538f08b0952d50<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en">
<head>
<meta http-equiv="expires" content="Thu, 07-Dec-2006 00:00:00 GMT" />
<title> roy g biv 'Infecting Mach-O Files' (VX heavens)</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<meta name="Author" content="roy g biv" />
<meta name="KeyWords" lang="en" content="virus,virii,vx" />
<meta name="Keywords" lang="ru" content="×ÉÒÕÓ,×ÉÒÉ" />
<meta name="Description" content="Mach-O is the native file format used by OSX. There is a little similarity to Portable Executable files, but not much. Mach-O files are collections of segments. Each segment can contain one or more sections, which have different protection attributes." />
<link rel="icon" href="/favicon.ico" type="image/x-icon" />
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />
<link rel="stylesheet" type="text/css" href="/style.css" />
</head>
<body bgcolor="#dbc8a0" text="#302000" link="#225599" vlink="#113366">
<div class="s1">
<h1>VX Heavens</h1>
</div>
<div class="s2">
<h1>Infecting Mach-O Files</h1><p>roy g biv<br /> <em>October 2006</em></p>
<p><a href="http://vx.netlux.org/src.php?info=machoman.zip">MachoMan virus</a></p>
<h2>What is a Mach-O file?</h2>
<p>Mach-O is the native file format used by OSX. There is a little similarity to Portable Executable files, but not much. Mach-O files are collections of segments. Each segment can contain one or more sections, which have different protection attributes.</p>
<h2>What does a Mach-O file look like?</h2>
<p>Everything about the format is public, most of the format is in loader.h. The file header structure is called mach_header. Each of the fields is 32-bits large. It has this format:</p>
<table border="1" summary="">
<tr><th>Offset</th><th>Field</th><th>Description</th></tr>
<tr><td>0x00</td><td>magic</td><td>sig (0xfeedface (PowerPC), 0xcefaedfe (Intel))</td></tr>
<tr><td>0x04</td><td>cputype</td><td>0x12 (PowerPC), 0x07 (Intel)</td></tr>
<tr><td>0x08</td><td>cpusubtype</td><td>specific architecture</td></tr>
<tr><td>0x0c</td><td>filetype</td><td>0x02 if executable</td></tr>
<tr><td>0x10</td><td>ncmds</td><td>number of commands following</td></tr>
<tr><td>0x14</td><td>sizeofcmds</td><td>total size of commands</td></tr>
<tr><td>0x18</td><td>flags</td><td> </td></tr>
</table>
<p>The commands are used for many different purposes, such as describing segments and sections, initial values of the CPU registers for the main thread, and resolving symbols (equivalent to imports in PE files).</p>
<p>The load_command structure has this format:</p>
<table border="1" summary="">
<tr><th>Offset</th><th>Field</th><th>Description</th></tr>
<tr><td>0x00</td><td>cmd</td><td>type of command</td></tr>
<tr><td>0x04</td><td>cmdsize</td><td>number of bytes in command (the value here can be larger than the command data, so this field must be used to reach the next command, do not rely on the command data)</td></tr>
</table>
<p>Interesting commands are LC_SEGMENT (1) and LC_UNIXTHREAD (5). The LC_SEGMENT command describes a segment of memory. It is equivalent to a section in PE files. The segment_command structure has this format:</p>
<table border="1" summary="">
<tr><th>Offset</th><th>Size</th><th>Field</th><th>Description</th></tr>
<tr><td>0x00</td><td>16</td><td>segname</td><td>name of segment (ignored, just like PE)</td></tr>
<tr><td>0x10</td><td>4</td><td>vmaddr</td><td>segment<em>virtual</em> address</td></tr>
<tr><td>0x14</td><td>4</td><td>vmsize</td><td>segment virtual size</td></tr>
<tr><td>0x18</td><td>4</td><td>fileoff</td><td>segment file offset</td></tr>
<tr><td>0x1c</td><td>4</td><td>filesize</td><td>segment file size (0 means empty)</td></tr>
<tr><td>0x20</td><td>4</td><td>maxprot</td><td>maximum protection attributes (can disallows writable code, for example, but clearing PROT_WRITE bit)</td></tr>
<tr><td>0x24</td><td>4</td><td>initprot</td><td>initial protection attributes (combination of READ, WRITE, EXEC, but PROT_WRITE requires PROT_READ)</td></tr>
<tr><td>0x28</td><td>4</td><td>nsects</td><td>number of sections following</td></tr>
<tr><td>0x2c</td><td>4</td><td>flags</td><td> </td></tr>
</table>
<p>A section is a piece of memory within a segment. The section_command structure has this format:</p>
<table border="1" summary="">
<tr><th>Offset</th><th>Size</th><th>Field</th><th>Description</th></tr>
<tr><td>0x00</td><td>16</td><td>sectname</td><td>name of section</td></tr>
<tr><td>0x10</td><td>16</td><td>segname</td><td>name of host segment</td></tr>
<tr><td>0x20</td><td>4</td><td>addr</td><td>section virtual address</td></tr>
<tr><td>0x24</td><td>4</td><td>size</td><td>section file size</td></tr>
<tr><td>0x28</td><td>4</td><td>offset</td><td>section file offset</td></tr>
<tr><td>0x2c</td><td>4</td><td>align</td><td>section alignment</td></tr>
<tr><td>0x30</td><td>4</td><td>reloff</td><td>relocation data file offset</td></tr>
<tr><td>0x34</td><td>4</td><td>nreloc</td><td>relocation data item count</td></tr>
<tr><td>0x38</td><td>4</td><td>flags</td><td> </td></tr>
<tr><td>0x3c</td><td>4</td><td>reserved1</td><td>interpretation depends on flags</td></tr>
<tr><td>0x40</td><td>4</td><td>reserved2</td><td>interpretation depends on flags</td></tr>
</table>
<p>The flags are a packed structure, the low 8 bits describe the section type, the top 8 bits describe the section user attributes, the next 8 bits describe the section system attributes.</p>
<h2>How do we infect it?</h2>
<p>I thought about this problem for a long time. The problem with the format is that some structures, like the symbol tables access sections by number, so we can't insert sections or segments. We could add a section to the end, but that would require possibly moving file data to make room, and some structures are difficult to parse properly, so that's not a good option. I thought about a cavity infector, but the only good cavity that I could find was in the __jump_table section, but the size cannot be altered, because it is used by the symbol loader. I considered appending to the __LINKEDIT segment, but it is discarded by the loader. I thought about moving some code from the __text section to the end of the file, and placing myself in the space, but then I would need to open the file to read it back.</p>
<p>Eventually, I started thinking about it differently. Each file is supposed to start with a __PAGEZERO segment, which marks the first 0x1000 bytes as not accessible. The file size there is 0, but I wondered if I could change it and load my code? Amazingly, it is so. All I had to do was pad the file to a multiple of 4kb first, to avoid a bus error, then append my code. After that, I set the file offset and size fields, and the protection flags so I can run.</p>
<h2>How to get control?</h2>
<p>This was a problem, too, for some time. I was using IDA to load the file, but at first I didn't see anywhere the entrypoint value. It seems that the Ilfak had the same problem, because IDA assumes that the entrypoint is always the first byte in the __text section. Of course, that's not true. :)</p>
<h2>Introducing LC_UNIXTHREAD</h2>
<p>The LC_UNIXTHREAD load command describes the register values for the main thread in the file. Yes, that includes EIP. By simply changing the value in the EIP field to another value, I was able to move the entrypoint around, but IDA did not notice, and continued to show the old one! It's a new type of entrypoint obscuring. ;) Even more interesting was that IDA refuses to load any segment which contains no sections (like __LINKEDIT and, more importantly, __PAGEZERO). That means my code is invisible, yet it runs.</p>
<p>The structure is of the thread_command type. It has this format:</p>
<table border="1" summary="">
<tr><th>Offset</th><th>Size</th><th>Field</th><th>Description</th></tr>
<tr><td>0x00</td><td>4</td><td>flavor</td><td>type of data following</td></tr>
<tr><td>0x04</td><td>4</td><td>count</td><td>number of dwords following</td></tr>
</table>
<p>The interpretation of the thread information depends on the data flavor. We are interested only in the i386_NEW_THREAD_STATE (1). In that case, it is a i386_thread_state_t structure, and it has the format:</p>
<table border="1" summary="">
<tr><th>Offset</th><th>Size</th><th>Field</th></tr>
<tr><td>0x00</td><td>4</td><td>eax</td></tr>
<tr><td>0x04</td><td>4</td><td>ebx</td></tr>
<tr><td>0x08</td><td>4</td><td>ecx</td></tr>
<tr><td>0x0c</td><td>4</td><td>edx</td></tr>
<tr><td>0x10</td><td>4</td><td>edi</td></tr>
<tr><td>0x14</td><td>4</td><td>esi</td></tr>
<tr><td>0x18</td><td>4</td><td>ebp</td></tr>
<tr><td>0x1c</td><td>4</td><td>esp</td></tr>
<tr><td>0x20</td><td>4</td><td>ss</td></tr>
<tr><td>0x24</td><td>4</td><td>eflags</td></tr>
<tr><td>0x28</td><td>4</td><td>eip</td></tr>
<tr><td>0x2c</td><td>4</td><td>cs</td></tr>
<tr><td>0x30</td><td>4</td><td>ds</td></tr>
<tr><td>0x34</td><td>4</td><td>es</td></tr>
<tr><td>0x38</td><td>4</td><td>fs</td></tr>
<tr><td>0x3c</td><td>4</td><td>gs</td></tr>
</table>
<p>and then we are done.</p>
<p>Greets to friendly people (A-Z):</p>
<p>Active - Benny - Malum - Obleak - Prototype - Ratter - Ronin - RT Fishel - sars - SPTH - The Gingerbread Man - Ultras - uNdErX - Vallez - Vecna - VirusBuster - Whitehead</p>
<pre>
rgb/defjam oct 2006
iam_rgb@hotmail.com
</pre>
</div>
</body>
</html>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed