* UBIFS recovery/forensics tools @ 2015-09-25 9:29 Andrew Tierney 2015-09-25 10:26 ` Richard Weinberger 0 siblings, 1 reply; 6+ messages in thread From: Andrew Tierney @ 2015-09-25 9:29 UTC (permalink / raw) To: linux-mtd Hello all, I am a reverse engineer, and I am finding that UBIFS is becoming increasingly common on embedded devices. A common task is recovering file systems from locked down or damaged devices, and I'm finding this very challenging with UBIFS! I have seen talk on here of userspace tools to recover damaged UBIFS systems. Did anything every come of this? I am currently using "ubi reader" ( https://github.com/jrspruitt/ubi_reader ) with some success. Andrew ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UBIFS recovery/forensics tools 2015-09-25 9:29 UBIFS recovery/forensics tools Andrew Tierney @ 2015-09-25 10:26 ` Richard Weinberger 2015-09-27 2:27 ` Dongsheng Yang 0 siblings, 1 reply; 6+ messages in thread From: Richard Weinberger @ 2015-09-25 10:26 UTC (permalink / raw) To: Andrew Tierney; +Cc: linux-mtd@lists.infradead.org, David Gstir, yangds.fnst On Fri, Sep 25, 2015 at 11:29 AM, Andrew Tierney <cybergibbons@cybergibbons.com> wrote: > Hello all, > > I am a reverse engineer, and I am finding that UBIFS is becoming > increasingly common on embedded devices. A common task is recovering > file systems from locked down or damaged devices, and I'm finding this > very challenging with UBIFS! > > I have seen talk on here of userspace tools to recover damaged UBIFS > systems. Did anything every come of this? I am currently using "ubi > reader" ( https://github.com/jrspruitt/ubi_reader ) with some success. We're currently working on such tools. Stay tuned. -- Thanks, //richard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UBIFS recovery/forensics tools 2015-09-25 10:26 ` Richard Weinberger @ 2015-09-27 2:27 ` Dongsheng Yang 2015-09-27 8:37 ` Andrew Tierney 0 siblings, 1 reply; 6+ messages in thread From: Dongsheng Yang @ 2015-09-27 2:27 UTC (permalink / raw) To: Richard Weinberger, Andrew Tierney Cc: linux-mtd@lists.infradead.org, David Gstir On 09/25/2015 06:26 PM, Richard Weinberger wrote: > On Fri, Sep 25, 2015 at 11:29 AM, Andrew Tierney > <cybergibbons@cybergibbons.com> wrote: >> Hello all, >> >> I am a reverse engineer, and I am finding that UBIFS is becoming >> increasingly common on embedded devices. A common task is recovering >> file systems from locked down or damaged devices, and I'm finding this >> very challenging with UBIFS! >> >> I have seen talk on here of userspace tools to recover damaged UBIFS >> systems. Did anything every come of this? I am currently using "ubi >> reader" ( https://github.com/jrspruitt/ubi_reader ) with some success. > > We're currently working on such tools. > Stay tuned. Yes, there is already a RFC for ubifs_dump tool, http://lists.infradead.org/pipermail/linux-mtd/2015-August/061201.html fsck.ubifs is in developing. Andrew, do you want something like that? Yang > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UBIFS recovery/forensics tools 2015-09-27 2:27 ` Dongsheng Yang @ 2015-09-27 8:37 ` Andrew Tierney 2015-09-27 8:47 ` Richard Weinberger 0 siblings, 1 reply; 6+ messages in thread From: Andrew Tierney @ 2015-09-27 8:37 UTC (permalink / raw) To: Dongsheng Yang Cc: Richard Weinberger, linux-mtd@lists.infradead.org, David Gstir I suspect a fsck utility will work quite well for a number of these. I guess the real issue is that as soon as any piece of data deviates from the norm, current tools fall over rather than attempting to recover. ubi_reader has verbose output that allows some degree of tweaking, but it can still be awkward. The current issue I am working on is that I have one image with two volumes contained within. The first volume can be recovered fine, but the second starts walking the index, reads a common header, an ino, and then stops. I can observe significant data in the remainder of the file. There is no other location on the system for a root directory, so I suspect that the index is being misread. I don't yet know enough about UBIFS to describe the issue better. On 27 September 2015 at 03:27, Dongsheng Yang <yangds.fnst@cn.fujitsu.com> wrote: > On 09/25/2015 06:26 PM, Richard Weinberger wrote: >> >> On Fri, Sep 25, 2015 at 11:29 AM, Andrew Tierney >> <cybergibbons@cybergibbons.com> wrote: >>> >>> Hello all, >>> >>> I am a reverse engineer, and I am finding that UBIFS is becoming >>> increasingly common on embedded devices. A common task is recovering >>> file systems from locked down or damaged devices, and I'm finding this >>> very challenging with UBIFS! >>> >>> I have seen talk on here of userspace tools to recover damaged UBIFS >>> systems. Did anything every come of this? I am currently using "ubi >>> reader" ( https://github.com/jrspruitt/ubi_reader ) with some success. >> >> >> We're currently working on such tools. >> Stay tuned. > > > Yes, there is already a RFC for ubifs_dump tool, > http://lists.infradead.org/pipermail/linux-mtd/2015-August/061201.html > > fsck.ubifs is in developing. Andrew, do you want something like that? > > Yang >> >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UBIFS recovery/forensics tools 2015-09-27 8:37 ` Andrew Tierney @ 2015-09-27 8:47 ` Richard Weinberger 2015-09-27 9:50 ` Andrew Tierney 0 siblings, 1 reply; 6+ messages in thread From: Richard Weinberger @ 2015-09-27 8:47 UTC (permalink / raw) To: Andrew Tierney, Dongsheng Yang; +Cc: linux-mtd@lists.infradead.org, David Gstir Am 27.09.2015 um 10:37 schrieb Andrew Tierney: > I suspect a fsck utility will work quite well for a number of these. > > I guess the real issue is that as soon as any piece of data deviates > from the norm, current tools fall over rather than attempting to > recover. ubi_reader has verbose output that allows some degree of > tweaking, but it can still be awkward. > > The current issue I am working on is that I have one image with two > volumes contained within. The first volume can be recovered fine, but > the second starts walking the index, reads a common header, an ino, > and then stops. I can observe significant data in the remainder of the > file. There is no other location on the system for a root directory, > so I suspect that the index is being misread. I don't yet know enough > about UBIFS to describe the issue better. Can you share the image? I hope I have something sane to release soon. ...being still busy with rebasing my preliminary tool to Yang's tree and found some issues. Thanks, //richard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UBIFS recovery/forensics tools 2015-09-27 8:47 ` Richard Weinberger @ 2015-09-27 9:50 ` Andrew Tierney 0 siblings, 0 replies; 6+ messages in thread From: Andrew Tierney @ 2015-09-27 9:50 UTC (permalink / raw) To: Richard Weinberger Cc: Dongsheng Yang, linux-mtd@lists.infradead.org, David Gstir Richard, Yes - let me just see how big it is compressed and get it uploaded somewhere appropriate. Andrew On 27 September 2015 at 09:47, Richard Weinberger <richard@nod.at> wrote: > Am 27.09.2015 um 10:37 schrieb Andrew Tierney: >> I suspect a fsck utility will work quite well for a number of these. >> >> I guess the real issue is that as soon as any piece of data deviates >> from the norm, current tools fall over rather than attempting to >> recover. ubi_reader has verbose output that allows some degree of >> tweaking, but it can still be awkward. >> >> The current issue I am working on is that I have one image with two >> volumes contained within. The first volume can be recovered fine, but >> the second starts walking the index, reads a common header, an ino, >> and then stops. I can observe significant data in the remainder of the >> file. There is no other location on the system for a root directory, >> so I suspect that the index is being misread. I don't yet know enough >> about UBIFS to describe the issue better. > > Can you share the image? > > I hope I have something sane to release soon. > ...being still busy with rebasing my preliminary tool to Yang's tree > and found some issues. > > Thanks, > //richard ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-09-27 9:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-25 9:29 UBIFS recovery/forensics tools Andrew Tierney 2015-09-25 10:26 ` Richard Weinberger 2015-09-27 2:27 ` Dongsheng Yang 2015-09-27 8:37 ` Andrew Tierney 2015-09-27 8:47 ` Richard Weinberger 2015-09-27 9:50 ` Andrew Tierney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox