자주 묻는 질문

컴퓨터의 시계가 바뀌나요?

아니요. 앞으로도 바뀌지 않습니다. 그것이 이 도구의 존재 이유이기 때문입니다. 옮겨진 시간은 프로세스 하나와 그것이 시작한 자식 프로세스에게만 보입니다. 도메인 로그온, 인증서, Windows Update, 다른 모든 애플리케이션은 내내 실제 날짜를 봅니다.

관리자 권한이 필요한가요?

실행하는 데는 필요 없습니다. zip 버전은 설치 프로그램이 필요 없고, 레지스트리에 아무것도 기록하지 않으며, USB 메모리에 넣어 둘 수 있는 폴더에서 실행됩니다. 선택 사항인 .msi는 이 컴퓨터의 모든 계정용으로 설치되므로 설치할 때 한 번만 관리자 권한이 필요합니다.

내 앱에서 동작하나요?

솔직한 답은, 이런 종류의 도구는 그것을 미리 약속할 수 없다는 것입니다. 그래서 이 도구는 대신 측정합니다. 모든 세션은 판정(동작함, 일부 동작함, 동작하지 않음), 앱이 실제로 읽은 시간 채널의 목록과 각 채널의 호출 횟수, 그리고 커버되지 않은 채널의 목록으로 끝납니다.

앱은 아무것도 가로채지 못한 경로, 즉 서버, 데이터베이스, 런타임 계층 등을 통해 시계를 읽을 수 있습니다. 그런 일이 일어나면 테스트가 통과했다고 짐작하게 두지 않고 그 사실을 알려 줍니다.

.NET, Java, Python 앱에서도 동작하나요?

부분적으로 동작하며, 차이가 중요합니다. 셋 모두 실험적으로 표시되어 있습니다. 테스트 대상에서는 동작하고, 폭넓게 테스트되지는 않았으며, 신뢰할 수 있는 출처는 이 문단이 아니라 내장된 감사입니다.

• .NET - 벽시계와 세션 시간대가 커버됩니다. Stopwatch는 배율 적용을 직접 켜지 않는 한 실제 고해상도 카운터에 남습니다.
• Java - 벽시계, 경과 시간, 세션 시간대가 커버됩니다. 시간대는 GMT+05:30 같은 이름의 고정 오프셋으로 전달됩니다.
• Python - time.time과 datetime이 커버됩니다. perf_counter와 Python 3.13 이상의 monotonic은 직접 켜지 않는 한 고해상도 카운터를 기반으로 합니다.

Electron과 Chromium 앱에서도 동작하나요?

예, 다른 메커니즘으로 동작합니다. 이들의 시계는 인젝션이 닿지 않는 샌드박스된 렌더러 안에 있으므로, 앱을 디버깅 포트와 깨끗한 일회용 프로필로 시작하고 앱 자신의 JavaScript 시간 API를 세션 시계에 올립니다. 타이머가 실제로 들어 있는 경우가 많은 Web Worker 내부도 포함됩니다.

알아 둘 만한 한계가 하나 있습니다. Electron 애플리케이션의 메인 프로세스는 세션이 닿지 않는 Node에서 실행되므로 실제 시계를 유지하며 보고서가 이를 알려 줍니다. 페이지와 그 워커는 세션 시간대를 읽습니다.

Chromium과 Electron 모드의 동작 방식 - 무엇에 닿고 무엇에 닿지 않는지, 그리고 왜 디버깅 포트가 유의할 부분인지.

시간을 실제보다 빠르게 흐르게 할 수 있나요?

예. 정수 배율을 고르면 앱의 시계가 그 속도로 돌아갑니다. x1440이면 하루가 1분이 되어, 30일 체험 기간이 약 30분 만에 만료됩니다. 시계를 멈추거나 세션 도중에 앞뒤로 점프할 수도 있습니다.

카운트다운과 타이머는 별도의 축에 있고 그것을 빠르게 하는 것은 별도의 스위치입니다. 배율을 적용하면 많은 애플리케이션이 의존하는 동작이 바뀌기 때문입니다.

날짜는 그대로 두고 시간대만 바꿀 수 있나요?

예. 세션은 자신만의 고정 오프셋을 가지며, 시스템 시간대는 그대로 둔 채 해당 프로세스에만 보입니다. 대부분의 도구가 건너뛰는 부분이며, 시간대가 다섯 개 떨어진 고객에게서만 나타나는 버그를 재현하는 방법입니다.

서머타임은 어떻게 되나요?

세션 시간대는 서머타임이 없는 고정 오프셋입니다. 폴란드로 설정한 세션은 시계가 3월을 가리키든 7월을 가리키든 선택한 오프셋에 머뭅니다. 따라서 실제 전환을 가로지르는 실행은 그 시간대가 실제로 보여 줄 값에서 한 시간 어긋납니다.

그러므로 앱을 서머타임 전환으로 통과시키는 것은 이 도구가 아직 하지 못하는 일이며, 날짜 계산기는 짐작하지 않고 그 사실을 밝힙니다.

백신이 왜 탐지하나요?

다른 프로세스에 라이브러리를 인젝션하는 것은 문서화된 정당한 Windows 기법이지만 악성코드도 쓰기 때문입니다. 이는 기법 때문에 발생하는 오탐이며, 도구가 컴퓨터에 하는 어떤 일 때문이 아닙니다. 인젝션되는 라이브러리는 chrono_hook.dll이며, 공개된 소스에서 GPL-3.0으로 빌드되고 직접 다시 빌드할 수 있습니다. Chromium과 Electron 모드는 인젝션을 전혀 하지 않습니다.

어떻게 해야 하는지는 다운로드 페이지에 있습니다.

체험 기간을 연장하거나 라이선스를 우회하는 방법인가요?

아니요. 그런 용도로 만들어지지 않았습니다. Chrono Mock은 자신이 책임지는 소프트웨어, 즉 자신의 라이선스 만료, 자신의 갱신 로직, 자신의 월말 보고서를 테스트하기 위한 것입니다. 다른 사람의 체험 기간을 연장하는 방법을 보여 주는 예제, 시나리오, 페이지는 여기에 앞으로도 없을 것입니다.

라이선스 보호가 있는 소프트웨어는 사실 이 도구가 가장 실패하기 쉬운 경우입니다. 변조 방지 코드는 가로채기 어렵도록 일부러 고른 경로로 시간을 읽는 경우가 많고, 시계를 되감는 것은 그런 소프트웨어가 탐지하도록 작성된 조건이기 때문입니다. 반대 방향의 기능이 계획되어 있습니다. 자신의 애플리케이션에 일련의 시간 조작을 실행하고 보호 장치가 어떤 것을 잡아냈는지 보고하는 모드입니다.

지속적 통합(CI)에서 쓸 수 있나요?

예. 명령줄 빌드는 설치할 런타임이 없는 약 2.4MB의 별도 다운로드입니다. 모든 명령이 --json을 지원하고 파이프라인이 분기에 쓸 수 있는 코드로 종료하며, 세션은 증거를 파일에 기록할 수 있습니다.

RunAsDate와 무엇이 다른가요?

RunAsDate는 벽시계 함수 다섯 개를 가로채며 그 일을 잘 해냅니다. 이 도구는 시간 채널 44개를 감시하고 그중 30개를 세션 시계로 옮기며, 시계를 빠르게 하고, 프로세스에 자체 시간대를 주고, 자식 프로세스를 따라가며, 실제로 어떤 채널이 적용되었는지 나중에 알려 줍니다. 또한 오픈 소스이고, RunAsDate는 비공개 프리웨어입니다. 반면 RunAsDate는 이미 실행 중인 애플리케이션에 연결할 수 있지만 이 도구는 그렇지 못합니다.

전체 비교에서는 RunAsDate가 더 나은 선택인 경우도 설명합니다.

Windows용 libfaketime인가요?

정신은 그렇습니다. 컴퓨터가 아니라 프로그램 하나를 위해 시간을 옮긴다는 같은 발상입니다. 실제로는 다른 구현입니다. libfaketime은 Windows에 없는 LD_PRELOAD에 의존하기 때문입니다. 바로 그 내용을 다룬 페이지가 있습니다.

무료인가요? 어딘가로 무언가를 보내나요?

GPL-3.0 아래의 무료 오픈 소스입니다. 계정도 텔레메트리도 없고 인터넷에 전혀 연결하지 않으며, 네트워크 케이블을 뽑아도 도구 전체가 동작합니다.

창에는 바깥으로 이어지는 컨트롤이 두 개 있으므로, 스스로 찾게 두지 않고 미리 밝혀 둡니다. 제목 표시줄의 Donate 버튼과 GitHub 버튼입니다. 둘 중 하나를 누르면 브라우저에 주소가 전달되고, 연결하는 것은 브라우저입니다. 어느 쪽이든 Chrono Mock은 연결을 열지 않으며, 앱에 대해 측정한 것은 어디로도 전송되지 않습니다.