@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

NTFS last access time and 1 hour (3)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

I continue to test last access time on the Win 10 1803 environment. (I repeat the same thing like a monkey. :-)
I am hoping to end this test today.

Please note that it is not a sufficient verification method.

DisableLastAccess = 2 (System Managed, Disabled) ⇒ Last Access Time updates are enabled.
The test volume F: is NTFS and the size is 149 GB.

Display properties of Dragonfly.jpg in Explorer.

f:id:hideakii:20181212180117p:plain

Check the latest time stamp with the fsutil command.

f:id:hideakii:20181212180214p:plain

Check the time stamp recorded on the disk.

It is different from the result of fasutil. I was able to confirm that the old time stamp was saved. This value is the same as the timestamp of the property.

f:id:hideakii:20181212180344p:plain

Wait one hour.

Check the latest time stamp with the fsutil command. The timestamp has not changed.

f:id:hideakii:20181212185438p:plain

The time stamp on the disk also does not change.

f:id:hideakii:20181212185450p:plain

Display the properties of the file and update the timestamp.

f:id:hideakii:20181212185629p:plain

Check the latest time stamp with the fsutil command.

f:id:hideakii:20181212185640p:plain

Check the time stamp of the disk. The latest timestamp was recorded.

f:id:hideakii:20181212185700p:plain

Perhaps, this is what I wanted to test.
In the future, I would like to consider a better verification method.


The resolution of NTFS last access time is described as 1 hour.

File Times - Windows applications | Microsoft Docs

The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

 

Verification environment: Windows 10 1083

Reference URL:

File Times - Windows applications | Microsoft Docs

 

f:id:hideakii:20181212175819j:plain

 

NTFS last access time and 1 hour (2)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

I continue to test last access time on the Win 10 1803 environment.

Please note that it is not a sufficient verification method.

DisableLastAccess = 2 (System Managed, Disabled) ⇒ Last Access Time updates are enabled.
The test volume F: is NTFS and the size is 149 GB.

Check the latest time stamp with the fsutil command.

f:id:hideakii:20181211194703p:plain

Display properties of Dragonfly.jpg in Explorer. Last Access Time has been updated by this operation.(Close the property and close Explorer.)

Check the latest time stamp with the fsutil command.

f:id:hideakii:20181211195748p:plain

Refer to Physicaldrive 2 and check the time stamp. An old timestamp on the disk was displayed.

f:id:hideakii:20181211195836p:plain

Add Local Drive F: and check the time stamp. Interestingly, adding Local Drive F: will update the latest timestamp. (This also happens with Autopsy.)

f:id:hideakii:20181211200132p:plain

When accessing the logical drive, flash the latest information to the disk?

I recommend you to check with PHYSICALDRIVE in the Last Access Time test.
Because I was referring to F: in the test, I lost a lot of time.

 

Verification environment: Windows 10 1083

Reference URL:

 

 

f:id:hideakii:20181211184548j:plain

 

NTFS last access time and 1 hour

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

The resolution of NTFS last access time is described as 1 hour.

File Times - Windows applications | Microsoft Docs

The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

Confirm Last Access Time update on Win 10 ver 1803. (DisableLastAccess = 2 (System Managed, Disabled))

Please note that it is not a sufficient verification method.

Check the time stamp of the sample image file with the fsutil command.
2018/12/09 11:27:05 UTC

f:id:hideakii:20181210185658p:plain

Display properties in Windows Explorer. You can check the same timestamp as fsutil command. (The time zone of the verification environment is set to UTC.)

f:id:hideakii:20181210185750p:plain

 

Again, display the time stamp with the fsutil command.

f:id:hideakii:20181210194723p:plain

Display properties in Windows Explorer.

Oh? , Explorer displays a different Last Access Time than the FILE record.

f:id:hideakii:20181210194841p:plain

I closed Windows Explorer and confirmed it again, but it was the same timestamp. 2018/12/10 10:01:46 UTC

Why does Explorer display old time stamp(Last Access Time)?

 

I tested it again. Check the timestamp in the property.

f:id:hideakii:20181210201441p:plain

Check the time stamp with the fsutil command. 

f:id:hideakii:20181210201520p:plain

Double check, I confirmed timestamp with FTK Imager

f:id:hideakii:20181210201858p:plain

I confirmed the timestamp of $I30. I confirmed the same time stamp as FTK Imager.

2018/12/10 11:11:56.6756334 UTC

f:id:hideakii:20181210202236p:plain

???,

Is the fsutil command displaying the latest information and it is different from the value on the disk?

When I checked the property again, I noticed that the time stamp was updated.

f:id:hideakii:20181210203217p:plain

The Last Access Time has also been updated in the display of FTK Imager.

f:id:hideakii:20181210203428p:plain

It is unknown which access the Last Access Time was updated.
I need to do further verification.

 

Last Access Time Verification of resolution is a bit difficult. ;-)

 

<2018/12/11 add>
Thank you for your comment.

 

 

Verification environment: Windows 10 1083

Reference URL:

 

f:id:hideakii:20181210184955j:plain

 

DisableLastAccess and 2 (System Managed, Disabled)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

I confirmed DisableLastAccess in verification environment. The size of C: is 40 GB.
The value of DisableLastAccess was "2" and "Disabled"...."Disabled"???

f:id:hideakii:20181209152548p:plain

f:id:hideakii:20181209152700p:plain

I confirmed the settable value with disablelastaccess.

f:id:hideakii:20181209153318p:plain

f:id:hideakii:20181209155011p:plain

I saw Forensic Lunch Test Kitchen 12/6/18 and understood the meaning of "Disabled"!
Thank you!

www.hecfblog.com

 

Check the timestamp of Accessed in the property of the sample image file.

f:id:hideakii:20181209185121p:plain

Again, display the properties. (File is not opened)

Accessed has been updated.

f:id:hideakii:20181209185258p:plain

Connect the USB memory(58.5GB) and repeat the same procedure.

f:id:hideakii:20181209190230p:plain

f:id:hideakii:20181209190045p:plain

Again, display the properties. (File is not opened)

Accessed has been updated.

f:id:hideakii:20181209190143p:plain

I added a 150 GB volume to the test environment.

f:id:hideakii:20181209190811p:plain

Check the time stamp of the sample image file.

>fsutil file layout Dragonfly.jpg
Last Access Time : 12/9/2018 10:09:20 (UTC)

f:id:hideakii:20181209202313p:plain

Display the properties. (File is not opened)

Again, Check the time stamp of the sample image file.
Last Access Time has been updated.

f:id:hideakii:20181209203752p:plain

Muuu??
Time stamp resolution is not 1 hour?

f:id:hideakii:20181209204531p:plain

I need to continue testing.


Verification environment: Windows 10 1083

Reference URL:

dfir.ru

File Times - Windows applications | Microsoft Docs

f:id:hideakii:20181209205334j:plain





Deleted Registry KEY and Timestamp

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

Delete the registry key and check the time stamp.
Create sample registry keys and values under SYSTEM.

f:id:hideakii:20181209143420p:plain

Last write timestamp:2018-12-09 05:33:00(UTC)

f:id:hideakii:20181209144258p:plain

Delete the registry key and check the time stamp. The timestamp has not changed.
Last write timestamp:2018-12-09 05:33:00(UTC)

f:id:hideakii:20181209145137p:plain

Next, we create a key with several subkeys.

f:id:hideakii:20181209145527p:plain

f:id:hideakii:20181209145915p:plain

EVIDENCE002: Last write timestamp:2018-12-09 05:54:22(UTC)
EVIDENCE003: Last write timestamp:2018-12-09 05:54:31(UTC)
EVIDENCE004: Last write timestamp:2018-12-09 05:54:49(UTC)

Delete the parent's EVIDENCE002 key and check the time stamp.

f:id:hideakii:20181209150412p:plain

EVIDENCE002: Last write timestamp:2018-12-09 06:01:00(UTC)
EVIDENCE003: Last write timestamp:2018-12-09 06:01:00(UTC)
EVIDENCE004: Last write timestamp:2018-12-09 05:54:49(UTC)

 

The timestamp of EVIDENCE 002 and 003 has been updated.
What changed?, Compare Technical details.

 

EVIDENCE003(Before deleting)

Size: 0x60
Relative Offset: 0x327848
Absolute Offset: 0x328848
Signature: nk
Flags: CompressedName

Name: EVIDENCE003

Last Write Timestamp: 12/9/2018 5:54:31 AM +00:00

Is Free: False

Debug: 0x0

Maximum Class Length: 0x0
Class Cell Index: 0x0
Class Length: 0x0

Maximum Value Data Length: 0x0
Maximum Value Name Length: 0x0

Name Length: 0xB
Maximum Name Length: 0x16

Parent Cell Index: 0x327970
Security Cell Index: 0x64B3D0

Subkey Counts Stable: 0x1
Subkey Lists Stable Cell Index: 0xA489A8

Subkey Counts Volatile: 0x0

User Flags: 0x00000000
Virtual Control Flags: 0x00000000
Work Var: 0x0

Value Count: 0x0
Value List Cell Index: 0x0

Padding: 00-63-14-FE-E9


Security key
Size: 0x108
Relative Offset: 0x64B3D0
Absolute Offset: 0x64C3D0
Signature: sk
Is Free: False

Forward Link: 0x138C70
Backward Link: 0x64B8F0

Reference Count: 7

Security descriptor length: 0xF0

Security descriptor: Revision: 0x1
Control: SeDaclPresent, SeDaclAutoInherited, SeSaclAutoInherited, SeSelfRelative

Owner offset: 0xC4
Owner SID: S-1-5-32-544
Owner SID Type: BuiltinAdministrators

Group offset: 0xD4
Group SID: S-1-5-21-3032502310-280463001-373959476-513
Group SID Type: DomainUsers

Dacl Offset: 0x14
DACL: ACL Revision: 0x2
ACL Size: 0xB0
ACL Type: Discretionary
Sbz1: 0x0
Sbz2: 0x0
ACE Records Count: 6

------------ Ace record #0 ------------
ACE Size: 0x18
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: QueryValue, EnumerateSubkeys, Notify, ReadControl
SID: S-1-5-32-545
SID Type: BuiltinUsers
SID Type Description: S-1-5-32-545: A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer.

------------ Ace record #1 ------------
ACE Size: 0x18
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: FullControl
SID: S-1-5-32-544
SID Type: BuiltinAdministrators
SID Type Description: S-1-5-32-544: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Administrators group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Administrators group also is added to the Administrators group.

------------ Ace record #2 ------------
ACE Size: 0x14
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: FullControl
SID: S-1-5-18
SID Type: LocalSystem
SID Type Description: S-1-5-18: An account that is used by the operating system.

------------ Ace record #3 ------------
ACE Size: 0x14
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritOnlyAce, InheritedAce
Mask: FullControl
SID: S-1-3-0
SID Type: CreatorOwner
SID Type Description: S-1-3-0: A placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the object's creator.

------------ Ace record #4 ------------
ACE Size: 0x18
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: QueryValue, EnumerateSubkeys, Notify, ReadControl
SID: S-1-15-2-1
SID Type: AllAppPackages
SID Type Description: S-1-15-2-1: All applications running in an app package context.

------------ Ace record #5 ------------
ACE Size: 0x38
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: QueryValue, EnumerateSubkeys, Notify, ReadControl
SID: S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681
SID Type: UnknownOrUserSid
SID Type Description: SID does not map to a common SID or this is a user SID

  

Subkeys

Key name: EVIDENCE004, Value count: 1, Subkey count: 0
Key name: New Key #1, Value count: 0, Subkey count: 0

 EVIDENCE003(Deleted)

Size: 0xB0
Relative Offset: 0x327848
Absolute Offset: 0x328848
Signature: nk
Flags: CompressedName

Name: EVIDENCE003

Last Write Timestamp: 12/9/2018 6:01:00 AM +00:00

Is Free: True

Debug: 0x0

Maximum Class Length: 0x0
Class Cell Index: 0x0
Class Length: 0x0

Maximum Value Data Length: 0x0
Maximum Value Name Length: 0x0

Name Length: 0xB
Maximum Name Length: 0x0

Parent Cell Index: 0x327970
Security Cell Index: 0xFFFFFFFF

Subkey Counts Stable: 0x0
Subkey Lists Stable Cell Index: 0x0

Subkey Counts Volatile: 0x0

User Flags: 0x00000000
Virtual Control Flags: 0x00000000
Work Var: 0x0

Value Count: 0x0
Value List Cell Index: 0x0


Subkeys

Key name: New Key #1, Value count: 0, Subkey count: 0
Key name: EVIDENCE004, Value count: 1, Subkey count: 0

  

Verification environment: Windows 10 1083

Reference URL:

 

f:id:hideakii:20181209142935j:plain

 

USB and Amcache(2)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

This is the continuation of the Amcache test.

 

I connected a USB memory and created an LNK file.
Each LNK file targets the CLI and the GUI program that exist on the USB memory.

f:id:hideakii:20181203072350p:plain

f:id:hideakii:20181203072709p:plain

f:id:hideakii:20181203073243p:plain

Run each LNK file and check the timestamp in the Sysmon event log.

f:id:hideakii:20181203073012p:plain

f:id:hideakii:20181203073403p:plain

I will wait until it is reflected in Amcahce. (The USB memory is still connected.)

Confirm the parse result.

There was no entry for F: drive in "20181203071331_Amcache_ShortCuts.csv".

 

Result of 20181203071313_Amcache_UnassociatedFileEntries.csv.

???, There is a record of the CLI program, Autorunsc.exe. (I want to test what happens when PowerShell etc. are embedded in LNK file.)

f:id:hideakii:20181203074130p:plain

And the record of the program deleted from F: drive has disappeared.(Record such as fte.exe does not exist.)

 

 

Result of 2018120307131331_Amcache_DevicePnps.csv.

f:id:hideakii:20181203073926p:plain

 

Verification environment: Windows 10 1083

Reference URL:

df-stream.com

 

f:id:hideakii:20181203072406j:plain

 

 

USB and Amcache

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

Have you seen the Amcache season of Forensic Lunch Test Kitchen?

Unfortunately, I have not seen everything yet. I am planning to enjoy them at the weekend.

and I saw @errno_fail tweet. They are very interesting comments.

 

Either way, I have done quite limited tests on USB memory and Amcache.hve.
Since it is not a sufficient test, it may be overlooking something.

First of all, I ran several programs from the USB memory(F:).

Run autorunsc64.exe as CLI program. The following is Sysmon event log.

f:id:hideakii:20181202104636p:plain

And as a GUI program, I executed Dcode.exe.

f:id:hideakii:20181202104831p:plain

The USB memory is still connected to the system.

I waited for the Application Experience task to be executed.(The execution date and time of the task is Japan time.)

f:id:hideakii:20181202104944p:plain

Parse Amcache.hve with AmcacheParser and filter by F:.
Dcode.exe is recorded, but Autorunsc64.exe does not exist.

f:id:hideakii:20181202105306p:plain

FileKeyLastWriteTimestamp(UTC) does not exactly match the date and time of the Sysmon event.(I checked the Sysmon event log that there is no record at 05:54)

 

I removed the USB memory from the system and waited one day. 
There was no change in the parse result of Amcache.hve. I do not know how long F: drive information will be maintained.

 

Next test.
I ran the program from the USB memory and removed the USB memory from the system.

f:id:hideakii:20181202110531p:plain

I waited for the Application Experience task to be executed. At the time when the task is executed, the USB memory is not connected.

As already mentioned by @ errno_fail, records are not recorded if USB is not connected.

f:id:hideakii:20181202110902p:plain

I felt strange about FileKeyLastWriteTimestamp.(The key is being updated before the task is executed.)
Do keys generate according to task execution? When is this key created?

Interestingly, the timestamp of Amcache.hve and LOG file is old. The contents of the file have been updated, but Date modified has not been updated. (This is also seen in the thumbcache_ * file.)

f:id:hideakii:20181202111634p:plain

I tried Shift + Shutdown.

f:id:hideakii:20181202112548p:plain

Muuu...Is it updated when a complete shutdown is performed?(In this system, fast startup is enabled.)

 

I have not tried running the LNK file on the USB memory yet.
I will continue testing.

 

Verification environment: Windows 10 1083

Reference URL:

 

www.hecfblog.com

dfir.ru

 

f:id:hideakii:20181202103010j:plain

 

 

 

ReFS and File ID

Note:I translated Japanese into English using Google Translate.
Thank you, Google. 

The File ID of ReFS looks different from NTFS. Using USN Journal, confirm the ReFS File ID.

I enabled the USN Journal on the ReFS volume used for testing.

f:id:hideakii:20181112200756p:plain

Create the folder Pictures and check the File ID.

File ID is "00000000000007020000000000000000". ⇒ 1,794
Parent file ID : 00000000000006000000000000000000 ⇒ 1,536

f:id:hideakii:20181112200913p:plain

Copy Example1.jpg to the Picutres folder. The file ID of Example1.jpg is 00000000000007020000000000000001.

f:id:hideakii:20181112201354p:plain

f:id:hideakii:20181112201541p:plain

Add more files and check the File ID. The last number will increase.

f:id:hideakii:20181112202057p:plain

example2.jpg
File ID : 00000000000007020000000000000002
Parent file ID : 00000000000007020000000000000000

example3.jpg
File ID : 00000000000007020000000000000003
Parent file ID : 00000000000007020000000000000000

 

Delete example3.jpg and copy example4.jpg to the Pictures folder.
Will 0000000000000003 be reused?

f:id:hideakii:20181112202522p:plain

f:id:hideakii:20181112202601p:plain

example4.jpg
File ID : 00000000000007020000000000000004
Parent file ID : 00000000000007020000000000000000 

 

Next, let's move the file. Parent file ID is updated and File ID is unchanged.

move Pictures\example4.jpg e:\

example4.jpg
File ID : 00000000000007020000000000000004
Parent file ID : 00000000000006000000000000000000

Using File ID, can I check the parent folder at the time of file creation?

 

Copy example3.jpg to the Pictures folder and check the File ID.

f:id:hideakii:20181112203731p:plain

example3.jpg
File ID : 00000000000007020000000000000005
Parent file ID : 00000000000007020000000000000000

Create "subfilder1" under the Pictures folder.

f:id:hideakii:20181112204700p:plain

705 was set for the File ID of "subfilder 1". In addition, 703 is in $ RECYCLE.BIN and 704 is a folder of SID.

 

Discard example3.jpg to the trash. The file name of Example3.jpg is changed but the File ID does not change.

f:id:hideakii:20181112205445p:plain

 

Is the File ID in ReFS composed of two of folder number and file number?

 

Verification environment: Windows 10 1083

Reference URL:

docs.microsoft.com

USN_RECORD_V4 structure (Windows)

 

f:id:hideakii:20181112200145j:plain

 

 

Refs and USN Journal(2)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

I got the Refs volume of Win10 1083 as E01 image. You can download it from the following URL. (That is the volume I tested last time.)

 

Win10_1083_Refs.E01
https://drive.google.com/open?id=1adzuHvXH2FlMpQnGHh2S-i9FXvV1Llwd

 

Unfortunately I do not have a tool to parse Refs. Therefore, I will use my own eyes :-)

f:id:hideakii:20181111071452p:plain

Look for the USN record of example.jpg in the Refs volume. 

f:id:hideakii:20181111071556p:plain

I found several file names at offset 268445728. Well, is this a USN Journal record?

I compared with the structure of USN_RECORD_V2, but some did not match.

f:id:hideakii:20181111071839p:plain

So, I tried the structure of USN_RECORD_V3.

f:id:hideakii:20181111072945p:plain


68 00 00 00 ⇒ RecordLength ⇒ 104
03 00 ⇒ MajorVersion ⇒ 3
00 00 ⇒ MinorVersion ⇒ 0
01000000000000000207000000000000 ⇒ FileReferenceNumber (16 bytes)
00000000000000000207000000000000 ⇒ ParentFileReferenceNumber (16 bytes)
D8 07 00 00 00 00 00 00 ⇒ USN
DE A4 43 09 FF 73 D4 01 ⇒ TimeStamp ⇒ FILETIME (UTC): 11/4/2018 5:27:10 AM
00010000Reason ⇒ 0x00010000 USN_REASON_HARD_LINK_CHANGE
00000000 ⇒ SourceInfo
00000000 ⇒ SecurityId
20000000 ⇒ FileAttributes
16 00 ⇒ FileNameLength ⇒ 22
4C 00 ⇒ FileNameOffset ⇒ 76
6500780061006D0070006C0065002E006A0070006700000000000000 ⇒ FileName (variable) ⇒ example.jpg

The Refs' USN Journal appears to be using USN_RECORD_V3. However, I do not know if it is always USN_RECORD_V3.

The structure differs between USN_RECORD_V3 and USN_RECORD_V2. For this reason, carving assuming V2 structure will fail.

 

By the way, I noticed that the USN related URL of Microsoft was 404.

So, I refer to the URL that David taught me. Thank you!

 

<add>

Zaki-san taught me that UsnJrnl2Csv supports USN_RECORD_V3.

I exported from offset 268443648 to 268449952.

f:id:hideakii:20181111174806p:plain

f:id:hideakii:20181111175106p:plain

However, no results were obtained.

f:id:hideakii:20181111175907p:plain

 

 

Verification environment: Windows 10 1083

Reference URL:

[MS-FSCC]: USN_RECORD_V2

[MS-FSCC]: USN_RECORD_V3

GitHub - jschicht/UsnJrnl2Csv: Parser for $UsnJrnl on NTFS

www.williballenthin.com

 

f:id:hideakii:20181110085559j:plain

Refs and USN Journal

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

A little while ago I learned that ReFS supports the USN Journal.

How do I check the USN Journal on ReFS?

Format E: drive with ReFS.

f:id:hideakii:20181104141239p:plain

Start the administrator command prompt. Check the status of USN Journal with fsutil command.

For some reason, access is denied. Also I could confirm that USN journal is not valid.

f:id:hideakii:20181104141639p:plain

Enable USN Journal. However, the queryjournal option is access denied.

f:id:hideakii:20181104141919p:plain

f:id:hideakii:20181104142008p:plain

Create the Pictures folder and read the USN Journal. The readjournal command worked.(also tried the CSV option)

f:id:hideakii:20181104142326p:plain

f:id:hideakii:20181104142547p:plain

Copy example.jpg to the Pctures folder and browse.

f:id:hideakii:20181104142922p:plain

Since ReFS does not support ObjectID, ObjectID is not set.

f:id:hideakii:20181104143135p:plain

NTFS ADS is supported. Perhaps the USN Journal also exists as $J?

f:id:hideakii:20181104143335p:plain

So how do I get USN Journal data on ReFS in RAW format?

 

<add>

I exported the area of ReFS and tried Carving. Unfortunately, no USN record was found.

f:id:hideakii:20181104145714p:plain

f:id:hideakii:20181104145937p:plain

f:id:hideakii:20181104150106p:plain

 

Verification environment: Windows 10 1083

Reference URL:

https://en.wikipedia.org/wiki/ReFS

https://www.jpcert.or.jp/present/2018/JSAC2018_03_yamazaki.pdf

Bulk Extractor with Record Carving | Forensicist

 

f:id:hideakii:20181104140631j:plain