@port139 Blog

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

Task Scheduler Registry key and "Last Run Time"

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

Summary:

  • "Last Run Time" is displayed in the GUI of Task Scheduler, this value is saved in the registry.
  • Several timestamps are stored in the "Dynamicinfo" value.
    1.Task File Created
    2."Last Run Time"
    3. Action completed or Task Completed ??

---

I received a question from my colleague while testing Amcahce.
『The Task Scheduler GUI displays "Last Run Time", but where is this timestamp stored?』

f:id:hideakii:20190112085642j:plain

"Last Run Time" will also be displayed in a state in which the task of history is disabled.
I guessed it saved in the registry and searched for registry keys related to Task.

Let's check the registry key of Task Scheduler.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser

f:id:hideakii:20190112090528j:plain

The ID of this task is {47C19566-4194-4C9F-BC70-C043803D80E0}.
Look for the key that matches the task ID under the Tasks key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{47C19566-4194-4C9F-BC70-C043803D80E0}

f:id:hideakii:20190112090723j:plain

There are several values under the key. There is "Dynamicinfo" as a value that contains data in FILETIME format.

About this value, some information is provided with winreg-kb. However, there seems to be some unknown part.

03000000
08D12A59C5A9D401
8495AE0DDFA9D401
00000000
00000000
07654515DFA9D401

Decode the first time stamp.

08d12a59c5a9d401 -> 2019-01-11 15:50:17.0216712 (UTC)

The same value as this time stamp can not be found on the task screen. What is this time stamp?
I tried checking the time stamp of the Task file. It matched the created time of the Task file.

Created: 2019-01-11 15:50:17.021671200 (UTC)

f:id:hideakii:20190112091811j:plain

By the way, the Task Scheduler GUI also has a Creted column. This column displays the "RegistrationInfo" timestamp in the task file (XML). In the figure below, nothing is displayed because timestamp is not recorded in RegistrationInfo.

f:id:hideakii:20190112092020j:plain

Decode the second timestamp.
8495AE0DDFA9D401 -> 2019-01-11 18:54:17.2933508 (UTC)
This timestamp seems to match the "Last Run" Time. 1/11/2019 6:54:17 PM(UTC)

f:id:hideakii:20190112092527j:plain

Decode the third timestamp.

07654515DFA9D401 -> 2019-01-11 18:54:30.0257543(UTC)
Is this the timestamp the task completed or Action completed?
Task Completed of the history matches the date and time. 1/11/2019 6:54:30(UTC)

f:id:hideakii:20190112093107j:plain

I checked the event log, it seems that the time stamp of Action Completed is close. However, it does not match perfectly.

f:id:hideakii:20190112094406j:plain

f:id:hideakii:20190112094237j:plain

 

If the Task Scheduler event log is not enabled, registry information may be somehow clues. 

 

Verification environment: Windows 10 1809, Time zone UTC

Reference URL:

github.com

computerforensics.parsonage.co.uk

f:id:hideakii:20190112084504j:plain

 

Windows 10 Storage sense and Recycle.bin

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

Summary:

  • I tested the Recycle.bin delete option of the Storage sense feature.
  • Files in Recycle.bin are deleted by task SilentCleanup??.
  • Sample JPEG file in Recycle.bin on volume C has been deleted.
    However, Files in Recycle.bin of volumes E and F were not deleted.

---

Recycle.bin is automatically cleaned up when you enable the Storage sense option of Windows 10. Enable the option in the test environment and confirm the execution of the task to delete the file.

f:id:hideakii:20181224121043p:plain

The delete option of recycle.bin specifies 1 day.

f:id:hideakii:20181224121306p:plain

The relevant registry keys are below.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy

01 ⇒ Storage sense ON(=1)
2048 ⇒ Run Storage sense: Every day(=1)
04 ⇒ Delete temporary files that my apps aren't using
256 ⇒ 1day

f:id:hideakii:20181224121429p:plain

Move sample JPEG files to the recycle bin on the C, E, F volume.
Volumes C: and F: are NTFS and volume E: is ReFS.(These volumes are fixed disk.)

f:id:hideakii:20181224121624p:plain

You can not move files to the Recycle.Bin on removable disks.

f:id:hideakii:20181224121743p:plain

Two days later, I confirmed that the file on volume C: has been deleted.
Files on volumes E: and F: were not deleted.

f:id:hideakii:20181224121857p:plain

When was the sample JPEG file deleted?
Check the date and time that the sample JPEG file was deleted in USN Journal.

f:id:hideakii:20181224122000p:plain

In the event log, find the task executed when deleting the file. I found a time very close to the file deletion, but it does not match perfectly.
From the contents of the message, I guess that this task deleted the file.

f:id:hideakii:20181224122039p:plain

However, file deletion is recorded one second after completion of the task.

In the USN Journal, there were several records of files deleted at the same time. I am interested in what files SilentCleanup task deletes.

I need to verify further.

 

Verification environment: Windows 10 1803

Reference URL:

blogs.technet.microsoft.com

www.tenforums.com

f:id:hideakii:20181224120707j:plain

 

NTFS last access time and 1 hour (3)

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

Summary:

  1. I confirmed that the latest Last Access Time is written to disk by accessing the file after 1 hour has elapsed.
  2. After one hour elapsed, when shutting down without accessing the file, I did not check whether Last Access Time on memory is written to disk.
    <2018/12/16 Add>
    The latest Last Access Time was written to disk by shutdown.
    In the update of the Last Access Time, the MFT record time stamp was not updated.
  3. This verification had to repeat the same thing over and over....And I still know that it is not enough.

---

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.

<2018/12/16 Add>

I tested whether Last Access Time not recorded on disk is written by shutdown processing.

Last Access Time confirmed with the fsutil command has not yet been written to disk even after 1 hour.

f:id:hideakii:20181216124137p:plain

f:id:hideakii:20181216123651p:plain

Shut down the system and start it. (In this system, fast startup is enabled.)
The Last Access Time seems to have been written to the disk by the shutdown processing.

f:id:hideakii:20181216124524p:plain

I did not pay attention to the update date of the FILE record. However, it seems that it was not updated.

NTFS Last Access Time update by property display does not update Change Time. When Last Access Time is set in PowerShell, Change Time is updated.

f:id:hideakii:20181216133049p:plain

$(Get-Item f:\Butterfly.jpg).lastaccesstime=$(Get-Date "01/01/2000 00:00 am")
Change Time is updated.

f:id:hideakii:20181216133231p:plain

Display the properties of the file and update the Last Access Time.
Last Access Time is updated, but Change Time does not change.

f:id:hideakii:20181216133534p:plain

 

Verification environment: Windows 10 1803

Reference URL:

File Times - Windows applications | Microsoft Docs

 

dfir.ru

 

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.  

Summary:

  1. I used FTK Imager and Autopsy as a tool to check Last Access Time on NTFS volume. However, adding Local Drive did not produce the expected results.
    (I lost a lot of time with this repetition.)
  2. Using "PHYSICALDRIVE", expected results were obtained.
  3. I recommend you to check with PHYSICALDRIVE in the Last Access Time test.

---

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 1803

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.  

Summary:

  1. NTFS's Last Access Time resolution is one hour. ( I started the test on Win 10 ver 1803.)
  2. "fsutil file layout" command and PowerShell displays the latest timestamp.
  3. Displaying properties in Explorer may display old timestamps.(It is not sufficient verification.)
  4. @errno_fail comments on the timestamp in memory. Thank you!

---

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.

 <2018/12/16 add>

I confirmed the Last Access Time in PowerShell. PowerShell displays the latest timestamp.

f:id:hideakii:20181216092120p:plain

f:id:hideakii:20181216092321p:plain

f:id:hideakii:20181216092508p:plain

I checked the Last Access Time with PowerShell and the Last Access Time was not updated.

 

Verification environment: Windows 10 1803

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 1803

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 1803

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 1803

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