@port139 Blog

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

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

 

 

Refs and USN Journal(2)

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

I got the Refs volume of Win10 1803 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 1803

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

Audit PNP Activity and ID 6416

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

When audit setting "Audit PNP Activity" is enabled on Windows 10, event ID 6416 is recorded. Auditing is not enabled for this item by default.

Let's check the record when connecting the USB memory.

f:id:hideakii:20181028170012p:plain

Connect the USB memory. This USB memory was connected to the system for the first time.

f:id:hideakii:20181028170343p:plain

Three records were recorded in the security log.

f:id:hideakii:20181028170612p:plain

ID 6416

f:id:hideakii:20181028170938p:plain

f:id:hideakii:20181028171006p:plain

f:id:hideakii:20181028171036p:plain

The user name is the computer account. It seems that it is necessary to confirm the account connected the USB device to the system with another item.

Slightly later, another 6416 records are also recorded. Volume name is recorded in the item of DeviceDescription.

f:id:hideakii:20181028171701p:plain

f:id:hideakii:20181028172043p:plain

Event IDs 6419 and 6420 are recorded when device is disabled.

Interesting, ID 6419 has recorded the user who disabled the device.

f:id:hideakii:20181028172451p:plain

f:id:hideakii:20181028172533p:plain

f:id:hideakii:20181028172616p:plain

When you enable the device, IDs 6421 and 6422 are recorded.
Event ID 6421 records the user who activated the device.

f:id:hideakii:20181028173020p:plain

f:id:hideakii:20181028173058p:plain

Perform removal of the device.

f:id:hideakii:20181028173412p:plain

Unfortunately, no record was recorded on removal of the device.

While shutting down the system with the USB device connected, records were not recorded.

When rebooting the system with the USB device connected, ID 6416 is recorded after system startup. (There was only one record related to the USB device.)

f:id:hideakii:20181028174625p:plain

 

Verification environment: Windows 10 1083

Reference URL:

docs.microsoft.com

6416(S) A new external device was recognized by the System. (Windows 10) | Microsoft Docs

 

f:id:hideakii:20181028165248j:plain

File System Tunneling and C:\

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

Last week I enjoyed File System Tunneling.
Unfortunately, I could not reproduce File System Tunneling with NTFS 'E: drive. This time I use the C: drive for testing.

Also, last time I did not refer to the USN journal and $LogFile.

Can I find out the occurrence of File System Tunneling from the USN Journal?

Copy the owl image file to the C:\Pictures folder.

f:id:hideakii:20181019082238p:plain

Check the USN journal and the timestamp.

>fsutil usn readjournal c:

f:id:hideakii:20181019082425p:plain

f:id:hideakii:20181019083825p:plain

Delete the file owl.jpg and create the same file name.

f:id:hideakii:20181019084337p:plain

Use usn_analytics to parse the USN journal.

f:id:hideakii:20181019085116p:plain

Let's check the parsing result.
I was expecting a record of "Basic Info Change", but it was not there.

f:id:hideakii:20181019085621p:plain

Confirm the meta information of the created file.
The timestamp of Created is restored by File System Tunneling. (Created time stamps of $SI and $FN, both have been restored.)

f:id:hideakii:20181019090039p:plain

Use LogFileParser to parse $LogFile and check the record of owl.jpg. 

When you confirm the InitializeFileRecordSegment, Created time stamp has restored value appeared.

f:id:hideakii:20181019094630p:plain

Next, try changing the file name. I copied the owl.tmp file to the Pictures folder.

f:id:hideakii:20181019153423p:plain

f:id:hideakii:20181019153629p:plain

Confirm the parse result of USN journal, Basic Info Change is not recorded.

f:id:hideakii:20181019154719p:plain

Confirm Created time stamp with file meta information.
Interestingly, the Created timestamp of $FN was not updated.

f:id:hideakii:20181019155201p:plain

Check the record in $ LogFile.

f:id:hideakii:20181019164842p:plain

.....If a FILE record already exists, the Created timestamp of $SI is restored and $FN is not restored?

 

Verification environment: Windows 10 1083

Reference URL:

 

f:id:hideakii:20181019080111j:plain

 

File System Tunneling and E:\

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

iria_piyo has published some interesting verifications on File System Tunneling in the blog. I read those blogs and I wanted to see how the USN Journal was recorded.

(2013 article in the reference URL, Keydet89 has already mentioned the USN journal.)

iria-piyo.hatenablog.com

Unfortunately I do not have an image of fried eggs (medamayaki.png) so I will use the otter image. 

Format E drive as NTFS and enable USN Journal.

E:\>fsutil usn createjournal e: m=1 a=1

f:id:hideakii:20181012201122j:plain

Copy the JPEG file to the E: Pictures folder using Windows Explorer.

f:id:hideakii:20181012182608j:plain

Check the file meta information with Autopsy.

f:id:hideakii:20181012185555j:plain

Delete the file and create the same file name. I should have recorded the time before deleting the file...

f:id:hideakii:20181012190026j:plain

Unlike expected results, Created timestamp was not restored.
...why?

f:id:hideakii:20181012190630j:plain

Copy the image file with a different name and test again.

f:id:hideakii:20181012191943j:plain

This time, the same file name is created by deleting the file and changing the file name.

f:id:hideakii:20181012192200j:plain

Created time stamp was not restored......why????

f:id:hideakii:20181012192741j:plain

Just to be sure, I check the registry, but there is no value of MaximumTunnelEntries.
By the way, why is NtfsDisableLastAccessUpdate value 80000002? (DisableLastAccess = 2 (System Managed, Disabled))

f:id:hideakii:20181012193504j:plain

I will test the same operation on the C: drive.
As before, I copied the otter image to c:\Pictures folder.

f:id:hideakii:20181012195235j:plain

f:id:hideakii:20181012195634j:plain

Created timestamp has been restored.

f:id:hideakii:20181012195958j:plain

 Muuuuuu...Why is the Created time stamp not restored on E: drive?

 

<FAT32>

I formatted E: drive with FAT32, and performed the same test, it was the result below.

f:id:hideakii:20181012204329j:plain

f:id:hideakii:20181012204910j:plain

f:id:hideakii:20181012205330j:plain

f:id:hideakii:20181012205339j:plain

On FAT32, Created time stamp is restored.

 

 

Verification environment: Windows 10 1083

Reference URL:

www.afodblog.com

 

 

f:id:hideakii:20181012180753j:plain

Timestamp and USN_REASON_BASIC_INFO_CHANGE

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

My question is

Can I find timestamp changes using USN Journal?

Let's try it.
Enable USN Journal with volume E :.

f:id:hideakii:20180930191719j:plain

Copy the sample JPEG file to the E: drive, using the explorer.

f:id:hideakii:20180930191902j:plain

Use Autopsy to check the time stamps of $SIA and $ FN.

f:id:hideakii:20180930192156j:plain

The record containing "Basic info change" appeared twice.

f:id:hideakii:20180930192948j:plain

Use Powershell to change the timestamp of LastWriteTime. 

f:id:hideakii:20180930193233j:plain

f:id:hideakii:20180930193406j:plain

In the figure below, it is easy to confirm that "Basic info change" has been changed. Unfortunately, I can not identify that the timestamp value has changed.

f:id:hideakii:20180930193458j:plain

What happens if I unzip the ZIP file?  I created a compressed file using 7zip and expanded it from explorer.

f:id:hideakii:20180930194148j:plain

f:id:hideakii:20180930194324j:plain

A record of "Data extend | File create | Close" is recorded, followed by a record of "Basic info change".

f:id:hideakii:20180930194913j:plain

Next, unzip the ZIP file using 7zip and check the time stamp.

f:id:hideakii:20180930195148j:plain

In the case of 7zip, I was able to confirm the same output result as when copying files in Explorer.

f:id:hideakii:20180930195436j:plain

Move the sample JPEG file on the C: drive to the E: drive and check the time stamp.

f:id:hideakii:20180930200648j:plain

f:id:hideakii:20180930200809j:plain

There was an ObjectID. It was different from my expectation.

f:id:hideakii:20180930201005j:plain

Try again with a file that does not have an ObjectID.

f:id:hideakii:20180930201600j:plain

f:id:hideakii:20180930201712j:plain

f:id:hideakii:20180930201904j:plain

I forgot to confirm the pattern when I created a new file.

f:id:hideakii:20180930203112j:plain

When creating a new file, "Basic info change" is not recorded.

f:id:hideakii:20180930203144j:plain

Open the file with Notepad.exe and update the content.

f:id:hideakii:20181001191007j:plain

I updated the file, but "Basic info change" is not recorded.

f:id:hideakii:20181001191055j:plain

 

I need to test more patterns.

 

Verification environment: Windows 10 1083

Reference URL:

 

docs.microsoft.com

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

GitHub - jschicht/SetMace: Manipulate timestamps on NTFS

 

f:id:hideakii:20180930190944j:plain