Results 1 to 2 of 2

Thread: when/how does /etc/shadow get created on the live image?

  1. #1
    Member whitelisted's Avatar
    Join Date
    Feb 2010

    Default when/how does /etc/shadow get created on the live image?

    if I mount filesystem.squashfs from off the bt4-final image and try to find where/how root's password is stored, I can't find it.

    root@bt:~# mount -o loop /mnt/host-shared/bt4-final.iso /media/cdrom
    root@bt:~# mount -o loop /media/cdrom/casper/filesystem.squashfs /mnt/tmp
    root@bt:~# ls /mnt/tmp/etc/shadow
    ls: cannot access /mnt/tmp/etc/shadow: No such file or directory
    root@bt:~# egrep ^root /mnt/tmp/etc/passwd
    If I boot from the same iso image, then by the time I find myself at a command shell, /etc/shadow exists and has been populated with a root password hash (john the ripper tells me the hash corresponds to a zero-length string).

    My question is where does this shadow password file come from? I can't find anything in the bootstrapping scripts (gunzip -c /media/cdrom/boot/initrd.gz | cpio -id), and the startup scripts on the root filesystem don't look like they are responsible either.

    I would like to hack the shadow file on my custom live image to use a different root password. Obviously, there are plenty of downstream ways that I could do this after whatever creates it has worked it's magic, but the absense of the file in the first place got me curious and I hate not knowing how things like this work.

  2. #2
    Member whitelisted's Avatar
    Join Date
    Feb 2010

    Default Re: when/how does /etc/shadow get created on the live image?

    OK, so deciding that the lord helps those who help themselves, I picked this problem up again last night and had another crack at it.

    The shadow file is definitely not on the casper.squashfs root filesystem image when the filesystem is first mounted, and combing through the startup scripts on the filesystem yielded nothing, so I figured the answer had to be on the initramfs miniroot that init uses to bootstrap the system with before it mounts the root filesystem.

    People who are unfamiliar with the boot process but who want to follow along can access the contents of the miniroot like so:

    root@bt:~# mount -o loop /mnt/host-shared/bt4-final.iso /media/cdrom
    root@bt:~# mkdir initrd && cd initrd
    root@bt:~/initrd# gunzip -c /media/cdrom/boot/initrd.gz | cpio -id
    38459 blocks
    root@bt:~/initrd# ls
    bin/  bootsplash  conf/  etc/  init*  initrd  lib/  sbin/  scripts/  var/
    root@bt:~/initrd# umount /media/cdrom
    Note that this is just for the initramfs for the default boot off the iso image - if you are interested in the boot sequence for forensics mode or for the 800x600 framebuffer mode, then use the appropriate initrd file.

    Before I made my original post, I had previously given the image a quick (ie. lazy) scan for likely sounding keywords such as "shadow", "passwd", etc. and I hadn't had much luck.

    This time around, I tried a different tack: I booted off the live image, noted down the shadow password entry, then searched for that instead and the answer just popped right out:

    root@bt:~/initrd# find . -type f | xargs egrep -l U6aMy0wojraho
    Now that's looking much more promising.

    root@bt:~/initrd# egrep -A 7 U6aMy0wojraho ./scripts/casper-bottom/10adduser
    # U6aMy0wojraho is just a blank password
    chroot /root debconf-communicate -fnoninteractive casper > /dev/null <<EOF
    set passwd/root-password-crypted *
    set passwd/user-password-crypted U6aMy0wojraho
    set passwd/user-fullname $USERFULLNAME
    set passwd/username $USERNAME
    set passwd/user-uid 999
    chroot /root /usr/lib/user-setup/user-setup-apply > /dev/null
    OK, so that looks like the answer to my question - the script /scripts/casper-bottom/10adduser on the miniroot attempts to chroot to the root filesystem and set the root password using debconf, then it chroots again, this time so that it can run /usr/lib/user-setup/user-setup-apply, which (among other things) enables shadow passwords and sets the encrypted root password to 'U6aMy0wojraho'.

    It's a pretty easy hack to try out a new password (I used 'test1' as the new password - note the first three characters of the new password hash ), to roll it up into a new initrd.gz, to test it out with qemu, and finally to copy it overtop of the initrd.gz that I use on my custom USB live image and try it out.

    root@bt:~/initrd# sed -i s/U6aMy0wojraho/BT4AauaAzyUyU/ scripts/casper-bottom/10adduser
    root@bt:~/initrd# find . | cpio -o -H newc | gzip -c >../newinitrd.gz
    38389 blocks
    root@bt:~/initrd# mount /dev/sdc2 /mnt/usb
    root@bt:~/initrd# mv /mnt/usb/boot/initrd.gz /mnt/usb/boot/initrd.gz.old
    root@bt:~/initrd# cp ../newinitrd.gz /mnt/usb/boot/initrd.gz
    root@bt:~/initrd# cd /mnt/usb
    root@bt:/mnt/usb# find . -type f | xargs md5sum >md5sum.txt
    root@bt:/mnt/usb# cd
    root@bt:~# umount /mnt/usb
    It all works great. It's a lot of effort to go to just for the sake of a safer root password (next thing to try - MD5 password hashes instead of the old-school UNIX DES password hashes) but, meh, learning is it's own reward and I now know a hell of a lot more about Linux bootstrapping.

Similar Threads

  1. virus on VM image
    By tywelcome in forum Beginners Forum
    Replies: 3
    Last Post: 02-04-2010, 12:24 AM
  2. Errol downloading image
    By nightuser in forum Beginners Forum
    Replies: 2
    Last Post: 01-25-2010, 01:10 AM
  3. Missing wallpaper VM Image
    By MassAppeal in forum BackTrack Bugs
    Replies: 9
    Last Post: 01-18-2010, 08:50 AM
  4. ISO Image ALFA-AWUS036H
    By MassAppeal in forum BackTrack Bugs
    Replies: 2
    Last Post: 01-17-2010, 10:52 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts