Note: This web page was automatically created from a PalmOS "pedit32" memo.

Recovering root access


1) Use install/recover media that's part of your OS, like an install CD
or recovery CD

2) Use recovery media that happens to support your root filesystem, like
one of the many Linux distributions that are intended for recovery - but
only if the recovery distribution supports your root filesystem type!
FreeBSD seems to prefer UFS, so if you go this route, please be sure
your recovery distribution includes read/write UFS support!

3) There is actually another way though, using a foreign-OS
recovery CD...  If you're not put off by a program like "bpe", and
filesystem support isn't working out, and you don't mind getting a bit
hackish, then you can bpe the raw partition of the root filesystem,
search for something like "root:" to locate the password entry,
and then replace "root:aaaaaaaaaaaaa:0:0:bbbbbbbbbbbbbcccccc" with
"root::0:0:aaaaaaaaaaaaabbbbbbbbbbbbbcccccc" - the key is not to
change the number of characters in the password or shadow file entry.
This should erase the root password - or similarly for a shadow file,
if required.  Note that this likely won't work for a filesystem like
Sun's new ZFS, which checksums every disk block - then again, I gather
initially ZFS isn't going to support use as a root filesystem anyway.

4) Use some sort of security issue to break in:

4/A) One of the easier ones, is if you can boot to multiuser, and you
have an NFS export to the machine in question, and the NFS export does
not remap root to nobody or similar.  In that case, you can just drop a
setuid-root copy of bash or other shell into the NFS filesystem, and run
it as an unprivileged user to get an effective uid of 0 (you may need to
specify a -p option with some shells so the shell won't automatically drop
privilege).  This most likely won't change your real uid, so you may want
to try su'ing to root afterward, to change your real uid to root as well.

4/B) You may also be able to "break in" to root using something like a
passwordless ssh, rsh, or similar (srsh? :), if it was set up previously.

4/C) And then there's always the possibility of going to an exploit
archive, and trying some of them.

5) Some systems will allow you to boot single user without a password.
It may be worth a try, but this is getting less common as time goes by.
On linux systems, you can sometimes, instead of booting from just a kernel
named "linux", instead boot with "linux init=/bin/sh" - this will come
up to a shell before the single user stuff would've kicked in.


Note that some *ix's will require some sort of indexed password
database to be rebuilt from your /etc/passwd and/or /etc/shadow file.
Tru64 sometimes needs this, and here are some partial notes from a fellow
UCI employee, Steve Chen, about doing this on a FreeBSD system:

1) Get “disc1” ISO image from http://www.freebsd.org/where.html.
In my case, FreeBSD v5.4 for I386
2) Boot from CD and select Repair/Fixit.  Go with the “live
filesystem” route so you’d have access to the UNIX utils off of the
CD under /mnt2.
3) In my case the OS is Raid5 and the / device used is /dev/aacd0s1a

 


Back to Dan's palm memos