짧은 답변입니다:
MIFARE 클래식 1K 카드에는 만료일을 저장하는 표준 블록이 없습니다.
만료 또는 유효 기간 정보는 애플리케이션 정의 카드에 전혀 저장되지 않을 수도 있습니다.
MIFARE 클래식 1K에 만료일 필드가 있나요?
아니요.
MIFARE 클래식 1K 카드:
- Do not 기본 제공 만료 날짜 필드 포함
- Do not 표준화된 데이터 모델 따르기
- 시스템 통합자가 정의한 원시 메모리 블록만 저장합니다.
모든 만료 로직은 다음에 의해 구현됩니다:
- 호텔 액세스 시스템
- 잠금 펌웨어
- 또는 백엔드 데이터베이스
다음이 있습니다. 범용 섹터 또는 블록 없음 MIFARE 클래식 1K 카드의 만료를 “처리”합니다.
MIFARE 클래식 1K 카드의 만료일은 어느 블록에 저장되나요?
고정된 블록 번호는 없습니다.
만료일이 있는 경우 해당 만료일이 저장될 수 있습니다:
- 모든 데이터 블록(블록 0-2) 모든 부문의
- A 사용자 지정 바이너리 형식
- An 암호화 또는 난독화된 구조
- 또는 카드에 전혀 저장되지 않음
같은 업종(호텔, 체육관, 주차)에서도 공급업체마다 서로 다른 레이아웃을 사용합니다.
카드 덤프에서 만료일을 자주 찾을 수 없는 이유
대부분의 호텔 시스템은 이러한 모델 중 하나를 사용합니다:
1. 백엔드 제어 만료(가장 일반적)
- 카드에는 식별자만 저장됩니다.
- 만료는 잠금 또는 백엔드 시스템에서 확인합니다.
- 덤프에 날짜가 없습니다.
2. 인코딩 또는 암호화된 타임스탬프
- 저장된 날짜:
-
- UNIX 타임스탬프
- BCD 인코딩 날짜
- 전용 카운터
- 보통 사람이 읽을 수 없음
3. 난독화된 애플리케이션 데이터
- 값은 다음과 같습니다:
-
- 암호화
- XOR 마스크
- 체크섬으로 보호
전체 섹터 액세스 권한이 있어도 데이터의 의미가 명확하지 않습니다.
덤프를 비교하여 만료일을 식별할 수 있나요?
가끔씩은 연구 수준에서만 가능합니다.
엔지니어는 일반적으로 비교합니다:
- 갱신 전과 후 동일한 카드
- 유효 기간이 다른 여러 개의 카드
그들은 찾습니다:
- 지속적으로 변경되는 바이트
- 발행 이벤트와 연계된 패턴
이것은 not 는 올바른 해석을 보장하며 시스템 유효성 검사를 우회하지 않습니다.
만료일을 수정할 수 있나요?
실질적으로: 아니요.
날짜가 쓰기 가능한 것처럼 보이는 경우에도 마찬가지입니다:
- 잠금으로 여러 매개변수 확인
- 백엔드 카운터 및 무결성 검사 존재
- 수정된 카드는 일반적으로 인증에 실패합니다.
승인 없이 호텔 액세스 자격 증명을 수정하는 것은 대부분의 지역에서 불법입니다.
호텔 시스템에서 MIFARE Classic이 교체되는 이유
호텔들이 미페어 클래식에서 마이그레이션하는 이유는 다음과 같습니다:
- 안전한 만료 시행 부족
- 더 이상 사용되지 않는 Crypto-1 암호화 사용
- 기본 파일 시스템이 없습니다.
일반적인 대체품은 다음과 같습니다:
- 미페어 데스파이어 EV2 / EV3
- NFC 모바일 키
- 백엔드 검증 액세스 자격 증명
주요 내용(스니펫 친화적)
- MIFARE 클래식 1K에는 표준 만료일 블록이 없습니다.
- 만료 로직은 애플리케이션 정의
- 대부분의 호텔 카드는 카드에 만료일을 저장하지 않습니다.
- 덤프에서 읽을 수 있는 날짜는 드뭅니다.
- 무단 수정은 불법입니다.
FAQ(PAA에 최적화됨)
질문: 만료일이 섹터 0에 저장되나요?
섹터 0에는 일반적으로 유효 날짜가 아닌 제조업체 데이터와 애플리케이션 식별자가 포함됩니다.
질문: 만료일을 일반 텍스트로 볼 수 있나요?
거의 없습니다. 날짜는 일반적으로 인코딩되거나 암호화되거나 전혀 저장되지 않습니다.
질문: 카드를 갱신할 때 덤프가 변경되는 이유는 무엇인가요?
내부 카운터, 키 또는 토큰이 업데이트되기 때문에 반드시 날짜 필드가 아니어도 됩니다.
