Research is being done on a useless Cisco 1600 with 4 megs of Flash running IOS 11.1.
Recently after writting my first cisco warez (tunnelx), I told myself hey we need to find a way to inject arbitrary code, poke and peek at the memory on a cisco, hide interfaces, route-maps, access-lists.
now you can even dump the memory with 'show memory'. Good but there isn't a write memory command, too bad. Maybe not...
I started looking for undocumented and hidden commands and found quite a bunch of them.
Among all the stupid hidden command, the best candidate for taking full control of the cisco is 'gdb'.
The IOS gdb command offers three subcommands:
gdb debug PID examine PID kernel
the kernel subcommand works only on the console. However 'examine' and 'debug' works perfectly; the debug subcommand is a bit tricky to use though.
scep#gdb debug 27
oops..
Ok grab a copy of gdb-4.18 and try to compile a version for your cisco. mkdir m68k-cisco ../configure --target m68k-cisco make
if you have a mips based cisco, just s/m68k/mips64/ the above 4 lines.
now type make install and you should have a m68-cisco-gdb binary in your path.
fire# m68k-cisco-gdb GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-cisco". (cisco-68k-gdb)
my cisco 1600 is connected to /dev/ttyS0, scep>en PassWord: scep#gdb debug 18
scep#
As you can see it bails out if you hit return. while examine works it seems.
scep#gdb examine 18
now the console seems locked. go back to our gdb-4.18 source tree and check out gdb/remote.c which contains a nice documentation of the gdb remote communication protocol. added.
IOS gdbserver implementation Don't get too excited, IOS gdbserver supports only a limited subset of those commands. I'll grab a binary of IOS 12 and check if new commands were added. I didn't have to test every command by hand.. let's just say I have reliable sources and I know that in IOS 11.2-8 (hum hum), the following commands are supported:
Request Packet
read registers g write regs GXX..XX Each byte of register data is described by two hex digits. Registers are in the internal order for GDB, and the bytes in a register are in the same order the machine uses. read mem mAA..AA,LLLL AA..AA is address, LLLL is length. write mem MAA..AA,LLLL:XX..XX AA..AA is address, LLLL is number of bytes, XX..XX is data continue cAA.AA AA..AA is address to resume IF AA..AA is omitted resume at same address. step sAA..AA AA..AA is address to resume If AA..AA is omitted, resume at same address.
kill request k last signal ? Reply the current reason for stopping. This is the same reply as is generated for step or cont : SAA where AA is the signal number. toggle debug d toggle debug flag (see 386 & 68k stubs)
All other commands will be ignored... too bad 'search' isn't implemented.
The protocol is simple, quoting remote.c comments:
A debug packet whose contents are <data> is encapsulated for transmission in the form. $ <data> # CSUM1 CSUM2
<data> must be ASCII alphanumeric and cannot include characters '$' or '#'. If <data> starts with two characters followed by ':', then the existing stubs interpret this as a sequence number.
CSUM1 and CSUM2 are ascii hex representation of an 8-bit checksum of <data>, the most significant nibble is sent first. the hex digits 0-9,a-f are used.
Before trying to make gdb work i wrote a little program that computed the right checksum:
#include <stdio.h> unsigned char const hexchars[] = "0123456789abcdef"; char tohexchar (unsigned char c) { c &= 0x0f; return(hexchars[c]); }