xfs
[Top] [All Lists]

Re: Using xfsdump On Linux With IRIX Version 1 FS?

To: Sean Elble <elbles@xxxxxxxxxx>
Subject: Re: Using xfsdump On Linux With IRIX Version 1 FS?
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Fri, 24 Jul 2009 19:11:51 +0200
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <C68F4D3F.B931%elbles@xxxxxxxxxx>
References: <20090724073030.GA15785@xxxxxxx> <C68F4D3F.B931%elbles@xxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
On 24.07.2009 11:36, Sean Elble wrote:
> On 7/24/09 3:30 AM, "Matthias Schniedermeyer" <ms@xxxxxxx> wrote:
> 
> >> 
> >> Looks like the version 1 directory code was removed as of June 15th, 2006,
> >> per this:
> >> 
> >> http://oss.sgi.com/archives/xfs/2006-06/msg00067.html
> >> 
> >> But another post <http://oss.sgi.com/archives/xfs/2003-07/msg00495.html> 
> >> has
> >> a 2.4.21 kernel being used with a patch, so I'm not sure if I want to try a
> >> 2.6 kernel, or see if I can patch together a 2.4.x kernel on an old FC4 box
> >> I have laying around.  Truth be told, it's a lot of work just to blank the
> >> entries in /etc/shadow so I can login to a 150 MHz box again, so who knows
> >> if I'll even try at this point, hah.
> >> 
> >> In any event, thanks a lot for the pointers in the right direction.
> > 
> > I'd guess the disc isn't very big.
> > 
> > You just dd it completly (for backup).
> > 
> > Then search for the content of the shadow-file and blank out the entry
> > with a hex-editor. Make sure that you don't change the filesize, pad
> > the previous/following entry with any character you have to remove.
> 
> Right, the disk is only 2 GB.  Presumably, to back the disk up, all I'd have
> to do would be something like:
> 
>     dd if=/dev/sda of=IRIXbackup
> 
> Correct?  No need to specify bs or count, I presume...

Exactly.

> Then, I could use hexedit in the following manner to edit the disk:
> 
>     hexedit -d -f /dev/sda

Don't know hexedit. Last time i used a hex editor it was "khexedit", 
worked good enough.

> I suppose I could search for the encrypted password string itself, but as
> Chris Wedgwood suggested, I might be better off finding the offset of the
> /etc/shadow file by doing something like the following:
>     
>     xfs_ncheck /dev/sda | grep /etc/shadow
> 
> I'm not sure if I can use the inode number directly as an offset or not, but
> I *think* I could use it in conjunction with a xfs_db convert command to get
> something usable as an offset.  Something like the following, perhaps?
> 
>     xfs_db -c convert inode <inode from xfs_ncheck command> daddr /dev/sda

2GB is small enough to just use "brute force".

- Make a backup-copy of the image
- Open the image in a/the hexeditor
- Search for something that appears in the shadow file
  it should be pretty obvious if the hit is inside the shadow file.
- Make the changes, (Remember filesize has to stay the same!) 
- dd the image back to the HDD.

Not very complicated and it still shouldn't take too long. :-)



Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

<Prev in Thread] Current Thread [Next in Thread>