ret2libc - Reverse Engineering & related

Hacking Coradir STB CDR1000D HDTV Receiver

noreply@blogger.com (topo) — Mon, 09 Aug 2010 18:25:00 +0000

It's been a long time since I last wrote something 'interesting' so I'll try to start doing so more often or at least to use this blog as an ideas repository instead of my never ending TODO list :)

A couple of months ago I had the opportunity to try the Set Top Box CDR1000D from Coradir (may be this procedure works for the CDR1000, too) which is an HTDV receiver being sold in Argentina and also given for free (on certain cases) by the government to impulse the Digital Terrestrial Television initiative. The CDR1000 uses an ARM-based processor called CSM1201 produced by Celestial Semiconductor.

There are a couple of things I usually do when I get an embedded device of any kind and I'm allowed to play with it, meaning remove it's case (as opposed to what happened when I tried to open my wife's Garmin Nuvi GPS but that's another story) :

Try to identify any JTAG or Serial communication port on the board.
Download any available firmware at the manufacturer/vendor page and try to reverse engineer it.
Identify any EPROM memory and download it's data-sheet to dump it's content.

Step 1 is the easiest one but given that at the moment there was no firmware update available on the vendor web page then I started to look at the board and proceed with step 2 to look for any pins fooling around waiting to be used.
As you can see in the picture there are a couple of candidates so I decided to start trying with the one with four pins which looks like a serial port to me... so I took my multimeter and started to try to figure out the pinout doing the following:

Unplug the device or turn off the main circuit breaker before attempting anything.
Set your multimeter for continuity test to identify the GND (Ground) by looking for connectivity between anyone of those pins and the outer (metallic) part of any of the connectors outside the box. Don't worry, this won't harm the device.
Turn on the device.
Set your multimeter to measure VCC, then connect the (usually) black cable from the multimeter to the pin previously identified as GND. Then connect the (usually) red cable from your multimeter to each of the other pins available and when you find one measuring 3.3V then you've got VCC.
The two remaining are either Tx (Transmission) or Rx (Reception) and they can be easily figured out later but you can deduce that Rx won't have any activity because it's the cable where you connect the Tx end of your RS232 adapter as explained later (or the Bus Pirate through my pythom module pyBusPirate2) to transmit the data from your computer to the STB. Opposed to this, the Tx pin should have some activity in case that the device sends any information (usually during boot sequence).

Next I used my home-brew RS232 Adapter (it's just a simple TTL level converter) which is similar to the ones in this page http://www.scienceprog.com/alternatives-of-max232-in-low-budget-projects/ (or you can just Google on how to create your adapter to connect your PC to a IC).
Because my adapter needs 5v I took them from the USB connector in the read of the CDR1000D (shame on me!) and connected the GND cable from the adapter to the GND pin discovered on the board and then took the Rx cable of my adapter to one of the two still mysterious pins (remember that we've already identified GND and VCC so those two remaining pins are Tx and Rx but we still don't know which one is what).
On the computer side I opened a terminal and started cu at a baud-rate of 4800 (I didn't know the correct baud-rate yet but even if it's right or wrong you should see something in the terminal is the pin where we connected the cable is the correct one (device Tx instead of RX). Of course the first try was not correct (lucky me) so I tried the other pin and some garbage started to appear on the screen so at that moment I knew the cable was correctly connected as shown bellow and garbage was due to the incorrect baud-rate of the terminal.

I began trying all the different baud-rates until I found the correct one, 115200, which was obviously the last try. Finally I used the following parameters:

me@host $ cu -l /dev/ttyUSB0 -s 115200

... and I started to receive some output from the device so I restarted it and got the following:

U-Boot 1.2.0 (May 13 2010 - 14:10:45)

DRAM: 256 MB
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
Flash: 0 kB
NAND:
Bad block table found at page 131040, version 0x01

Bad block table found at page 131008, version 0x01
64 MB
SPI Booting... Speed at [R:10MHz/W:5MHz] Flash Size: 1MB
Init CSM1201 I2C!
In: serial
Out: serial
Err: serial
MAC: 00:1a:cc:08:f8:cd
Hit any key to stop autoboot: 0
Init CSM1201 I2C!

EEPROM @0x50 read: addr 00001000 off 0200 count 1 ... done
Init CSM1201 I2C!

EEPROM @0x50 read: addr 00100000 off 0004 count 1 ... done
## Booting image at 34060000 ...
Bad Magic Number
USB: ERROR : No interrupt for (0xa)
Error, couldn't init Lowlevel part

NAND read: device 0 offset 0x0, size 0x200000

Reading data from 0x1ffe00 -- 100% complete.
2097152 bytes read: OK
## Booting image at 03000000 ...
Image Name: Linux-2.6.12.5
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1586828 Bytes = 1.5 MB
Load Address: 00008000
Entry Point: 00008000
OK

Starting kernel ...

Uncompressing Linux.................................................................................................... done, booting the kernel.
Linux version 2.6.12.5 (root@localhost.localdomain) (gcc version 3.4.6) #1 Thu Apr 22 05:37:00 UTC 2010
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
Machine: ORION
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists
Kernel command line: root=/dev/mtdblock/1 rw rootfstype=jffs2 console=ttyS0,115200 mem=64M mtdparts=ORION:2m(Part01),-(Part02) ethaddr=00:1A:CC:08:F8:CD
ORION Readed MAC:00:1a:cc:08:f8:cd
PID hash table entries: 512 (order: 9, 8192 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 64MB = 64MB total
Memory: 61568KB available (2467K code, 645K data, 96K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
SCSI subsystem initialized
Linux Kernel Card Services
options: none
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NetWinder Floating Point Emulator V0.97 (extended precision)
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
NTFS driver 2.1.22 [Flags: R/O].
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
fb0: ORION frame buffer @[0xf400000, 0xc4880000] size 0xc00000
fb1: ORION frame buffer @[0xe800000, 0xc5500000] size 0xc00000
ORION GPIO at 0x101e4000, 16 lines
ORION GPIO2 at 0x10260000, 55 lines
Smart card: base address 101f0000 map to c4866000
Orion Watchdog Timer: timer margin 40 sec
Xport: Init OK [0x0e100000].
orion_video: Orion Video driver was initialized, at address@[phyical addr = 41600000, size = 100000]
csdrv audio init ok ...
Default ORION I2C at 0x10170000, 100KHZ
orion15_df: Orion Display feeder driver was initialized, at address@[phyical addr = 41800000, size = 1000]
orion15_df: Orion TVE0 driver was initialized, at address@[phyical addr = 10168000, size = 1000]
orion15_df: Orion TVE1 driver was initialized, at address@[phyical addr = 10160000, size = 1000]
pinmux0 : 0x0, pinmux1: 0x1001
dma_pool_alloc: dma_phy_addr: 3d2a000, ttx_buf: ffc00000
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
ttyS0 at MMIO 0x101f1000 (irq = 12) is a 16550A
ttyS1 at MMIO 0x101f2000 (irq = 13) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
RAMDISK driver initialized: 1 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
ORION eth0: 0x41400000 IRQ 24 MAC:00:1a:cc:08:f8:cd
Not SST flash.<5>physmap flash device: 800000 at 34000000
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)
Using command line partition definition
Creating 2 MTD partitions on "ORION":
0x00000000-0x00200000 : "Part01"
0x00200000-0x04000000 : "Part02"
PCMCIA: orion_pcmcia_init called!
Succesefully create pcmcia proc entry!
orion socket ci module initializing!!!
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
drivers/usb/musb/musb_driver.c: Initializing MUSB Driver [npci=1][gadget=no][otg=no]
MUSB Drive version 1.1.0.1
mgc_controller_init: Driver instance data at 0xc3d3ce00
mgc_hdrc_init: MHDRC version 1.500 info: UTMI-8, dyn FIFOs, SoftConn
mgc_controller_init: End 00: FIFO TxSize=0040/RxSize=0040
mgc_controller_init: End 01: Shared FIFO TxSize=0200/RxSize=0200
mgc_controller_init: End 02: FIFO TxSize=0000/RxSize=0040
mgc_controller_init: End 03: Shared FIFO TxSize=0400/RxSize=0400
mgc_controller_init: New bus @0xc3d1a820
musb-hcd usb0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Empty flash at 0x017bdca0 ends at 0x017bde00
Empty flash at 0x026427d8 ends at 0x02642800
jffs2_scan_dirent_node(): Node CRC failed on node at 0x02dd53e8: Read 0xffffffff, calculated 0xacd3f548
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 96K
Warning: unable to open an initial console.
jffs2_get_inode_nodes(): Data CRC failed on node at 0x02641db0: Read 0x3444ce97, calculated 0xf1cad815
jffs2_get_inode_nodes(): Data CRC failed on node at 0x017bd4a4: Read 0xd94d27c4, calculated 0xdebb94f3
-/bin/sh: ./test_fwdebug: not found
[1] + Done(127) ./test_fwdebug 1 1
============= SBDevFonts ============
0: rbf-fixed-rrncnn-12-24-ISO8859-1, charsetname: ISO8859-1, style: 0
========== End of SBDevFonts =========

============= MBDevFonts ============
1: rbf-fixed-rrncnn-24-24-GB2312-0, charsetname: GB2312-0, style: 0
2: rbf-fixed-rrncnn-*-*-UTF-8, charsetname: UTF-8, style: 0
3: rbf-fixed-rrncnn-*-*-UTF-16LE, charsetname: UTF-16LE, style: 0
4: rbf-fixed-rrncnn-*-*-UTF-16BE, charsetname: UTF-16BE, style: 0
========== End of MBDevFonts =========
system font 0: rbf-fixed-24-ISO8859-1
system font 1: *-fixed-24-GB2312-0
warnning: You have no fip frontpanel!
IAL: Use orionfpc engine.
MiniGUIMain 27630
default key_value = 0x1c
....
default key_value = 0x2 Set Led Charecters Success
Timing mode =21
loading xport firmware
write gpio 15 to 1
readed xport fw data section size =240
readed xport fw text section size =10872
loded xport firmware
CS_CRC_Init error = 1, time[28040]
CS_DB_Init error = 1, time[28110]
CS_AV_Init error = 1, time[29080]

GPIO0 Write 1 Succeed!!!
definition_index = 1
bufsize = 9437184
read_len = 2652 ,===no data
read_len = 2652 ,===no data
read_len = 2652 ,===no data
read_len = 2652 ,===no data
AspectRatio = 15
CS_AV_Play_IFrame 29980
DB_DemuxInit error = 0, time[29980]
PDmx_SFilter->pid = 0x0
PDmx_SFilter->pid = 0x2
PDmx_SFilter->pid = 0x11
PDmx_SFilter->pid = 0x10
CS_SI_Init error = 1, time[29980]
CS_DT_Init error = 1, time[29980]

GPIO6 Write 0 Succeed!!!

GPIO6 Write 1 Succeed!!!
CS_FE_Init error = 1, time[31520]
CS_INSTALL_Init error = 1, time[31520]
PDmx_SFilter->pid = 0x12
PDmx_SFilter->pid = 0x12
CS_EIT_Init error = 1, time[31530]
-----------------------------
CS_TIMER_Init error = 1, time[31720]
PDmx_SFilter->pid = 0x14
PDmx_SFilter->pid = 0x14
CS_DT_Start

GPIO0 Write 1 Succeed!!!
definition_index = 1
[USB_CON]:UsbCon_Umount().
[USB_CON]:UsbCon_Init().
[USB_CON]:Creating usbcon thread.
$125336 Set Led Charecters Success MSG_CHECK_SERVICE_LOCK = 0 *****************************CS_MW_PlayServiceByIdx************************* CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout! CSDEMUX_Filter_ReadWait Timeout!
CSDEMUX_Filter_ReadWait Timeout!

Killed

# ls -la
drwxr-xr-x 3 528 528 0 Dec 4 2009 .
drwxr-xr-x 18 root root 0 Jan 1 00:00 ..
-rwx------ 1 root root 601945 May 14 2010 csapp.elf
-rwx------ 1 root root 127352 Jan 1 00:09 database
drwxr-xr-x 2 root root 0 May 14 2010 resource
-rwx------ 1 root root 45817 Dec 4 2009 test_fwdebug.bak
# uname -a
Linux uclibc 2.6.12.5 #1 Thu Apr 22 05:37:00 UTC 2010 armv5tejl unknown
# whoami
root

At this point I connected an Ethernet cable from my computer to the device and issued:

# ifconfig eth0 192.168.100.100 netmask 255.255.255.0 up
# ping 192.168.100.101
PING 192.168.100.101 (192.168.100.101): 56 data bytes
64 bytes from 192.168.100.101: seq=0 ttl=64 time=10.000 ms
64 bytes from 192.168.100.101: seq=1 ttl=64 time=0.000 ms
64 bytes from 192.168.100.101: seq=2 ttl=64 time=0.000 ms
64 bytes from 192.168.100.101: seq=3 ttl=64 time=0.000 ms
64 bytes from 192.168.100.101: seq=4 ttl=64 time=0.000 ms

--- 192.168.100.101 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.000/2.000/10.000 ms
#

GAME OVER!!!

Awesome ATM hack

noreply@blogger.com (topo) — Thu, 04 Jun 2009 20:17:00 +0000

ATM fraud is not new but what those guys have done is pretty cool (from the technical point of view, of course) :

Cybercriminals are improving a malicious software program that can be installed on ATMs running Microsoft's Windows XP operating system that records sensitive card details.

The malware records the magnetic stripe information on the back of a card as well as the PIN (Personal Identification Number), which would potentially allow criminals to clone the card in order to withdraw cash.

The collected card data, which is encrypted using the DES (Data Encryption Standard) algorithm, can be printed out by the ATM's receipt printer.

The malware is controlled via a GUI that is displayed when a so-called "trigger card" is inserted into the machine by a criminal. The trigger card causes a small window to appear that gives its controller 10 seconds to pick one of 10 command options using the ATM's keypad.

The entire article is here and the analysis of the malware is here.

Mind-blowing netifera upcoming features

noreply@blogger.com (topo) — Thu, 09 Apr 2009 16:00:00 +0000

I have to say that I'm very proud for the work that the guys have been doing on netifera.

Even tough I'm not working with them anymore, I know the guys and what they were capable of and this is the proof.
Those upcoming features like Probe deployment and Geographical Visualization are only the tip of the iceberg.

There is not much to add, just take a look at the video and you'll understand...

Conficker C analysis

noreply@blogger.com (topo) — Sun, 29 Mar 2009 18:30:00 +0000

For all of you living under a rock, there is a very interesting virus infecting machines all over the internet and into corporate networks as well (more than you think... ehehehe).
It had a huge impact due to certain characteristics it posses and it's worth reading about them.

The people of SRI International have made a great analysis of the virus and I recommend everyone reading it because it's very interesting.
Click HERE to see the analysis.

Enjoy!

netifera beta 2 is out!

noreply@blogger.com (topo) — Fri, 12 Dec 2008 12:58:00 +0000

If you are a lazy bastard who didn't contact us to receive notification about netifera then move your lazy ass and and download it HERE.

This version doesn't include any new exciting eye-candy feature but it does have something new. If you like developing security stuff then you'll probably love this release cause you will be able to develop sniffing modules by following the Sniffing Module Tutorial in the documentation section of netifera home page.

This is just the first one of a series of articles about how to create your own sniffing modules and integrate them into netifera either by using a your favorite text editor and a script or using Eclipse (which is now the number one IDE in my list). you may think that it's more comfortable not to use Eclipse but I promise you that once you try it, you love it and you want to keep using it every time.

If you are interested in the changes/bug fixes done for this beta 2 then take a look at the changelog.

netifera beta was released at XCON2008

noreply@blogger.com (topo) — Wed, 26 Nov 2008 11:35:00 +0000

A couple of the guy and I came to Beijing, China to talk about netifera.
For those who has been living under a rock, netifera is the next generation, ass-kicking platform for security tools done in Java supporting multiple OS's and remote tools execution with an awesome piece of code called 'peludo' and it's partner called 'the probe'.

If you are interested in reading the presentation you can take a look at it here at the end of this post and also I'd recommend to download netifera and try it.

At this moment netifera beta builds for Linux and Mac OS X are available for download HERE (yes, dumb-ass, click here!) and also you will find a startup guide explaining some interesting aspects of it along with it's installation process which is really simple. In a future we'll have the windows version available also, but not yet :)

All the feedback will be very appreciated and if you are interested on seeing something implemented on netifera for the next release, let us know. I cannot make promises but we'll surely appreciate everyones opinions (if they match our opinions... ehehehe).

There are some interesting posts at the netifera blog here so you should take a look at it.

Here are the slides of the presentation.. have fun:

New dreams, new challenges, old friends... Netifera

noreply@blogger.com (topo) — Mon, 13 Oct 2008 00:31:00 +0000

What am I talking about? It's about something that I've been waiting for long time. It's the opportunity to create something from scratch, being able to do something awesome and share it with others, working with incredible intelligent people, creating a cutting edge security related stuff which will blow everyone' head off ... all this things I've described and more are the things I feel about working on Netifera, the next generation multi-platform security framework.
We all have bunch of experience in the security field but saying it is one thing and proving it is another so we'll try to probe the last one by creating the ultimate security platform.
If you are interested on what I talking about then stay tuned and also checkout Netifera website to see the news about this kick-ass tool :)

CitectSCADA vulnerability 90's Style

noreply@blogger.com (topo) — Wed, 11 Jun 2008 15:55:00 +0000

Does the SCADA community get interested in security? I think they not because they always say "don't touch those things, you could hurt people" to avoid moving their asses to secure their networks so with this bug and the previous about Wonderware DoS they will probably start to really secure their products and do better things during the development process.

Some people asked me how I found the vulnerability and the answer is simple:

1) Download and install the soft, duh!!!!
2) Select a process with a port listening for incoming connections (I just selected the first one I saw)
3) Start your favorite debugger
4) Set a breakpoint on recv() function (the one that receives info from TCP connections)
5) Use your favorite programming language (mine is python) and create a script to send a bunch of A's.
6) When the breakpoint hits, start debugging. You'll usually see that a byte of two are read from the socket and that is processed as the length of the rest of the packet so you could adjust your script to send a packet with those bytes at the beginning representing the length.
7) If you step out a function or two, you'll see the function that processes the packet content according to the length specified.
8) In those parser functions, you'll usually see that a byte or two are read from the packet and interpreted the field type (That is usually a huge switch-case).
8) According to the operation selected by the byte read, a byte or two are read as the size of the field to process (like Tag-Length-Value).
9) The field is copied into a fixed-size buffer on the stack by the length specified in the packet... OUCH!!! Eip = 0x41414141 ??? That's not good (for them... ahhaha)

peace!!!!!!!!!!!!!

IOS rootkit technical paper

noreply@blogger.com (topo) — Fri, 06 Jun 2008 19:57:00 +0000

Finally! The technical (in my humble opinion) paper called 'Killing the myth of Cisco IOS rootkits' that I wrote about the subject is available at CORE Security site here.
Enjoy... and send feedback ;)

CISCO response on IOS rootkits

noreply@blogger.com (topo) — Mon, 02 Jun 2008 23:07:00 +0000

'Rootkits on Cisco IOS Devices' is a document published by CISCO in response to my presentation on IOS rootkits.
It talks about several security measures to take to detect binary image modification but I think that there are some things that are worth mentioning:
1) System Administrators don't read logs very often.
2) Implementing AAA is not easy task for every company (specially small-med sized corps).
3) Using the 'verify' or any other CLI command can easily be hooked by DIK and return whatever it wants instead of the real values.

Ohh come on! You cannot rely on any information given by IOS because this is equivalent than diagnosing an infected Windows machine from within the infected OS.

Let's analyze the case of the verify command.
If you execute that command on any IOS you get an output like:

router#verify /md5 disk0:c7301-jk9s-mz.124-10.bin 0c5be63c4e339707efb7881fde7d5324
..........Done!

%Error verifying disk0:c7301-jk9s-mz.124-10.bin
Computed signature = ad9f9c902fa34b90de8365c3a5039a5b
Submitted signature = 0c5be63c4e339707efb7881fde7d5324

router#

So, now we know the strings used by this command, and if we go to IDA and take a look at the strings list (View->Open Subwindows->Strings) we could find any of those strings like '%Error verifying ' (which is obviously located next to the previously seen strings 'Computed signature = ' and 'Submitted signature = ') which will take us directly to the function that displays the verify command output.
Now that the function is located, we can do the known procedure of intercepting it's call and check if the filename to verify is the router image and just display the output we want (previously obtained printf() memory address, right?).
A different approach could be to intercept open_file() to check if the IOS filename is opened and set a flag inside the rootkit so that any call to read_file() with the FD (File descriptor) of the previous call to open_file() must be monitored to return the original bytes of the image at it's corresponding locations. But this is more difficult and some other things have to be taken into consideration.
So this sounds difficult? How about intercepting the function that received a char* with the calculated MD5 and overwrite it with the correct value previously stored inside the rootkit? That sounds way too easy, right? Well, it is! ;)

Now what do you think about verify /md5 command? Useful? Yeah right...

CISCO IOS rootkits presentation slides

noreply@blogger.com (topo) — Sun, 01 Jun 2008 19:55:00 +0000

The slides of my presentation at EuSecWest 2008 in London and at PH-Neutral 0x7d8 are online on CORE's website but those are not exactly the ones I showed because there were some typos and the ASCII graphics were also changed so the presentation with the original (cool) graphics and without errors is here.
Bellow is the slides show if you want to take a quick look:

The sky isn't falling yet, but it will

noreply@blogger.com (topo) — Wed, 28 May 2008 20:11:00 +0000

I was talking to Nico Fischbach about the IOS rootkit during PH-Neutral 0x7d8 while drinking some beer... A few after that, he sent me an email with a summary about the rootkit stuff and all the noisy. The mail was sent to some mailing lists like Full Disclose and here is a link to it for those who didn't have the chance to read it.
The email is a good overview about the rootkit PoC and takes into consideration lot's of security measures to detect an attack vector like image binary modification... but what about using the same technique (find strings to find important functions) is applied on-the-fly or by a shellcode?
He mentions that TCL scripts can be easily detected in startup/running configuration but what if the functions that read the startup file and display running processes are manipulated?
I don't want to start enumerating counter measures to the detection measures because this is the same as the virii & AV race where one creates a new way to infect a machine and the other creates a new way to detect it and so on. Besides Nico is right that it is a 'noisy' to perform that kind of rootkit deployment but like said before, what if this is performed using a shellcode via a remote exploit?
Don't get me wrong, I really liked what Nico wrote but just want to say that there is always a way to enhance 'things' to bypass security, right?

Another important thing is to follow Cisco security guidelines... just in case because you never know if some inside user gets pissed off and installs it before leaving the company? :/

PH-Neutral 0x7d8 Soccer World Cup finals

noreply@blogger.com (topo) — Wed, 28 May 2008 02:00:00 +0000

Italian table soccer team (Igor - twiz) beats Argentinian team (shadown - topo) :(
Next year we'll have a rematch after some practice, of course... hahahaha
Here is a link to the YouTube video uploaded by a friend of mine (thanks Mario) in case you can't see the video bellow.

Rootkits on routers... uhm

noreply@blogger.com (topo) — Fri, 16 May 2008 20:49:00 +0000

Pretty noisy topic, right? Well, this is definitely not a new thing. Rootkits for IOS existed for quite a few years and that is what i told Sean when we talk about my presentation on EuSecWest among some other things.

Remember the news about stolen IOS source code? That definitely helped the bad guys cause reversing and entire IOS image was not necessary anymore... so what do you think the bad guys did with this source code? :P

printf("Hello World\n");

noreply@blogger.com (topo) — Thu, 03 Jan 2008 21:43:00 +0000

Every nerd makes it's first blog post with a 'hello world' reference, right?
I can't help it...
Anyway, this is a blog created to dump all sort of crazy ideas that get inside my head and share them with everyone interested.
I'll also put some code here that made my life easier when I was reversing some crappy code :P

see ya!