UBIFS recovery/forensics tools
Andrew Tierney
cybergibbons at cybergibbons.com
Sun Sep 27 01:37:54 PDT 2015
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 at 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 at 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
>>
>>
>
More information about the linux-mtd
mailing list