HWID 기반 라이선싱: 활성화 및 하드웨어 변경

노드 락 라이선싱은 활성화를 특정 기기 또는 기기 집합으로 제한합니다. 하드웨어에서 도출된 식별자는 이 정책을 구현하는 한 가지 방법이지만, 누락된 식별자, 가상 머신 및 합법적인 업그레이드를 고려하여 설계되어야 합니다. 이 가이드는 그러한 구현 결정에 중점을 둡니다. 비기술적 개요는 HWID 기반 라이선싱이란?에서 시작하세요.

활성화 흐름

고객이 소프트웨어를 활성화할 때 다섯 가지가 일어납니다:

1. 구매. 고객이 소프트웨어를 구매하고 라이선스 키를 받습니다.
2. 수집. 앱이 기기의 HWID를 읽습니다 — 일반적으로 여러 하드웨어 식별자(마더보드 UUID, 디스크 시리얼, CPU ID)의 SHA-256 해시입니다.
3. 전송. 앱이 라이선스 키 + HWID를 라이선스 서버로 전송합니다.
4. 기록. 서버가 키-기기 바인딩을 저장합니다.
5. 검증. 이후 실행 시마다 앱이 현재 기기의 HWID가 기록된 것과 일치하는지 확인합니다.

HWID가 일치하면 소프트웨어가 실행됩니다. 일치하지 않으면 사용자에게 다시 활성화하라는 메시지가 표시됩니다 — 활성화 제한에 따라 허용될 수도, 아닐 수도 있습니다.

라이선싱에 좋은 HWID란?

모든 하드웨어 식별자가 라이선싱에 적합한 것은 아닙니다. 다음 조건을 만족하는 식별자가 필요합니다:

• 안정적 — 일반적인 사용 중(OS 업데이트, 재부팅, 드라이버 업데이트)에 변경되지 않습니다
• 고유 — 기기마다 다릅니다
• 스푸핑 어려움 — 하나의 구성 요소를 변경해도 검사를 우회할 수 없습니다

가장 좋은 조합은 보통 다음과 같습니다:

| 식별자 | 역할 | | --- | --- | | 마더보드 SMBIOS UUID | 기본 앵커 — OS 재설치 후에도 유지되며 마더보드 교체 시에만 변경 | | 디스크 시리얼 | 강력한 보조 — 드라이브마다 고유하며 드라이브 교체 시 변경 | | CPU ProcessorId | 세 번째 — CPU 모델을 식별하고 다양성을 추가 |

엄격한 복합 SHA-256 해시는 모든 입력이 일치해야 할 때 유용하지만, 포함된 값 중 하나라도 변경되면 완전히 바뀝니다. 제품이 교체된 드라이브나 네트워크 어댑터를 허용해야 한다면, 보호된 구성 요소 해시를 비교하거나 문서화된 가중치 일치 정책을 사용하세요.

다음에만 의존하는 것은 피하세요:

• MAC 주소 — 소프트웨어에서 쉽게 스푸핑되며 NIC 교체 시 변경
• Windows MachineGuid — OS 재설치 시 변경되며 하드웨어에 종속되지 않음
• 브라우저 지문 — 너무 변동성이 크며 브라우저 업데이트 시 변경

하드웨어 업그레이드 문제

이것이 HWID 기반 라이선싱에서 가장 어려운 부분입니다. 고객이 마더보드를 교체하거나 SSD를 바꾸면 HWID가 변경됩니다. 시스템이 이를 완전히 새로운 기기로 취급하면 고객은 활성화를 잃고 화가 납니다.

좋은 라이선싱 시스템은 다음으로 이를 처리합니다:

1. 셀프 서비스 비활성화

고객이 고객 포털을 통해 이전 기기를 해제한 후 새 하드웨어에서 재활성화하게 합니다. 이것이 가장 깔끔한 해결책입니다 — 지원 티켓이 필요 없습니다.

2. 잠금이 아닌 활성화 한도

정확히 하나의 기기만 있다고 가정하는 대신, 제품 및 라이선스 조건에 맞는 활성화 허용량을 선택하세요. 작은 여유 허용량은 우발적 잠금을 줄일 수 있고, 셀프 서비스 기기 목록은 고객이 오래된 활성화를 해제할 수 있게 합니다.

3. 퍼지 매칭

정확한 HWID 일치를 요구하는 대신, 새 HWID를 이전 것과 비교하여 몇 개의 구성 요소가 변경되었는지 계산하세요. 하나의 구성 요소만 다르면(예: 새 SSD) 허용합니다. 모든 것이 변경되었으면 재활성화를 요구하세요.

4. 유예 기간

시간 제한 유예 기간은 고객이 재활성화를 완료하는 동안 액세스를 유지할 수 있습니다. 기간은 제품의 위험, 오프라인 요구 사항 및 지원 모델에 맞춰야 하며, 하나의 보편적인 숫자를 사용하지 마세요.

HWID 밴: 다른 측면

게임 안티치트 시스템은 같은 기술을 사용하지만 반대로 작동합니다. 액세스를 부여하는 대신 거부합니다. 치터가 적발되면 게임은 그 HWID를 기록하고 그 기기에서 플레이하는 모든 계정을 차단합니다.

이것은 사용자명이 아닌 물리적 하드웨어에 연결되어 있어 계정 밴보다 우회하기 어렵습니다. 하지만 같은 약점이 있습니다: 하드웨어 업그레이드가 HWID를 변경하므로, 일부 게임은 밴 회피를 어렵게 만들기 위해 여러 식별자와 퍼지 매칭을 사용합니다.

HWID 밴을 받았을 수도 있다고 생각된다면, HWID 밴 확인 도구를 사용하여 밴이 하드웨어 수준인지, 계정 수준인지, IP 수준인지 진단하세요.

직접 구축하기 vs SDK 사용하기

하드웨어 지문 코드를 직접 작성하는 것은 다음 엣지 케이스를 다뤄야 함을 의미합니다:

• 가상 머신은 호스트와 다른 식별자를 가지며, 변경하기 더 쉽습니다
• 일반 시리얼 — 일부 저렴한 마더보드는 일반적이거나 빈 시리얼 번호를 보고합니다
• 크로스 플랫폼 지원 — Windows, macOS, Linux는 완전히 다른 API로 하드웨어 식별자를 노출합니다
• 권한 요구 사항 — 일부 식별자는 관리자/루트 액세스가 필요합니다
• wmic 지원 중단 — WMIC는 Windows 11 24H2에서 기본적으로 비활성화되어 있으므로 스크립트는 PowerShell CIM 또는 지원되는 API를 사용해야 합니다

상용 제품을 구축 중이라면, 플랫폼 간 하드웨어 지문을 처리하는 라이선싱 SDK가 몇 달의 작업을 절약할 수 있습니다. 하지만 단일 플랫폼 도구를 위한 간단한 HWID만 필요하다면, HWID 찾기 가이드의 코드 예제로 시작하기에 충분합니다.

핵심 요약

HWID 기반 라이선싱은 강력하지만 하드웨어 변경을 신중하게 처리해야 합니다. 핵심 결정은 다음과 같습니다:

1. 어떤 식별자를 결합할지 — 안정적이고 하드웨어에 종속된 값을 선호
2. 몇 개의 활성화를 허용할지 — 한도를 라이선스 및 지원 모델에 맞춤
3. 업그레이드를 어떻게 처리할지 — 셀프 서비스 비활성화, 구성 요소 매칭 또는 둘 다 사용
4. 직접 구축할지 구매할지 — 간단한 도구는 DIY 가능, 상용 제품은 SDK의 혜택을 봄

본인의 HWID를 확인해야 하나요? 도구를 다운로드하거나 지금 명령을 실행하세요. 누군가 보낸 HWID 문자열을 검증하고 싶으신가요? 온라인 확인 도구에 붙여넣으세요.