Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Recover partly overwritten luks volume?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Mar 30, 2015 11:33 am    Post subject: Reply with quote

I find it terribly hard to believe that no one has yet decided to help me with this.

O wish to simply be able to log into Sleuthkit forums

The deadline is probably tomorrow or the day after, after which deadline the activation would not be possible other than anew. (That how it usually is, I'm only guessing.)

I have no other means, as I'm not aadvaced enough to circumvent this censorship, and no other email that the regime really could not control could I now use.

You can see how they treat me over here:

Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-999436-highlight-.html#7682770

I can't go on without being able to log into Sleuthkit Forum. Pls. help, anybody, Gentoo Forums member or any other visitor with free email to use. Thank you in advance!
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Mar 30, 2015 1:07 pm    Post subject: Reply with quote

For me to be able to solve this properly, I'd need the little bit of instance of freedom to use Sleuthkit Forum.

To aid potential visitor who, I hope, will eventually help me, I took what happened some 5 minutes earlier than the video I already posted. I'll add this one there too, but here it is the link as well:

http://www.CroatiaFidelis.hr/gnu/zerk/Screen_150329_1925_g0n_SleuthkitForums.mkv

And more instructions I'll now post there too.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Mon Mar 30, 2015 1:11 pm    Post subject: Reply with quote

Well, good luck with that... I give up.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Mar 30, 2015 3:33 pm    Post subject: Reply with quote

frostschutz wrote:
Well, good luck with that... I give up.

Thanks, frostschutz.

I have looked through your suggestions, but the understanding, the advice, or the instructions that are missing, at this stage (when the luks volume I can open and would be able to recover the superblock of, apparently, with that exact mke2fs command given multiple times above, IIUC [*] )...

But what is missing now for me for this case to reach its (I'd hope: likely) solution, I believe, is too particular knowledge, to be found even on Gentoo Forums.

I really really need what I keeep pleading at:

https://forums.gentoo.org/viewtopic-t-1004014.html#7724054

to be able to ask some of the best world experts in these matters, for whom the answer will probably be like drink a glass of water.

The too particular knowledge to be easily found around, is how do you get which exact blocks a particular file is occupying on a device.

Why? Because I want to be able to revert to the current status defined by the MD5 sum of the device taken.

How? By dumping, with dd dump seek... , just that which some of my command will change in the next steps after this stage, so that if I go wrong, I can recover, with dd dump skip ..., exactly those blocks only, and check the MD5, and know that I am back at this exact stage at which I am right now while I am writing this.

Something is there about [how do you get which exact blocks a particular file is occupying on a device] on:

Ext4 Disk Layout
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

but I now first need to finish the explanations of what happened, and how great actually Gentoo is, if properly built and configured and used, in security on the internet, and in revealing censorship.

Gentoo/Funtoo (I keep wailing for the creator of Gentoo to come back ;-) and merge funtoo back) is great as a very secureable OS, and is good for revealing censorship. Revealing censorship is very necessary also, but only for rare, but important. kind of people, or group of people if you want, worldwide, and that is the political dissenters of which I am one, and in my own country.

Those will find my revealed censorship, useful, on top of interesting.

And important they are, because the countries are changing for the better, and bad political systems fall, because of them. I am minor in that sense, but I relish to be honest and right, and truthful in my society, even if it takes persecution against me.

I'll post more about it where it fits better, not here, but on:

Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-999436.html#7724260
(right under that, already written at the time of writing this, notice-post)
---
[*] It occurs to me, a strong suspicion, right now. what if, that command, and I'll post it 3+1st or 4+1st time now...
What it this:
Code:

uabox ~ # mke2fs -t ext4 -n -b /dev/mapper/H_E09
mke2fs: invalid block size - /dev/mapper/H_E09
uabox ~ #

that command wanted to write a new superblock, and not recover the existing one? ...
Yeah, I need your help, dear visitor:

https://forums.gentoo.org/viewtopic-t-1004014.html#7724054
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46352
Location: 56N 3W

PostPosted: Mon Mar 30, 2015 5:41 pm    Post subject: Reply with quote

miroR,

In the command
Code:
mke2fs -t ext4 -n -b /dev/mapper/H_E09
-b expects a parameter. It has only three valid values.
Even when the command runs, it won't help straight away. It will tell where the superblocts would be written relative to the start of /dev/mapper/H_E09.

To be able to see the superblocks, you first have to find the missing LUKS volume and decrypt it.
All the pointers to the missing LUKS volume have been destroyed when dd set the filesize to zero.

We know that dd reused at least one i-node from the original file. Once dd truncated the file all its blocks were marked as free and all of its i-nodes became available for reuse.
Its likely that dd reused some of this newly freed space before you stopped it.

At best you have a fragment of a LUKS volume that you need to decrypt before you can go further.
The first task is to find that fragment in the free space on the drive. Its also likely, as frostschutz has demonstrated, that what remains will be a series of fragments that you need to identify and assemble in the right order.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Tue Mar 31, 2015 7:30 am    Post subject: Reply with quote

NeddySeagoon wrote:
miroR,

In the command
Code:
mke2fs -t ext4 -n -b /dev/mapper/H_E09
-b expects a parameter. It has only three valid values.
Even when the command runs, it won't help straight away. It will tell where the superblocts would be written relative to the start of /dev/mapper/H_E09.

To be able to see the superblocks, you first have to find the missing LUKS volume and decrypt it.
All the pointers to the missing LUKS volume have been destroyed when dd set the filesize to zero.

We know that dd reused at least one i-node from the original file. Once dd truncated the file all its blocks were marked as free and all of its i-nodes became available for reuse.
Its likely that dd reused some of this newly freed space before you stopped it.

At best you have a fragment of a LUKS volume that you need to decrypt before you can go further.
The first task is to find that fragment in the free space on the drive. Its also likely, as frostschutz has demonstrated, that what remains will be a series of fragments that you need to identify and assemble in the right order.

Thanks for another piece of valuable advice.

In the hours that I was able to dedicate to the issues here, I have, however, first been preparing a presentation of what happened, in my attempts to get some simple help against censorship.

I should be back to deal with this luks volume restore issue in some (small?) number of hours.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu Apr 02, 2015 9:33 am    Post subject: Reply with quote

Finally, at least the mailing list I was able to post to:

Which blocks my very partly zeroed out, recoverable luks volume file occupies?
http://sourceforge.net/p/sleuthkit/mailman/message/33690981/
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sat Apr 18, 2015 1:51 am    Post subject: Reply with quote

2f07d3d1fc0b4a4950d782acc37b50577c89177d9520948d544cc0463050d06a dump_150418_0345_g0n.pcap
477ef99365d0629323b8b92e6c748d2410fd5e04a2b2d09889305623c67c900d Screen_150418_0345_g0n.mkv

http://www.google.com/recaptcha/api/noscript?k=6Le-IAATAAAAANwNvJTrUNx48_qBRJ72sAuctKzA

Pls. patience. A story coming.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sat Apr 18, 2015 3:42 am    Post subject: Reply with quote

I even thought I should remove the address above, in the solo post:

(this same topic, the post just above)
https://forums.gentoo.org/viewtopic-t-1004014-start-25.html#7734184

with just the hashes of the packet capture and screencast taken literally a small number of minutes, let me see, posted here 6 minutes later than they were taken. So I guess either I am a wizard or those are authentic.

And many people on Gentoo Forum know that my wizardry is excluded. I really struggle with things.

But it's innocuous that it remain. that Schmoog captcha address.

However, I wanted to give the Sleuthkit Forum address:

http://forum.sleuthkit.org/ucp.php?mode=register&sid=ce15c9ad1523bc99dccf89a05d9d0ebf

because it's still about me trying to register on their forum.

None of the addresses above may tell much at all though.

However, at this address:

http://www.CroatiaFidelis.hr/foss/cap/cap-140518_SchC/

EDIT Mon 4 May 20:02:03 CEST 2015
That address has to change. I wanted the name to reflect the YYMMDD, and with `14' I put it to last year.
EDIT END

for the knowledgeable, there's a little story to read.

A captcha picture:

http://www.CroatiaFidelis.hr/foss/cap/cap-140518_SchC/dump_150418_0345_g0n_tcp.stream_05_Schmoog.jpg

is downloadable.

But that picture is easily recoverable, not even any hex exitor needed from the packet capture. I got it out by following the tcp.stream 5.

That is, by opening the dumpcap dump_150418_0345_g0n.pcap (just download it from there), and entering in the filter box:

tcp.stream eq 5

and saving it as, really plain text is fine, such as:

dump_150418_0345_g0n_tcp.stream_05_Schmoog_jpg.txt

Then open it in vim (or any good text editors like nano), and...

And remove, in this case, the first 21 lines.

Save it as

dump_150418_0345_g0n_tcp.stream_05_Schmoog.jpg

Now, that dump_150418_0345_g0n_tcp.stream_05_Schmoog.jpg captcha, can anybody tell me for what they read in it?

Is it the string that is findable that I submit, in the dumpcap, and also in the:

Screen_150418_0345_g0n.mkv

If it is not, then I ought to quit computing.

And if it is, then please, Brian Carrier, rid us of that depending on that freaking Schmoog to register to Sleuthkit Forum!

(Brian Carrier is the maintainer of the Sleuthkit Project, for the parachuters.)

What is it?

More coming. Likely a presentation like:

http://www.CroatiaFidelis.hr/foss/cap/cap-140516_SchI/

and I don't know how soon. It's a lot of work...

Atila from Sleuthkit replied to me kindly on the mailing list:

Re: [sleuthkit-users] Which blocks my very partly zeroed out, recoverable luks volume file occupies?
http://sourceforge.net/p/sleuthkit/mailman/message/33695222/

However, like a sparrow in a cage, I can't function without the freedom to simply register, and I suspect the Schmoog (term of endearment for Google), via the obnoxious local personnel affiliated to regime currently in power in my country, just won't let me. Suspect, yes. To prove would be huge more effort.

Thanks for bearing with me.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon May 04, 2015 6:03 pm    Post subject: Reply with quote

I'm back to try and work this out. But only preparing it first, before actual attempts on the filesystem.

I'm back to try and work this out.

I just reread nearly all, and most of it I do not see unnecessary, on my way towards understanding of these issues (and maybe others' who might reach here with seeking remedy for similar trouble).

The HDD contains the perfect clone: 3TB the original, 3TB the cloned partition, by dd, to the bit.

It looks like this, as I already posted, and can confirm that I have all of it still in the exact same condition:

Code:

g5n ~ # ls -l /mnt/g1/
total 457295768
-rw-r--r-- 1 miro miro            0 2013-08-31 17:06 000_WCC072884455_THIS
-r-------- 1 root root      1052672 2014-05-06 01:03 H_E05.bak
-rw-r--r-- 1 root root           76 2014-05-06 01:04 H_E05.bak.sum
drwxr-xr-x 2 miro miro        20480 2014-05-07 16:34 H_E05_fL
-rw-r--r-- 1 miro miro        24277 2014-05-07 16:24 H_E05_fL.sum
drwxr-xr-x 2 miro miro         4096 2014-05-06 00:58 H_E05.mnt
-rw-r--r-- 1 miro miro        23512 2014-05-07 16:24 H_E05.sum
-rw-r--r-- 1 root root 465567744000 2014-09-11 23:09 H_E05.vol
-r-------- 1 root root      1052672 2014-09-11 23:11 H_E09.bak
-rw-r--r-- 1 root root           76 2014-09-11 23:11 H_E09.bak.sum
drwxr-xr-x 2 root root         4096 2014-09-11 17:26 H_E09.mnt
-rw-r--r-- 1 miro miro        35810 2014-09-11 22:37 H_E09.sum
-rw-r--r-- 1 root root   2700836864 2014-11-11 23:21 H_E09.vol
-rw-r--r-- 1 miro miro           61 2014-09-11 23:11 ls_list
g5n ~ #

Just the number by which I touch an empty file starting with 000_<that_number>_THIS is different, because I anyway don't want to give the real number of the cloned HDD, so I faked it differently.

That stage I reached in exactly the same way as I explained previously in this topic.

If you go and see the pages for today's edits:

[ this same topic]
https://forums.gentoo.org/viewtopic-t-1004014.html#7724060

and

[ this same topic]
https://forums.gentoo.org/viewtopic-t-1004014.html#7724256
(this one has today's edit in bottom)

you can see that I had lots of work figuring out the posts deleted by Frostschutz and that was so very unnecessary and unhelpful making me have to do it with his having deleted those.

But I think I'll go next, today, hopefully, with first what I reached, than use the Neddy's advice on alternative superblock, and then the Frostschutz's advice on doing a hexdump.

So, where I reached was, and what will, hopefully be next (I'm writing this prior to doing it):

Code:

uabox ~ # losetup -f
uabox ~ # losetup /dev/loop0 /mnt/g1/H_E09.vol
uabox ~ # cryptsetup --verbose --header /mnt/g1/H_E09.bak open /dev/loop0 H_E09


I here need to try and mount the damaged ext4 filesystem of the unlocked luks volume.

This first command will not work:

Code:

uabox ~ # mkdir H_E09.mnt
uabox ~ # mount -r -t ext4 /dev/mapper/H_E09 H_E09.mnt

But I saw somewhere the number to try... Some multiple of 4096 (which I'm petty certain is the block size of the filesystem in question, the 4k)...

The number I think must be `32768'... I found it in:

Code:

E2FSCK(8)                              System Manager's Manual                              E2FSCK(8)



NAME
       e2fsck - check a Linux ext2/ext3/ext4 file system

near the entry for sure, the alternate superblock:
Code:

       -b superblock
              Instead of using the normal superblock, use  an  alternative  superblock  specified  by
              superblock.   This  option  is  normally used when the primary superblock has been cor‐
              rupted.  The location of the backup superblock is dependent on the filesystem's  block‐
              size.   For  filesystems  with 1k blocksizes, a backup superblock can be found at block
              8193; for filesystems with 2k blocksizes, at block 16384; and  for  4k  blocksizes,  at
              block 32768.

              Additional  backup  superblocks can be determined by using the mke2fs program using the
              -n option to print out where the superblocks were created.   The -b option  to  mke2fs,
              which  specifies  blocksize  of  the  filesystem  must  be  specified  in order for the
              superblock locations that are printed out to be accurate.



Also the man mount gives the same number as a possibility, as Neddy suggested:
[ this same topic]
https://forums.gentoo.org/viewtopic-t-1004014.html#7650410

But what is the command to try and run? Atila from Sleutkit suggested not to use mke2fs. I know mke2fs is for making a filesystem, but it's there in the re-quoted `man e2fsck', just a few lines above, and below, again:
Code:

              Additional  backup  superblocks can be determined by using the mke2fs program using the
              -n option to print out where the superblocks were created.

But what is the right command to use for that purpose?

Why what I tried did want to right to disk instead of just give the numbers back?
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon May 04, 2015 6:53 pm    Post subject: Reply with quote

I'm still preparing, not doing actual work yet, for new attempts at recovery.

Since this:
Code:

uabox ~ # mount -r -t ext4 /dev/mapper/H_E09 H_E09.mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/H_E09,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
uabox ~ #

is what I got previously, in equivalent conditions, and then I went on trying to get the superblock numbers with, just pasting the last attempt:

Code:

uabox ~ # mke2fs -t ext4 -n -b -4096 /dev/mapper/H_E09
mke2fs 1.42.12 (29-Aug-2014)
/dev/mapper/H_E09: Operation not permitted while setting up superblock
uabox ~ #


and obviously, or maybe only apparently, it attempted to write, and surely couldn't because I mounted it ro...

(All the above are pasted that are easily found in the previous posts.)

So what now?

I'll quote from `man mount'.


Code:

MOUNT(8)                                       System Administration                                       MOUNT(8)



NAME
       mount - mount a filesystem

SYNOPSIS
       mount [-l|-h|-V]

       mount -a [-fFnrsvw] [-t fstype] [-O optlist]

       mount [-fnrsvw] [-o options] device|dir

       mount [-fnrsvw] [-t fstype] [-o options] device dir


I quoted that because I may not necessarily be sure which od the three version (just the first with the -h is sure excluded) to use.

And then I need to somehow use this option:

Code:

       sb=n   Instead of block 1, use block n as superblock.  This could be useful when  the  filesystem  has  been
              damaged.   (Earlier,  copies  of  the  superblock  would be made every 8192 blocks: in block 1, 8193,
              16385, ... (and one got thousands of copies on a big filesystem).  Since version 1.08, mke2fs  has  a
              -s (sparse superblock) option to reduce the number of backup superblocks, and since version 1.15 this
              is the default.  Note that this may mean that ext2 filesystems created by a recent mke2fs  cannot  be
              mounted r/w under Linux 2.0.*.)  The block number here uses 1 k units.  Thus, if you want to use log‐
              ical block 32768 on a filesystem with 4 k blocks, use "sb=131072".


So for mount, how do I prepare the command? I do think it's the bottom option above:

Code:

       mount [-fnrsvw] [-t fstype] [-o options] device dir



Code:

mmount -r -t ext4  -o sb=131072 /dev/mapper/H_E09 H_E09.mnt


Next I'll try and apply some of it.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon May 04, 2015 7:45 pm    Post subject: Reply with quote

So we're talking a full-disk, 3TB partition, with the listing, shortened for
the input needed next:
Code:

uabox ~ # ls -l /mnt/g1/
[...]
-r-------- 1 root root      1052672 2014-09-11 23:11 H_E09.bak
-rw-r--r-- 1 root root   2700836864 2014-11-11 23:21 H_E09.vol
[...]
uabox ~ #


And so I've prepared these to try:
Code:

uabox ~ # losetup -f
uabox ~ # losetup /dev/loop0 /mnt/g1/H_E09.vol
uabox ~ # cryptsetup --verbose --header /mnt/g1/H_E09.bak open /dev/loop0 H_E09
uabox ~ # mkdir H_E09.mnt
uabox ~ # mount -r -t ext4 /dev/mapper/H_E09 H_E09.mnt
mmount -r -t ext4  -o sb=131072 /dev/mapper/H_E09 H_E09.mnt


And the so far it went just as expected:

Code:

uabox ~ # cryptsetup --verbose --header /mnt/sdg1/H_E09.bak open /dev/loop0
H_E09
Enter passphrase for /mnt/sdg1/H_E09.vol:
Key slot 0 unlocked.
Command successful.
uabox ~ # ls -l /dev/mapper/H_E09
brw------- 1 root root 252, 9 2015-05-04 21:16 /dev/mapper/H_E09
uabox ~ #


Code:

uabox ~ # mkdir H_E09.mnt
mkdir: cannot create directory ‘H_E09.mnt’: File exists
uabox ~ #

That's fine:
Code:

uabox ~ # ls -l H_E09.mnt
total 0
uabox ~ #

Also this was...:
Code:

uabox ~ # mount -r -t ext4 /dev/mapper/H_E09 H_E09.mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/H_E09,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
uabox ~ #

...[was] also expected.

The moment of truth. Adrenaline rush... Scared...
Code:


uabox ~ # mount -r -t ext4 -o sb=131072 /dev/mapper/H_E09 H_E09.mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/H_E09,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
uabox ~ #


Nope... Failed.

What now?

Oh, wail, further into the file system. That one superblock must have been
overwritten with the dd... Double the number, triple, make it tenfold?

echo 131072*16|bc
2097152

That's 16-fold.

[/code]
uabox ~ # mount -r -t ext4 -o sb=2097152 /dev/mapper/H_E09 H_E09.mnt
mount: wrong fs type, bad option, bad superblockuabox ~ # mount -r -t ext4 -o sb=2097152 /dev/mapper/H_E09 H_E09.mnt
mount: wrong fs type, bad option, bad superblock
[...]
[/code]

I tried these numbers, all with the same error reported.

Code:

 mount -r -t ext4 -o sb=131072 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=262144 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=393216 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=524288 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=655360 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=786432 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=917504 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=1048576 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=1179648 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=1310720 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=2097152 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=33554432 /dev/mapper/H_E09 H_E09.mnt
 mount -r -t ext4 -o sb=536870912 /dev/mapper/H_E09 H_E09.mnt


And if I try:

Code:

miro@uabox ~ $ hexdump -C /mnt/sdg1/H_E09.vol
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
a0fb8000
miro@uabox ~ $


So I'm still nowhere yet.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Tue May 05, 2015 6:30 am    Post subject: Reply with quote

My next work.

Still nowhere yet, but I think I see a little more clearly, with the following.

I tried this as root (the last night's was as regular user):
Code:

uabox ~ # hexdump -C /mnt/sdg1/H_E09.vol
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
a0fb8000
uabox ~ #

Same result.

Have a look how also my poor eyesight plays here, and also equipment that is slowly dying, so shows poorly on the monitor for this box; took me a while to realize I was typing "==" instead of "="; but I'm just saying it, removing many of the extra lines of the paste:
Code:

uabox ~ # dd if==/mnt/sdg1/H_E09.vol of=/Cmn/H_E09.dd
dd: failed to open ‘=/mnt/sdg1/H_E09.vol’: No such file or directory
uabox ~ #

I'm also working under Grsecurity, so for full privs, I'll log in to Gradm account.
Code:

uabox ~ # gradm -a admin
Password:
uabox ~ #

And retrying the hexdump command. Is same of course.
Code:

uabox ~ # hexdump -C /mnt/sdg1/H_E09.vol
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
a0fb8000
uabox ~ #

While the zeroes that my famous dd dump wrote to this originally 430GB file are visible nicely, and while I have no idea what "a0fb8000" means at all, still more will be clear now. Read on.

First this is more of poor equipment and poor eyesight:
Code:

uabox ~ # dd if==/dev/mapper/H_E09 of=/Cmn/H_E09.dd
dd: failed to open ‘=/dev/mapper/H_E09’: No such file or directory
uabox ~ #

Which I finally realize:
Code:

uabox ~ # dd if=/dev/mapper/H_E09 of=/Cmn/H_E09.dd
5270976+0 records in
5270976+0 records out
2698739712 bytes (2.7 GB) copied, 45.1651 s, 59.8 MB/s
uabox ~ #

And the thing which is clear, now, is that I lost only some 0.6 % of the content of the 430G original filesystem of the luks volume, or maybe, if in that 2.7GB zero-overwhitten initial area of the disk there was also the start of a big file, than I lost that big file too, but still around 99 % of the content is still there!

Because remmber that the content of the full-disk partition of the HDD was:
Code:

uabox ~ # ls -l /mnt/g1/
total 457295768
# this is the size that H_E09.vol was originally of:
-rw-r--r-- 1 root root 465567744000 2014-09-11 23:09 H_E05.vol
[...]
-rw-r--r-- 1 root root   2700836864 2014-11-11 23:21 H_E09.vol
[...]
uabox ~ #

So these lines pretty well correspond with the same reality:

From the dd of the unlocked, zeroed-out luks volume:
Code:

2698739712 bytes (2.7 GB) copied, 45.1651 s, 59.8 MB/s

and:
Code:

-rw-r--r-- 1 root root   2700836864 2014-11-11 23:21 H_E09.vol


And surely, there were no spare superblocks to be found in the seroed-out filesystem!

I think Sleuthkit has a lot of work to do here!

---
WARNING: NOT TECHNICAL FROM HERE TO THE END OF POST.
And, again, I will need to somehow log into Sleuthkit Forums...

The other issue here, of censorship and anybody's help, anybody who is reading this, is part of the topic here, because to really work on this, having a lousy regimatic provider who reads my mail, and decides what to let through and what not to let through, and who is part of the current Croatian regime's oppressive apparatus, because the Schmoogle pronto refuse to accept my valid response to the Schmoogle captcha a few days, or a week or two ago:

[ this same topic you are reading ]
https://forums.gentoo.org/viewtopic-t-1004014-start-25.html#7734200

means somebody, having an uncensored email, like I don't have, can still help here, by, firstly, telling to people on Sleuthkit Forums to relinquish sending people to the Schmoog for registering to their forum, and that can be achieved by using something free from the captchas available:

Open Source Scripts
http://captcha.opensourcescripts.com/

And secondly, they could draw their attention that there is a stubborn Sleuthkit wannabe user here, who has documented instances (one is completely documented, see the previous to last link a few lines above, and hopefully the other will be some time in the near future)...

[That there is a stubborn Sleuthkit wannabe user here] who could use their forum with a little of their manual help, since automatically, as [the documented instances] of censorship show, can not work because of the regime in his country.

Which leads us to the old link:

[ this same topic you are reading ]
https://forums.gentoo.org/viewtopic-t-1004014.html#7724054

Anybody to finally help with this?

I will try and communicate this to them via email on the Sleuthkit ML, and see if the regime has relented and maybe let me there now... in which case this will not be necessary... But in such case you will see a clear not "SOLVED, HELP NO MORE NEEDED" in that same old post linked, and edited at least 14 times by now.

Don't know... How much energy! How much energy in vain because of the neocommunists (all the currently ruling "political elite" in my country are sons of yugoslav communists of the former regime, and their accolytes/associates) turned very fascistic, really fascistic. They do even occasinally kill people and disappear people (although not so often, probably, not yet widely)... My tribulation described in a few places in this topic is just a minor of the misdeeds of theirs that Croatia is replete with these days... Just a minor instance, but so typical.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Wed May 06, 2015 8:34 pm    Post subject: Reply with quote

I've reconstructed (to use a euphemism for manually typed) what frostschutz had posted, and which he later deleted.

I see, by the events above, that I was wrong.

See his nearly completely reconstructed textual post (there is also the screencast that I reconstructed it from):

[ this same topic ]
https://forums.gentoo.org/viewtopic-t-1004014.html#7724060

And I also started another topic:

A[n Instance of] Basic Data Recovery with SleuthKit
https://forums.gentoo.org/viewtopic-t-1016618.html
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Wed May 06, 2015 11:15 pm    Post subject: Reply with quote

I'm quoting this again, because I only now understood it (at least I hope so).
After manually typing frostshutz's text recovered from my screencasts, as I just explained in the link in the previous post.
NeddySeagoon wrote:
miroR,

In the command
Code:
mke2fs -t ext4 -n -b /dev/mapper/H_E09
-b expects a parameter. It has only three valid values.
Even when the command runs, it won't help straight away. It will tell where the superblocts would be written relative to the start of /dev/mapper/H_E09.

Right.

NeddySeagoon wrote:
To be able to see the superblocks, you first have to find the missing LUKS volume and decrypt it.
All the pointers to the missing LUKS volume have been destroyed when dd set the filesize to zero.

I finally got that.
NeddySeagoon wrote:
We know that dd reused at least one i-node from the original file. Once dd truncated the file all its blocks were marked as free and all of its i-nodes became available for reuse.
Its likely that dd reused some of this newly freed space before you stopped it.

I got that too.

NeddySeagoon wrote:
At best you have a fragment of a LUKS volume that you need to decrypt before you can go further.

Clearer than ever yet.
NeddySeagoon wrote:
The first task is to find that fragment in the free space on the drive.

In the unallocated space, as it is called in the Autopsy help and various Sleuthkit tools (blkls, blkcat, ifind, ffind... but I'd need to give those yet another read)...
It became unallocated the very moment of that freaking (or deadly as frostschutz said) dd that I issued.

BTW, his demo is just perfect. Just I have to study the commands first before I try the demo out (`man <each-one-of-those>'), I haven't ever user most of those commands yet.
NeddySeagoon wrote:
Its also likely, as frostschutz has demonstrated, that what remains will be a series of fragments that you need to identify and assemble in the right order.

It's (probably) not the case. I don't fear of that one. You know why? Because I used to (I now like to use whole partitions rather than files for luks volumes, I mean real block devices rather than files)...

Because I used to issue a
Code:

dd if=/dev/zero bs=4k count=<whatever-I-used-to> of=the-file

before any other other file whichever was written there in that whole-disk 3T parttition.

But I'll see about that.

And it's my constant headaches from very strong allergy that don't allow me to think clearly. If it is not a start of some of those old man's diseases that I even fear to name. I used to be at least ten times faster than this to grasp things... Sad.

Now my problem is to figure out the Autopsy help, I mean with to get a clear understanding, it's still somewhat vague for me, after quite a few reads. And the Sleuthkit commands that Autopsy uses, like in the other post that I started for another issue of deleted files:

A Basic Data Recovery with SleuthKit
https://forums.gentoo.org/viewtopic-t-1016618.html
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu May 07, 2015 1:02 am    Post subject: Reply with quote

Just sent to Sleuthkit Mailing List.
Code:

54b3470fb213d0d5b21fd0aefac202f0b469b8395c2f353e789230aa7da6092c  dump_150507_0257_g0n.pcap
250b0c875eb4122db2756879e9e27c09fd5595ac0d5f14a1f14d9e40e8024175  Screen_150507_0257_g0n.mkv

---
Just one linefeed after "---", and surely, only this forum members, because you need to quote it to get the code, not what the HTML shows, and you need to remove the quote at the beginning, and than this sig can verify the text above:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABCgAGBQJVSroxAAoJEOqYhIhPuvCurn4QAIivVcHncirtiJvWrB31ovhR
FERud7EX9m6MtS8FKhtJThFNJqGL5AyOxRgo+hhXNqKwqTsheCgodbAroZvzSIlN
jS3UO8TbPK654VW+AXqeigMPq2OgSJZWVHHlEa1ZD8qYdXFK5nVWWjgO/xdOx4bS
lbeOZvVJCw491ecTDPnxJ6/qj53oOtpM37TlgAwmrnksgRZMm/r4iTAt+HY2BAj1
bZ/8lqkeQi8R+eyoyxiB2HdLYkdE0wbtmoBUvOUCuJJJvrEPEdeSrRkQHO3KBldm
YJvXqwrpn59JMlgTU4UeWHWapiQsKivqAYcvVD4qCpixodg78b1HK+sORfU4MNQz
oPZanUHNynSX8CEg7x/k3dxz5tmCj+1vZa1gO2+Un0KuQTv1RpsVWXPvkP3+TfY3
91eJL2Tlq/KuHEeGzs2uq7FSDBTesxzB2YoTW5a4T/h8ck6mygMeNel4xHSp6bOc
nzPawaYkp9UYNO4UKvBj11V+AmuArqgXGNofPBgMHkaHQVqszaqX8hqxcnUzg3C4
suogbYGniJnVUlycmJZKD5zQ6FeAUxZA3k3bfsM2bir7ucu2Yzi0jqHYWiMNX4+t
bmKYK2IRSfpdK0gN28gHrp6UEiewUdEQtwfk633SXNGG5z4eLucpSGLZk03MIa94
QoPsLjJPC5AIgTvXTHI1
=BYno
-----END PGP SIGNATURE-----


Last edited by miroR on Thu May 07, 2015 5:14 am; edited 1 time in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu May 07, 2015 1:13 am    Post subject: Reply with quote

It arrived at Sleuthkit Mailing List:

Which blocks my very partly zeroed out, recoverable luks volume file occupies?
http://sourceforge.net/p/sleuthkit/mailman/message/34090581/

I did not get any e-mail (it's my message; that could be the ML policy, not to send to the author).
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Thu May 07, 2015 3:11 pm    Post subject: Reply with quote

whatever
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu May 07, 2015 3:51 pm    Post subject: Reply with quote

WARNING: non-technical paragraphs. You are free to ignore this post! Everybody is asked to, please, read at your own responsability!!
I'm still sure not all people are unforgiving cinics. And if you are such, take care, nothing is certain in life, and what you have is not necessarily given, and in the first place, really basically does not depend only on you...
What you have is certainly not guarrantied, and you should be proud and thankful for having what you have, esp if you see others struggling and not having what you have without much ado...

(What you have at the very least does not depend only on you, and you always change, everybody change. Nothing, nothing, but the Highest and the Eternal in the Worlds of Intelligence and Wisdom and in the Secrets, previously unknown, revealed to the minds which Light of Intelligence made capable to understand...

Nothing, nothing, but the Highest and the Eternal and Principles that stand and are never shaken, nor can they be by the passing and the fleeting that can only glance at them...

Nothing, nothing else is given.)

And everybody gets what they deserve, for good or for bad, sooner or later.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri May 08, 2015 9:58 am    Post subject: Reply with quote

I first studied the commands that I've never used before yet, really completely new were only `man truncate', `man filefrag', and, which I will yet study before the next post, where I will continue, as this post is up to that possibly most important point in frostschutz' demo, the `man strings'.

And I reproduced the most important tip in this topic which took me all these ages to understand.

So I'll try and post that my attempt here and if manage, expand and move on from there.

I'll also keep to the original frostschutz' wording. Except these are real pastes from my `uabox' system, in homedir `ukra'. Few differences, e.g. `mke2fs.ext4' I don't have, but `mke2fs -ext4' I use instead.

Also I've strewn what I did with a few extra:
Code:

uabox loop # ls -l

which also tell a little more.

And except that the notice that it is mostly frostschutz's wording is given hereby and not by means of the quoting.

I created and loop-mounted a 2G ext4 filesystem:

Code:

uabox ukra # truncate -s 2G filesystem
uabox ukra # shred -z filesystem
uabox ukra # mke2fs -t ext4 filesystem
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done                           
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: 5c9576eb-aadd-4dac-bcf4-f82deb2a3722
Superblock backups stored on blocks:
   32768, 98304, 163840, 229376, 294912

Allocating group tables: done                           
Writing inode tables: done                           
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

uabox ukra # mkdir loop
uabox ukra # mount -o loop filesystem loop
uabox ukra # cd loop
uabox loop # ls -l
total 16
drwx------ 2 root root 16384 2015-05-08 10:31 lost+found
uabox loop # df -h
Filesystem                Size  Used Avail Use% Mounted on
[...]
/dev/loop2                2.0G  3.0M  1.8G   1% /home/ukra/loop
uabox loop #


In this filesystem I created a 1GB LUKS container:

Code:

uabox loop # truncate -s 1G container
uabox loop # ls -l
total 16
-rw-r--r-- 1 root root 1073741824 2015-05-08 10:39 container
drwx------ 2 root root      16384 2015-05-08 10:31 lost+found
uabox loop # shred -z container
uabox loop # ls -l
total 1048596
-rw-r--r-- 1 root root 1073741824 2015-05-08 10:40 container
drwx------ 2 root root      16384 2015-05-08 10:31 lost+found
uabox loop # cryptsetup luksFormat container

WARNING!
========
This will overwrite data on container irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
uabox loop #

Note: the `foobar' password didn't echo above, but I did enter `foobar' the two times, to keep to the original demo.
Code:

uabox loop # cryptsetup luksHeaderBackup container --header-backup-file container.luks
uabox loop #


This is to replicate your situation - a LUKS container stored as a file in a filesystem.

Code:

uabox loop # ls -l
total 1049624
-rw-r--r-- 1 root root 1073741824 2015-05-08 10:41 container
-r-------- 1 root root    1052672 2015-05-08 10:42 container.luks
drwx------ 2 root root      16384 2015-05-08 10:31 lost+found
uabox loop #


Here's what that file's allocation data looks like:

Code:

uabox loop # filefrag -s -v container
Filesystem type is: ef53
File size of container is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:           
   1:    32768..   63487:      67584..     98303:  30720:           
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:           
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:           
   6:   190464..  221183:     231424..    262143:  30720:     229376:
   7:   221184..  237567:     278528..    294911:  16384:     262144:
   8:   237568..  262143:     296960..    321535:  24576:     294912: last,eof
container: 6 extents found
uabox loop #


Now comes the deadly dd. Since the container is only 1G, I will "overwrite" 128MB. So it's partially overwritten as in your case, as I understood it.

Code:

uabox loop # dd if=/dev/zero of=container bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 0.43381 s, 309 MB/s
uabox loop #
uabox loop # ls -l
total 132116
-rw-r--r-- 1 root root 134217728 2015-05-08 10:45 container
-r-------- 1 root root   1052672 2015-05-08 10:42 container.luks
drwx------ 2 root root     16384 2015-05-08 10:31 lost+found
uabox loop #


Here's what the results allocation data looks like:

Code:

uabox loop # filefrag -s -v container
Filesystem type is: ef53
File size of container is 134217728 (32768 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:     321536..    354303:  32768:             last,eof
container: 1 extent found
uabox loop #


As you can see, it ended up in a different physical location compared to the original container.

The offset of the file produced by dd is 321536-354303. The original offset of the first fragment was 34816-67583.

Conclusion: The file was not overwritten at all, but deleted, and a new file created in its place in a different location. The different location is a matter of luck. The filesystem just picks whatever location is free.

If you wanted dd to overwrite in-place, you'd need the conv=notrunc option.

In the raw data of that filesystem, the original LUKS header can still be found. But what you actually must find in order to be able to restore anything (but the first fragment, if it still exists), is all of the posted earlier:

Code:

uabox loop # filefrag -s -v container
Filesystem type is: ef53
File size of container is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:           
   1:    32768..   63487:      67584..     98303:  30720:           
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:           
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:           
   6:   190464..  221183:     231424..    262143:  30720:     229376:
   7:   221184..  237567:     278528..    294911:  16384:     262144:
   8:   237568..  262143:     296960..    321535:  24576:     294912: last,eof
container: 6 extents found
uabox loop #


I[t] was just a 1G file but already there are many pieces to the puzzle[. F]or each piece you must know the exact physical offset and length. Without this information the container is just dead and gone.

Hence my suggestion: see if you can find the first piece. The one with the LUKS header, and with any luck if the piece was large enough, with your filesystem metadata. If you have this piece you might have a remote chance at finding some specific other piece. Finding random pieces in general, on the other hand, in nigh impossible.
-----------
To find pissible LUKS headers on a device: ... On that I will continue in the next post.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri May 08, 2015 11:09 am    Post subject: Reply with quote

Continuing from the previous post. Here correcting a minor frostschutz' lapsus mentis along with thinking how to apply his advice from this demo of his.

The lapsus consists in, as you can see in the screencast that I made with my my (primitive) program uncenz which I always use when I go online, censored as I too often am, [consists in] typing in the command of `foobar' instead of `filesystem'. `foobar' is the passphrase used at the time of creation of the luks volume of the demo, and filesystem is the actual file for the demo in which the ext4 filesystem was made for this really kind demonstration, for which I am thankful, if I am still allowed to be.

To find pissible LUKS headers on a device:

Code:

strings -t d -n 4 /dev/DEVICE | grep -A 3 LUKS


In my case the result is:

Code:

cd ../
uabox ukra # ls -l filesystem
-rw-r--r-- 1 ukra ukra 2147483648 2015-05-08 12:49 filesystem
uabox ukra # strings -t d -n 4 filesystem | grep -A 3 LUKS
134746112 LUKS
134746152 xts-plain64
134746184 sha1
134746227 'F)
--
142606336 LUKS
142606376 xts-plain64
142606408 sha1
142606451 'F)
uabox ukra #


34816 (the first fragment shown by filefrag above) * 4096 (sector size) = 142606336 so the second hit is the first place we were looking for. And the first hit happens to be the LUKS header backup I created.
---
And now, to apply this in my case, I don't know if I can without closing one of two other Sleuthkit cases opened, because, as I mentioned over here:

Use GPLv2+ for a program to release, is best?
https://forums.gentoo.org/viewtopic-t-1016338.html#7742440
( the mention is at bottom )

I had, in the meantime, made another stupid deletion elsewhere (it really could be what I fear and won't repeat, but careful reader will have noticed it in some cca three to five posts previous to this one, it really could be that)...

Not to mention that the typing, the manual typing of the original demo (that I euphemized with "RECONSTRUCTION") from my screencast I had to do twice, because, after having finished typing it from the screencast, I issued an `cat > THAT-TEXT instead of cat THAT-TEXT, can you imagine?

And likewise, I deleted those other files, and that one Sleuthkit case, described here:

A Basic Data Recovery with SleuthKit
https://forums.gentoo.org/viewtopic-t-1016618.html

and also another one not described anywhere yet, but will probably be also described in that "...Basic..." topic, is under way.

And so currently everything else that I was supposed to be working, but these data recovery, is on hold... and also those other two sleuthkit cases and not this one, are underway...
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Aug 24, 2015 2:14 pm    Post subject: Why, oh why the Schmoog Captcha? Reply with quote

I have another post where the issue with the corporate captcha has nothing but trouble for me again. I misposted it here, but moved the complete post over to:

Why, oh why the Schmoog captcha?
https://forums.gentoo.org/viewtopic-t-1027382.html

(
As far as the recoveries in this and the topics linked from this one, I intend to give another week or two for them. When, I still don't know.

But at least I have where to continue from. I'm not a newbie to recovery any more...
)

Cheers.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum