LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 10-22-2018, 01:39 PM   #31
Kallys
LQ Newbie
 
Registered: Jul 2018
Posts: 14

Original Poster
Rep: Reputation: Disabled

Here is (partial) result:
Code:
# tune2fs -l /dev/sda4
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         unsigned_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30355200
Block count:              30453104
Reserved block count:     0
Free blocks:              16335303
Free inodes:              30351218
First block:              0
Block size:               65536
Fragment size:            65536
Reserved GDT blocks:      32
Blocks per group:         65528
Fragments per group:      65528
Inodes per group:         65280
Inode blocks per group:   255
Flex block group size:    16
Mount count:              73
Maximum mount count:      35
Lifetime writes:          1102 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Journal backup:           inode blocks
Thanks for your help!
 
Old 10-22-2018, 11:17 PM   #32
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,046

Rep: Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798
I fear this is going to be ridiculously complex. Even if your file is "contiguous", it is still going to spread over many of the ~465 block groups in that filesystem. The Overview section of the Ext4 Disk Layout shows what you are up against. The nonstandard block size and possibility of Flexible Block Groups means I can't calculate where those group descriptors might be located or what their size might be. It is all information that I'm sure can be dug out from the super block. I see that the filesystem features do include "flex_bg" and "sparse_super", so it is apparent that this is the most complex case. It's still not something I could calculate without spending a huge amount of time with a hex editor examining those ext4 metadata structures.

Here's a thought. If you have another disk at least as large as that sda4 partition, you could put it in the NAS, create a partition of that size, and create an ext4 filesystem there with the same features as the current filesystem. You could then proceed to fill that filesystem with a file having blocks containing a recognizable mark and a block number. That would allow a program to build a map of where the user data blocks are. Due to possible inode indirect blocks it won't be a 100% match to the blocks available to your LUKS file, but it should be a place to get started. If you can once figure out just where the blocks of your "contiguous" file actually were, it's then a fairly simple matter to create dmsetup mapping that would extract your file.

I know I'm grasping at some very long, thin straws here, but I'm at a loss for other ways to proceed. I don't think that photorec is going to be very useful at rebuilding a huge file of apparently random data.

Suggestions, anyone??
 
Old 10-23-2018, 08:18 AM   #33
Kallys
LQ Newbie
 
Registered: Jul 2018
Posts: 14

Original Poster
Rep: Reputation: Disabled
If it can help, I do have an earlier backup of the encrypted content. The probably only thing I'll loose if I can't rescue data from this drive (as far I can remember) is another LUKS file, encapsulated in the first LUKS file.

I'm pretty sure almost data is still there: fsck should have deleted inodes but not content, right?

Since encrypted file size is not stored in LUKS header and encryption is only based on block position on disk, is there not a way to decrypt a whole raw device, and then try to rebuild deleted inodes based on raw content or rescue files by reading apparently free space?

What I tried is to dd from LUKS header to end of disk, then decrypt that file, and then, on the decrypted mapped device I tried to:
1) photorec it: aborted since it estimated a month just to read inodes...
2) mount it: failure
3) e2fsck it: deleted almost everything and then resulting filesystem is still unmountable
I know that this method assumed original luks_file is contiguous, which is certainly not true; but since I have no more idea, I had to try.

Thanks!

Last edited by Kallys; 10-23-2018 at 08:19 AM. Reason: typo
 
Old 10-23-2018, 09:28 AM   #34
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,046

Rep: Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798Reputation: 1798
Quote:
Originally Posted by Kallys View Post
Since encrypted file size is not stored in LUKS header and encryption is only based on block position on disk, is there not a way to decrypt a whole raw device, and then try to rebuild deleted inodes based on raw content or rescue files by reading apparently free space?
The problem is that what matters is not the block position on the disk but the block offset in the LUKS container. When that container is a raw disk or a partition, then it's easy to determine where any given offset apears on the underlying media. An LVM logical volume would be somewhat harder, but still doable. But, your container is a file in an ext4 filesystem. You have found where that file begins on the disk, so some number of blocks immediately follow. However, at some point, call it block N, you run into a group descriptor in that outer filesystem, and then your file's blocks resume with block N+1 after that group descriptor. You don't know where that group descriptor begins or what its size is. You can go searching/calculating, but you will have to do that 400+ times to find all of your file's segments. That's just not practical unless your data is extremely valuable (e.g., your PhD thesis, or perhaps a large Bitcoin wallet).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: How to make remote incremental backup of LUKS-encrypted disk/partition LXer Syndicated Linux News 0 02-16-2015 01:50 PM
How to recover deleted file from LUKS encrypted hard disk kumariarjun@gmail.com Linux - Newbie 1 06-20-2013 02:47 AM
Is my hard disk dying? Nylex Linux - Hardware 6 07-16-2006 03:31 PM
Hard drive dying, good backup method cadj Linux - Software 3 12-14-2004 08:28 PM
Dying disk???? Mux Linux - Hardware 2 10-22-2002 07:27 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 01:56 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration