* 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