9. The entry point

 

The longest part of the journey is said to be the passing of the gate.

 Marcus Terentius Varro

If we decide to leave entry_point as it is, we have to patch something else. One approach is to disassemble the code, starting at entry_point, find the first call (or jmp) and abuse it. This requires way too much intelligence for a virus, though. But then we are operating in a homogeneous environment, having one compiler and one C run-time library for all. The startup code should be the same for every executable.

Command: pre/sparc-sunos5.7/entry_point/gdb/SunOS.sh
#!/usr/xpg4/bin/sh
pre/sparc-sunos5.7/entry_point/gdb_core.sh \
| /usr/xpg4/bin/sed -ne '/<_init>/,/<_exit>/p' \
| pre/sparc-sunos5.7/magic_elf/gdb_format.pl

We uses the tool from Extracting e_entry to retrieve the entry point. On some shells a read from a pipe opens a sub-shell, i.e. it does not export the variables to the surrounding scope. The while loop is executed just once. Its only purpose is to build a block for read.

Command: pre/sparc-sunos5.7/entry_point/gdb_core.sh
#!/usr/xpg4/bin/sh
file=${1:-/usr/xpg4/bin/sh}

tmp/sparc-sunos5.7/evil_magic/e_entry ${file} \
| while read entry_point offset
do
  /usr/bin/echo "[entry_point=${entry_point}]"
  /usr/local/bin/gdb ${file} -q <<EOT 2>&1
	
	break *0x${entry_point}
	run
	disassemble 0x${entry_point} 0x${entry_point}+0x100
EOT
done

Output: out/sparc-sunos5.7/entry_point/sh.gdb
0x17688 <_start+196>:     call          0x3c610 <_init>
0x1768c <_start+200>:     nop           
0x17690 <_start+204>:     mov           %l0, %o0
0x17694 <_start+208>:     mov           %l1, %o1
0x17698 <_start+212>:     mov           %l2, %o2
0x1769c <_start+216>:     mov           %l3, %o3
0x176a0 <_start+220>:     call          0x28560 <main>
0x176a4 <_start+224>:     nop           
0x176a8 <_start+228>:     call          0x4e548 <exit>
0x176ac <_start+232>:     nop           
0x176b0 <_start+236>:     call          0x4e554 <_exit>