Ouch. it sucks she broke it but at least you have a “guinea pig” now. Do you happen to have the hardware to solder to the nand so you can read/write? that would be awesome. I have been able to run some commands as root! ;D
I have been able to unpack > modify > repack and run the 3.0 update. For now I am playing with the updater portion (b_138271353801) by injecting my own script into init.d. My goal at the moment is to dump the nand. I had the first success last night and was able to dump out some common things. I didn’t learn tooo much more than I already knew from them but something is better than nothing. The script ran way too early in the boot process so syslog wasn’t even up yet. Below is that info. For anyone who did not know… the tstat is based on the Freescale IMX35PDK: i.MX35 Product Development Kit… there is a plethora of info on their website.
offsets of NAND "partitions" 0x00000000-0x00200000 : "nand.redboot" 0x00200000-0x00700000 : "nand.kernel" 0x00700000-0x10100000 : "nand.rootfs" 0x10100000-0x29100000 : "nand.upgrade" 0x29100000-0x40000000 : "nand.factory" <- im guessing this is going to hold the magic data we want to get our hands on.
output of uname -a Linux ComfortControl 2.6.26-466-ga04670e #1 Thu Oct 17 01:35:01 CDT 2013 armv6l unknown
output of ps aux PID Uid VSZ Stat Command 1 root 2800 SW init 2 root SW< [kthreadd] 3 root SW< [ksoftirqd/0] 4 root SW< [watchdog/0] 5 root SW< [events/0] 6 root SW< [khelper] 89 root SW< [kblockd/0] 92 root SW< [cqueue] 100 root SW< [mxc_spi.0] 120 root SW< [kmmcd] 127 root SW< [mc13892/0] 190 root SW [pdflush] 191 root SW [pdflush] 192 root SW< [kswapd0] 234 root SW< [aio/0] 239 root SW< [nfsiod] 865 root SW< [mtdblockd] 894 root SW< [rpciod/0] 896 root SW< [mmcqd] 908 root SW [mxc_ts] 909 root SW [pdflush] 912 root 2800 SW init 913 root 2800 SW /bin/sh /etc/rc.d/rcS 935 root 1600 SW< udevd --daemon 1717 root 2800 RW /bin/sh /etc/rc.d/init.d/filesystems start 1740 root 2804 RW ps aux
whoami - rootid - uid=0(root) gid=0(root)
as you can see the system is barely booted at the point I was in last night. Since I am injecting before the update actually runs I can just hit cancel when it gets to that point so pretty much no chance of bricking… getting there… I need to get it to load the mtd kernel module… load the “partitions” and then dump them with the following…
#dump the nand partitions ###0x00000000-0x00200000 : "nand.redboot" nanddump -f /media/sd-mmcblk0p1/mtd0 /dev/mtd0###0x00200000-0x00700000 : “nand.kernel”
nanddump -f /media/sd-mmcblk0p1/mtd1 /dev/mtd1###0x00700000-0x10100000 : “nand.rootfs”
nanddump -f /media/sd-mmcblk0p1/mtd2 /dev/mtd2###0x10100000-0x29100000 : “nand.upgrade”
nanddump -f /media/sd-mmcblk0p1/mtd3 /dev/mtd3###0x29100000-0x40000000 : “nand.factory”
nanddump -f /media/sd-mmcblk0p1/mtd4 /dev/mtd4
I think a wiki is a great idea. Im going out of town for the weekend so I can’t do it just yet. I have attached a zip with the outputs that actually returned things. The logs are named after the command ran as you can see from my “payload” below.
###dump all the things! dmesg > /media/sd-mmcblk0p1/dmesg df > /media/sd-mmcblk0p1/df du > /media/sd-mmcblk0p1/du free > /media/sd-mmcblk0p1/free id > /media/sd-mmcblk0p1/id ps aux > /media/sd-mmcblk0p1/ps uname -a > /media/sd-mmcblk0p1/uname whoami > /media/sd-mmcblk0p1/whoami wreep -h > /media/sd-mmcblk0p1/wreep boardrev -r > /media/sd-mmcblk0p1/boardrev lsmod > /media/sd-mmcblk0p1/lsmod
EDIT:
PS… i noticed last night that dropbear (the ssh server) is started with the -w argument. -w = no root login. So the only way in even with the password on a “stock” firmware will be with the raptor21 user… which from groups file doesn’t have much permissions. One thing at a time though… Hopefully once SSH’d into the raptor21 acct I/we can exploit something to escalate privileges. Ideally I could modify the jffs2 image in the update and remove the -w switch from the init.d script that loads dropbear… but I have not had the balls to do that yet =P
My “end goal” at the moment is to be able to format a portion of the SD card as an ext partition that the tstat can use, inject into one of the startup scripts in the jffs2 img in the update and then install it so that when it boots it will attempt to mount the ext2 partition on the sd card and run an “init.sh” script from it if it exists… then we can put anything we want to do/run on the card and start it from the script. I think that’s the safest way as it doesn’t modify the stock firmware much… the init.sh script could do something like killall dropbear > adduser > restart dropbear etc. thoughts?
Phorkus - think it might be possible to add a SD card with the directory clii_logs on it, in a fat32 partition, and see if it writes interesting things there (like passwords, seeds, hashes, etc.). I'll see about setting up a full emulated environment and package it as a VM for folks once I figure out how to do so. Anyone interested in a compiler image, as well, to write custom "applets" for the XL? I know I'd love to know how to install additional applications, and since it's Linux with XML configuration files, I think it's most likely very possible to do.
Ill have to give the clii_logs dir a try… the VM image and compiler sound awesome! keep us updated. Also let me know what you can figure out from IDA… I had to stop staring at it… it was making my brain hurt haha. It made me REALLY appreciate high level languages! The functions I listed the other day are pretty short… so im sure that someone who understands assembly will have no problem identifying exactly what it does to generate the password before issuing the ‘passwd’ cmd.
I have never tried to “hack” into anything before… im having a blast with this =) I wish I had a second one… the GF gives me the “look” everytime I stick an SD card into it… ill be in the dog house if I break it =P