คุณจะรู้ได้อย่างไรว่าได้ผล?

กับเครื่องมือประเภทนี้ตัวอื่นทุกตัว คุณไม่มีทางรู้ แอปเริ่มทำงาน แสดงวันที่บางอย่าง แล้วคุณก็สันนิษฐานเอาเอง แต่แอปอาจอ่านนาฬิกาผ่านเส้นทางที่ไม่มีอะไรดักไว้ - และเมื่อนั้นคำว่า “ทดสอบผ่าน” ก็ไม่มีความหมายเลย

ความล้มเหลวที่ไม่มีอาการ

เครื่องมือเลื่อนเวลาที่พลาดช่องทางหนึ่งจะไม่แครชและไม่เตือน แอปแค่อ่านวันที่จริงผ่านฟังก์ชันเดียวที่ไม่มีใครฮุกไว้ แล้วทำงานเหมือนที่ทำในบ่ายธรรมดาวันไหนก็ได้ การทดสอบเป็นสีเขียว และบั๊กก็ถูกปล่อยออกไป

RunAsDate ซื่อสัตย์เรื่องนี้ในเอกสารของตัวเอง - มันบอกว่ามัน“จะไม่มีผลกับแอปที่ดึงวันที่/เวลาปัจจุบันจากแหล่งอื่น” - แล้วปล่อยให้คุณหาเองว่าแอปของคุณเป็นหนึ่งในนั้นหรือไม่ เครื่องมือนี้ถือประโยคเดียวกันนั้นเป็นสิ่งที่ต้องวัด

สิ่งที่เซสชันรายงานจริง ๆ

เอาต์พุตจริง จากการรันเครื่องมือกับโพรบทดสอบตัวหนึ่งของโปรเจกต์นี้ - โพรบที่ตั้งใจเปิดการเชื่อมต่อเครือข่าย:

$ chrono run "...\pnet-x64.exe" --at 2038-01-19T03:14:07 --report session.txt

Chrono Mock - session report
  target:   C:\ChronoMock\tools\probes\bin\pnet-x64.exe
  verdict:  WORKS - time substitution took effect  (processes: 1)
            every process that read time saw the session clock
  session:  fake clock reached 2038-01-19T03:14:10
            real elapsed 3.4s, fake elapsed 3.4s
  exited:   the target closed itself with code 0
  covered channels (substituted, with call counts, 4 calls in all):
            - pid 9152: GetSystemTimeAsFileTime (1 call)
            - pid 9152: NtQuerySystemTime (3 calls)
            ... every other channel, including the ones never called
  observed channels (hooked but left real):
            - pid 9152: NtCreateUserProcess (0 calls)
            - pid 9152: connect (1 call)
  warnings:
            - the target opened a network connection - it may read time from a
              server, which no local hook can cover (source.network_at_start)
  requested:  2038-01-19T03:14:07 (zone +02:00 (host default), mode flow)

สองบล็อกสุดท้ายคือประเด็น ไม่มีอะไรล้มเหลวที่นี่ - ผลสรุปคือใช้งานได้ - แต่รายงานก็ยังบอกขึ้นมาเองว่าแอปนี้คุยกับเครือข่ายก่อนจะทำเสร็จ ฮุกในเครื่องจึงอาจไม่ใช่เรื่องราวทั้งหมด ประโยคนั้นคือความต่างระหว่างการทดสอบที่คุณไว้ใจได้กับที่ไว้ใจไม่ได้

หน้าจอผลลัพธ์ของ Chrono Mock โดยเปิดส่วน What the application read อยู่: ตารางที่มีคอลัมน์ Function, Read from และ Reads NtCreateUserProcess ถูกระบุว่าอ่านจากนาฬิกาจริงตามการออกแบบ และ connect ถูกระบุว่าอ่านจากนาฬิกาจริงตามการออกแบบและถูกฮุกช้า ส่วนแถวที่เหลือ - GetSystemTimeAsFileTime, NtQuerySystemTime, GetTimeZoneInformation และอื่น ๆ - อ่านจากนาฬิกาปลอม แต่ละแถวมีจำนวนของตัวเอง ใต้ตารางมีคำเตือนสองข้อ — คำตอบเดียวกันในหน้าต่างโปรแกรม ทุกฟังก์ชันที่แอปอาจถาม สิ่งที่มันอ่านจริง และกี่ครั้ง - รวมถึงตัวที่ตั้งใจปล่อยไว้บนนาฬิกาจริง ซึ่งถูกระบุชื่อ ไม่ถูกนับเป็นผ่านโดยเงียบ ๆ

สี่ผลสรุป และรหัสออกของแต่ละอัน

ผลสรุปได้มาจากภายในโพรเซสที่กำลังรัน ก่อนที่คุณจะเริ่มทำงาน และมันคือรหัสออกของเครื่องมือเอง ไปป์ไลน์จึงแตกสาขาตามมันได้

ผลสรุป	รหัสออก	ความหมาย
ใช้งานได้	0	ทุกโพรเซสที่อ่านเวลาเห็นนาฬิกาของเซสชัน
ใช้งานได้บางส่วน	10	บางช่องทางครอบคลุม บางช่องทางไม่ครอบคลุม - ช่องที่ไม่ครอบคลุมจะแสดงรายการ
ใช้งานไม่ได้	11	การแทนที่เวลาไปไม่ถึงช่องทางสำคัญ
ระบุไม่ได้	4	ยืนยันความครอบคลุมไม่ได้ - คำว่า “ฉันไม่รู้” ที่ซื่อสัตย์

เมื่อผลสรุปคือ “ใช้งานไม่ได้” โพรเซสจะถูกหยุดทันที ก่อนที่คุณจะโต้ตอบกับมันได้ ผลสรุปไม่อาจมาก่อนการเปิดโปรแกรม เพราะแหล่งความจริงเพียงแหล่งเดียวคือค่าที่อ่านจากภายในโพรเซสที่กำลังรัน สิ่งที่รับประกันคือคุณจะรู้ความจริงก่อนเริ่มทำงาน - ไม่ใช่ว่าการเปิดที่ถูกกำหนดให้ล้มเหลวจะไม่เกิดขึ้น คุณเลือกข้ามและไปต่อได้ และเซสชันจะถูกทำเครื่องหมายว่าไม่น่าเชื่อถือทุกที่ที่ปรากฏ รวมถึงหลักฐานใดก็ตามที่คุณส่งออก

รหัสอื่น ๆ บอกว่าสิ่งที่ผิดพลาดคือการรันเอง ไม่ใช่การแทนที่ เช่น ใช้งานผิด เป้าหมายที่เริ่มไม่ได้ การรันที่ถูกตัดกลางคัน หรือมีเซสชันอื่นทำงานอยู่แล้ว และไม่มีรหัสใดเป็นผลสรุป ตารางเต็มอยู่ในข้อมูลอ้างอิงบรรทัดคำสั่ง

ครอบคลุม สังเกต และไม่ครอบคลุม

ช่องทางแบ่งเป็นสามกลุ่ม และกลุ่มกลางคือกลุ่มที่น่าสนใจ

ครอบคลุม - ฮุกและแทนที่แล้ว แอปถามและได้นาฬิกาของเซสชัน จำนวนครั้งที่เรียกบอกว่ากี่ครั้ง
เฝ้าสังเกต - ถูกดัก ถูกนับ และจงใจปล่อยให้บอกความจริง การรอออบเจกต์อยู่ที่นี่ เพราะการย่อเวลารออาจปลอมการหมดเวลาบนแฮนเดิลจริงได้ ตัวจับเวลามัลติมีเดียก็อยู่ที่นี่ เพราะการปรับสเกลจะทำให้จังหวะเสียงและ MIDI เคลื่อน ทั้งสองถูกเฝ้าดูเมื่อเซสชันปรับสเกลแกนเวลาที่ผ่านไป การเชื่อมต่อเครือข่ายและเส้นทางสร้างโพรเซสหนึ่งเส้นทางอยู่ที่นี่ในทุกเซสชัน เพราะเป็นหลักฐาน ไม่ใช่นาฬิกา ตัวนับความละเอียดสูงไม่อยู่ในกลุ่มนี้ มันไม่ถูกแตะต้องจนกว่าคุณจะขอด้วย --scale-qpc และเมื่อนั้นจึงถูกครอบคลุม
ไม่ครอบคลุม - ช่องทางที่แอปอ่านซึ่งการแทนที่เวลาไปไม่ถึง สิ่งนี้คือสิ่งที่ทำให้ผลสรุปกลายเป็น ใช้งานได้บางส่วน และถูกแสดงรายการตามชื่อ ไม่ถูกสรุปรวมจนหายไป

จำนวนศูนย์ก็เป็นข้อมูลเช่นกัน: ช่องทางถูกฮุกไว้และแอปไม่เคยถามเลย นั่นคือเหตุผลที่รายงานแสดงรายการมันแทนที่จะซ่อน

สิ่งที่การตรวจสอบมองไม่เห็น

รายงานซื่อสัตย์เรื่องความครอบคลุม ซึ่งหมายถึงซื่อสัตย์เรื่องขอบเขตของตัวเองด้วย สิ่งเหล่านี้ถูกอ่านโดยไม่มีการเรียกฟังก์ชันให้ดัก หรืออยู่นอกโพรเซสทั้งหมด:

การอ่านโดยตรงจากหน้าข้อมูลโหมดผู้ใช้ที่ใช้ร่วมกัน - ค่าอยู่ในหน่วยความจำ จึงไม่มีอะไรให้ฮุก พบได้น้อยในแอปทั่วไป แต่พบบ่อยในโค้ดไลเซนส์และป้องกันการแก้ไข
การเรียกระบบโดยตรงที่ข้ามเอ็กซ์พอร์ตมาตรฐาน - รูปแบบเดียวกัน
เวลาที่ได้มานอกโพรเซส ผ่าน WMI เซิร์ฟเวอร์ COM นอกโพรเซส หรือ RPC
เวลาจากเครือข่าย - ส่วนหัว HTTP Date NTP คำตอบของ API หรือนาฬิกาของเซิร์ฟเวอร์ฐานข้อมูลเอง
เวลาจากไดรเวอร์เคอร์เนล

กรณีเครือข่ายคือกรณีที่การตรวจสอบอย่างน้อยสังเกตเห็นได้ จึงมีคำเตือนในรายงานข้างต้น สำหรับที่เหลือ ผลสรุปใช้งานได้หมายความว่าช่องทางที่เครื่องมือนี้มองเห็นถูกครอบคลุมแล้ว - ไม่ใช่ว่าไม่มีเส้นทางอื่นอยู่

ในไปป์ไลน์

--json ส่งออกข้อเท็จจริงเดียวกันในรูปแบบสำหรับเครื่อง --report เขียนฉบับสำหรับมนุษย์ลงไฟล์ และเซสชันที่ผลสรุปเป็นอย่างอื่นนอกจาก ใช้งานได้ จะขึ้นต้นไฟล์ด้วยแบนเนอร์เตือนว่าหลักฐานไม่น่าเชื่อถือ แทนที่จะฝังไว้ท้ายไฟล์

chrono run "C:\apps\test.exe" --at 2027-12-31T23:59:59 --json --report evidence.txt

ลองใช้

ดาวน์โหลดสำหรับ Windows เทียบกับ RunAsDate