PNG 파일 구조 정리

PNG(Portable Network Graphics)란?

비손실 그래픽 파일 포맷, GIF 파일에서 사용되는 L2W 데이터 압축 알고리즘이 특허가 걸려 자유롭게 사용이 불가능해지자 유니시스(미국IT기업)가 자유롭게 쓸 수 있는 PNG 포맷을 개발하였다.

파일 헤더(시그니처)

89 50 4E 47 0D 0A 1A 0A

통신 등 8비트 데이터를 지원하지 않는 시스템을 찾거나, 텍스트 파일과 구별하기 위해 사용

ASCII 코드로 “PNG”, 16진수 편집기에서 구별하기 위해 사용

DOS에서 TYPE 명령을 사용하였을때 출력을 멈추기 위해 사용 (EOF문자)

Unix-style 줄바꿈으로. UniX-DOS 변환에서 줄바꿈시에 사용

PNG 파일 청크

헤더 뒤에는 이미지 내용을 담고 있는 청크가 온다. 청크는 아래와 같이 길이, 청크타입(이름),청크데이터,CRC 4가지로 구성된다.

사진 1 : PNG 파일 청크 구조

청크타입(이름)이 대문자로 시작하면 중요 청크, 소문자로 시작하면 보조청크다.

중요 청크 : IHDR, IDAT, PLET, IEND

보조 청크 : tRNS, CHRM, gAMA, iCCP, sBIt, sRGB,iEXT ··· 등 수십개

IHDR

PNG파일 가장 앞에 오는 청크, PNG파일의 기본 정보를 저장한다.

사진 2: IHDR 구조

IHDR 청크 데이터 내용

IHDR 청크 데이터는 항상 13바이트이며 아래와 같은 내용을 가지고 있다.

width(가로, 4byte), height(세로, 4byte), Bit depth(한 픽셀이 차지하는 비트 양, 1byte),
Color Type(색의 유형, 1byte)*, Compression method(압축방법, 1byte),
Filter method(필터링 방식,1byte), interlace method(인터레이스 이용유무,1byte)**

*

사진 3: 색의 유형

** 인터레이스 메소드란 웹페이지 등 이미지를 표시할 때 이미지 로딩이 완료되기전 해상도가 낮은 이미지를 보여주기 위해 사용됨, (0 인터레이스 미사용, 1 Adam7 인터레이스 사용)

IDAT

실제 이미지 데이터가 들어가는 부분, 여러개의 IDAT가 존재할 수도 있으며 IDAT가 여러개인 경우 모든 IDAT가 다 있어야 정상 출력이 가능하다

사진 4 : IDAT 구조

IDAT 청크 데이터 내용

IDAT 이미지 데이터 블럭 , 마지막 블럭 유무 (1byte) , Little-endian 블럭 크기 (2byte),
PNG 이미지데이터(크기 가변), 필터 (1byte), IDAT 이미지 데이터 블럭

PLET

IHDR에서 color type이 indexed color일 경우 필요한 청크, 팔레트 범위를 지정해주는 청크다.

사진 5 : PLET 구조

PLET 청크 데이터 내용

0번 팔레트 RGB 값 {Red(1byte),Green(1byte),Blue(1byte)}
1번 팔레트 RGB 값 {Red(1byte),Green(1byte),Blue(1byte)}
2번 팔레트 RGB 값 {Red(1byte),Green(1byte),Blue(1byte)}
··· 반복

+ {}안에 들어가는 값 (0=Black, 255=Red), (0=Black, 255=Green), (0=Black, 255=Blue)

0이면 검정 255에 가까울수록 각 원래의 색(R,G,B)가 나온다

IEND

이미지 파일의 끝을 표시하는 청크

사진 6 : IEND 구조

단순히 파일의 끝을 알리는 청크이기 때문에 청크데이터가 없으며, 항상 0바이트이다.


보조 청크 한줄 설명(자세한 설명을 보고 싶으면 www.w3.org/TR/png 으로…)

tRNS : IHDR에서 색의 유형이 indextype 일 경우 사용되는 청크, 투명색을 지정한다

cHRM : 빨간색의 CIE 1931 x,y 색도 공간을 지정하는데 사용 (CIE 1931 위키백과 링크)

gAMA : 감마 값을 지정

iCCP : 해당 청크가 있을경우 ICC/ISO_150761-1에서 정의한 ICC 색범위를 사용

sbit : 원래의 유효 비트 수를 정의한다

sRGB : 해당 청크가 있을 경우 SRGB 색범위를 사용

cICP : 사진 디코더가 이미지를 랜더링 할때 필요한 함수를 저장하는 청크

mDCV : 사진을 랜더링(출력)할때 디스플레이에서 필요한 메타데이터를 저장

cLLi : 특정 디스플레이에서 톤 매핑을 위해 사용하는 청크

tEXt: 텍스트 데이터를 저장하는 청크

zTXT : tEXt 청크와 기능은 동일하나 텍스트를 압축할때 사용하는 청크

iTxt : 국제 텍스트 데이터 (UTF-8)을 사용하는 텍스트를 저장할때 사용

bKGD : 이미지를 표시 할 때 기본 배경색을 지정하는 청크

hIST : 팔레트에 있는 각 색상의 대략적인 사용빈도를 알려주는 청크

pHYs : 이미지 표시를 위해 의도적으로 지정한 픽셀 크기 또는 비율을 저장하는 청크

sPLT : 사진 출력을 위해 디코더에게 팔레트 관련으로 제한하는 청크 (제한이라 무시될 수도 있음)

eXIF : 카메라가 촬영하는 시간, 위치 등 메타데이터를 저장하는 청크

tIME : 이미지 최종 수정 시간을 기록하는 청크

애니메이션(움직이는) PNG 관련 청크

acTL : 해당 이미지가 애니메이션(움직이는) 사진임을 선언하는 청크

fcTL : 프레임에 관한 메타데이터 청크

fdat : 각 프레임의 실제 데이터가 들어가 있는 청크


참고 문서

https://mineeeee.tistory.com/m/entry/PNG-파일구조
https://yooniia.tistory.com/m/48
https://bgm2020.tistory.com/5
https://ko.m.wikipedia.org/wiki/PNG
https://m.blog.naver.com/PostView.naver?blogId=gnsehfvlr&logNo=220733132744&proxyReferer=&noTrackingCode=true
https://www.w3.org/TR/PNG-Chunks.html

[HackThisSite.org] Steganography 1 문제풀이

사진 1 : 문제 기계(bing)번역

기계번역된 문제내용을 정리하자면 문제파일(사진)안에 인코딩 된 메시지가 있고 찾는 힌트는 2개의 NULL 바이트라고한다.

winhex를 실행시키고 ctrl + alt + x로 Hex 검색창을 띄운 후 NULL값 (00 00)을 검색 후 f3로 넘기면서 값을 살펴보던 중 00 00 으로 둘러 쌓인 문자열을 발견 하였다.

사진 2 : 00 00 으로 둘러싸인 값

2진수이거나 모스부호 일 것 같은 느낌이 들었다. 하지만 모스부호라면 중간중간에 구별이 가능하게 띄어쓰기가 있어나 표시가 되어있는데 그런 흔적들이 없어서 아닌 것 같았다.

16을 0 17을 1로 치환해서 2진수로 변환 하였다

사진 3 : 변환 된 값

변환된 값을 2진 변환기에 넣으면 쉽게 flag가 나올 줄 알았는데 에러가 발생하였다.

사진 4 : 변환 오류

문자열이 잘못 되었나 8자리씩 끊어서 보니 어디서 하나가 부족한 상태였다…

00111000
01100110
01101110
11010000
11000010
11100110
0110110
표 1 : 2%부족한 …..

각 줄 앞에 0과 1을 하나씩 넣어보면서 때려 맞추기를 하고 있었는데 2번째 줄에 0을 추가하고 줄을 다시 정리하니 정상적으로 변환이 되는 것을 확인하였다.

사진 5 : 플래그!

플래그 값을 넣으면 클리어와 동시에 아래와 같이 다음 문제를 풀 수 있는 버튼이 만들어진다!

사진 6: 클리어!

[HackThisSite.org] Forensic 3 문제풀이

사진 1 : 문제전문(bing기계번역 버전)

문제 내용을 요약하자면 피자를 제조하는 것이 중범죄인 어떤한 주에서 피자를 제조한 혐의로 체포된 용의자가 가진 USB를 회수하였고 해당 USB안에서 피자를 만들었다는 증거가 있는지 찾아내는 문제인 것 같다.

문제파일을 받고 압축을 풀면 8개의 파일을 확인 할 수 있다.

사진 2 : 8개의 파일

8개의 파일들의 용량을 각각 확인해보니 shh.jpg 파일이 약 10MB로 해상도에 비해 비정상적으로 커서 수상해 보였다.

사진 3 : shh.jpg 파일

shh.jpg 파일을 winhex 열어서 있을거 같은 파일 형식을 선택 후에 카빙을 진행하였다.

사진 4: winhex 카빙
사진 5 : 카빙 결과

카빙 한 파일들의 용량 총합이 36.6KB으로 제대로 카빙이 되지 않은 것으로 추정된다. 직접 수동으로 파일을 찾아보기로 하였다.

우선 카빙된 000001.jpg 파일의 영역을 잘라내려고 하니 jpg파일의 푸터 뒤에 rar 압축파일의 시그니처와 비슷해 보이는 문자열을 발견하게 되었다.

사진 6 : rar 파일의 시그니처는 52 61 72 21 1A 07 00!

000001.jpg 의 영역을 지운 후 5A 를 52로 수정한 후 7zip으로 압축 풀기를 시도 하였다.

사진 7,8 : 시그니처 수정 및 압축해제

암호를 입력하라는 창이 뜨는데 앞에서 카빙할때 나온 000002.jpg 파일에 적혀있는 GL0zMe를 입력하니 암호가 정상적으로 해제되었다.

사진 9 : 수많은 피자 사진들

압축 해제된 파일들을 보니 수많은 피자 사진들 중에서 한개의 txt파일 보이는데 이 파일을 열면 이번 문제의 flag가 적혀있다.

사진 10 : flag

[HackThisSite.org] Forensic 2 문제풀이

사진 1 : 기계번역(bing) 전문

문제 내용을 정리하자면 어떤 의뢰인이 다른 사람과 바람을 피운 혐의로 기소가 되었다고 한다.

다른 여성과 같이 찍은 사진이 증거로 제출되었는데 의뢰인은 해당사진은 셀카였으며 해당 사진이 합성되었다고 주장하는 중이다.

해당사진이 합성사진인 것을 증명하면 되는 문제로 추정된다.

문제에는 저렇게 쓰여 있어도 스테가노그래피일 가능성이 있어서 우선 스테가노그래피인지 확인해보았다.

사진 2 : gimp 색감,레벨 기타 등 변형 사진

gimp를 이용하여 색상 레벨도 바꿔보고 채도도 바꾸어 봤는데 플래그는 보이지 않았다.

푸터 뒤에 문자로 존재하는 경우도 종종 있기에 winhex로 바이너리 값을 보기로 하였다.

사진 3 : 포토샵 사용흔적

숨겨진 메시지는 발견하지 못하였으나 해당 사진이 어도비 포토샵을 사용한 흔적은 발견 할 수 있었다.

하지만 저 문자열만으로는 해당 사진이 포토샵으로 단순 보정을 했는지, 합성을 했는지 할 수는 없다.

어떻게 하면 합성 사진으로 증명 할 수 있을지 구글링을 하던 중 jpg와 같은 손실 압축 사진 파일들은 ELA(Error Level Analysis) 분석을 통하여 사진의 합성 유무를 확인 할 수 있다는 것을 알게 되었다.

ELA(Error Level Analysis) 분석으로 압축수준이 다른 정도를 확인 할 수 있는데 압축수준이 특정 한곳만 지나치게 다른 경우에는 합성 사진일 가능성이 높다.

ELA 분석을 해주는 소프트웨어도 있고 웹사이트도 있는데 필자는 https://29a.ch/photo-forensics/#error-level-analysis 에서 진행하였다.

사진 4 : ELA 분석 사진

ELA 분석을 한 결과 여성쪽만 균일하지 않게 노이즈가 발생하는 것을 확인 할 수 있다.

이것으로 해당 사진이 합성 사진임을 증명 할 수 있게 되었고 좌상단에 flag로 추정되는 문자열도 얻을 수 있다.

사진 5 : 클리어!

플래그 값이 ELA4LIFE!! 인지 ELAALIFE!! 인지 해상도가 낮아 구별이 안되는 작은 이슈가 있는데, 그냥 둘다 제출해보니 ELA4LIFE!!가 플래그였다.

[HackThisSite.org] Forensic 1 문제풀이

사진 1 : 문제전문(bing기계번역 버전)

기계번역 된 문장들을 정리해보자면 최근에 전 직원과 마찰이 있었는데 그가 USB에 있는 파일을 날려버렸고 파일 복구를 하기 위해 USB 이미징을 진행한듯 하다.

이미징 파일을 받아서 USB안에 있는 암호파일을 구하면 되는 문제인 것으로 추정된다.

첨부파일을 받고 본격적으로 문제를 풀기전에 이미지 파일이 제대로 받아졌는지 무결성 검사를 진행한다.

사진 2: 무결성 검사

해쉬값이 문제에 적힌 값과 같아서 바로 문제 풀이에 들어갔다.

압축을 풀면 image.dd 파일이 나오는데 해당 파일을 ftk imager로 불러와준다.

사진3 : Trash-1000 폴더

.Trash-1000 폴더(휴지통 폴더) 안으로 들어간 후 expunged 폴더로 들어가면 삭제된 파일 리스트들이 나온다.

파일을 둘러보면 고양이 사진, 산맥 사진 등등 평범한 사진들이 대부분인데 딱 한폴더가 수상하게 선정성(?)이 높은 사진 한장과 압축파일 들어 있다.

사진4 : 수상한(?) 폴더

해당 폴더에 있는 압축파일을 풀면 flag가 나올 것 같았으나… 압축파일이 암호로 잠겨있다…

사진 5 : 암호화된 압축파일

어디에 암호가 숨겨져 있는지 폴더를 이리저리 뒤져가며 확인하던 중 음성 파일과 pdf문서, docx 문서들을 발견했다.

사진 6 : 문서&음성 파일 리스트

voicemail 1.wav 파일을 실행시켜서 소리를 들어보면 8초 정도의 짧은 대화가 나온다.

대화 내용을 해석하자면 핸드폰 번호로 어떤 파일의 암호를 해제 할 수 있는다는 내용 같았다.

여러 문서들을 살펴보던 중 Termination – Allen Smith.docx 해당 파일에서 핸드폰 번호를 찾을 수 있었다.

사진 7 : 휴대폰 번호

핸드폰 번호를 압축파일에 넣었는데 압축이 안풀렸다…. 혹시나 싶어서 -를 빼고 다시 해보니 압축이 풀렸다!

압축을 풀면 flag값이 적힌 docx파일을 확인 할 수 있다! 플래그를 제출하면 끝!

사진 8 : flag
사진 9 : 클리어!

윈도우 계열 OS에서 디스크 쓰기 방지 설정(레지스트리)

디지털 포렌식 5대 원칙 중 하나인 무결성을 유지하면서 디지털 포렌식을 진행하려면 디스크 쓰기 방지 조치를 해야한다.

이번 글에서는 레지스트리를 편집하여 논리적으로 디스크 쓰기 방지 설정하는 방법을 작성하였다.

레지스트리 편집

Win + r -> regedit 입력 후 엔터

아래 레지스트리 주소로 들어간다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies

만약 해당 경로가 존재 하지 않을 경우 Control에서 우클릭 -> 새로만들기 -> 키 -> StorageDevicePolicies 입력을 하여 경로를 만들어 준다.

해당 주소에 들어온 후 우클릭 -> 새로만들기 -> DWORD(32비트) 값 -> WriteProtect 생성

단위는 16진수로 설정 , 값 데이터가 0일 경우 쓰기 가능, 1일 경우 쓰기 불가

위 설정을 1로 변경하고 평범한 방식으로 증거 매체를 수정 하려면 쓰기 금지가 되어 무결성 확보 할 수 있다.

다만, winhex 등 16진수 편집기를 이용하여 수정을 시도 할 경우는 수정이 가능하기에 논리적인 쓰기 방지 기능은 증거 매체 이미징용 으로만 사용할 것을 권장한다.

만약 불가피하게 원본으로 작업을 해야하는 상황에서는 쓰기 방지 장치 하드웨어를 사용하여야 무결성을 보장 할 수 있다.

MP4 파일 구조 정리 (1)

MP4(MPEG-4 part 14)

비디오 및 오디오 스트림을 저장하는 동영상 포맷이며, ISOBMFF(ISO Base Media File Format)으로 정의된다.

ISOBMFF

  • ISO가 개발
  • 포맷 종류 : Media Container
  • QuickTime(.Mov)로 부터 확장
  • ISOBMFF의 대표적인 확장 포맷 (mp4, 3gp, 3g2, mj2, dub, dcf …..)

MP4 파일은 3가지의 구조적인 특징을 가진다.

logical structure (논리적 구조) : 시간과 관련된 병렬적인 트랙(audio, video)로 구성됨

time structure (시간적 구조): 각 track은 시간에 따른 sample sequence로 이루어짐

physical structure (물리적 구조) : 모든 데이터는 box라 불리는 형태로 저장됨


MP4 파일 아키텍쳐 구조

사진 1 : 대략적인 mp4 파일 구조

file

  • moive 트랙에 시간 데이터를 저장
  • time과 관련 없는 데이터를 저장
  • 간혹 위 두 가지 모두를 저장 할 때도 있다
  • 동기와를 위한 common timeline을 정의

Track

  • 특정 미디어 유형(코덱)에 해당
  • 단일 디코더에 연결되어 있음 (확장 가능 한 코덱 제외)
  • 다른 트랙에 연결 하거나 그룹화 또는 다른 트랙으로 대체 가능
  • item에 있는 untimed data와 관련이 있을 수 있음
  • 암호화 될 수 있음
  • sample로 분해됨

Sample

  • 지정된 시간 (DTS, CTS)에 디코더가 사용하는 연속데이터를 나타냄
  • 속성(크기,위치,랜덤 엑세스, 디코더 configuration)가 저장되어 있다.
  • Sub-Sample의 관점에서 표현 될 수도 있다.
  • Sample Group 내의 다른 비슷한 Sample과 연관이 있을 수도 있다.
  • 샘플별 보조 정보가 존재 할 수도 있다.

Item

  • Movie 전체에 대해 사용되는 Data를 나타냄
  • Type, Position, size 등과 같은 속성을 가짐
  • 암호화 되어있거나, 압축화 되어있어서 확인이 어려울 수 있음

physical structure (물리적 구조)

MP4 파일에서 모든 데이터는 Box(박스)라고 불리는 구조로 저장되어 있다. 각 박스는 length, type(4바이트), Version, flag, data를 저장한다.

사진 2. 박스 구조도

Extensible format(확장 형식)

  • 잘 알려지지 않은 Box는 생략 할 수 있다.
  • Header 정보는 Box의 계층 구조이다.
  • Media data는 Header와 동일한 파일 Box(주로 ‘mdat’ 또는 ‘idat’)에 구조화되지 않고 저장되거나 별도의 파일에 저장 될 수 있다.

MP4 파일의 일반적인 구조

위에서 소개한 여러 Box들이 모여 MP4 파일은 계층적 구조를 가진다.

사진 3. mp4 Box tree

FTYP

  • filetype의 약자로, i per file, File type, File version, 다른 ISO file 과의 호환성을 알려주는 박스

Moov(moive)

  • Presentaion(표현)과 관련된 MetaDate를 위한 Unique Container (고유 컨테이너)

mvhd(moive Hedear) : movie에 대한 일반적인 정보를 가진 박스

trak(track) : 하나의 steam과 연관된 metadata container

tkhd(track header) : track에 대한 전반적인 정보를 가지고 있는 박스

mdia(media information) : track안의 media imformation에 대한 container

mdhd(media header) : media에 대한 전반적인 정보를 가지고 있음

minf(media information container) : 미디어 정보 컨테이너

vmhd(video media header) : 비디오 미디어 헤더 박스

dinf/dref(Data information/Data Reference) : data의 위치를 나타내는 박스

stbl(Sample Table) : Sample과 관련된 Meta 데이터를 가짐

stsd(sample Description) : Sample Decoder configuration 정보

stts(time to sample) : 샘플의 시간 정보

ctts(composition time to sample) : 샘플링 시간

stsc(sample to chkunk) : partial data-offset information (파티션 데이터 오프셋 정보)

hdlr(Handler) : stream의 타입을 의미

tref(track reference container) : 추적 참조 컨테이너

mdat(media Data) : media data를 가지는 박스


아래에 첨부된 온라인 mp4 parser 도구를 이용하면 위에서 설명한 것과 유사한 파일 구조를 볼 수 있다.

사진4. 분석 사진

다음 2편에서는 각 박스들의 16진수 값들에 대해 작성해보기로 마음 먹으며 글을 마친다.

참고문헌 :

MPEG-4 파일의 구조 개괄 :: 개똥이야기 (tistory.com)

[MP4] 분석 하기 | MPEG-4 파트 14 | MP4Box 설치 (tistory.com)

MP4 파일 구조 – Studying Programming (revol300.github.io)

mp4파일 시스템 구조, mp4파일 구조 : 네이버 블로그 (naver.com)

mp4파일 시스템 구조, mp4파일 구조 : 네이버 블로그 (naver.com)

비디오 – Digital Forensic Wikipedia (korea.ac.kr)

MP4 file format – Wikipedia

사용된 도구

Online Mp4 Parser

첨부파일

X-ways imager 구매 후기

X-ways imager는 독일의 X-ways 사에서 만든 디스크 이미징 디지털 포렌식 도구 이다.

이름답게 이미징과 관련된 기능 말고는 아무런 기능이 없고 매우 가볍게 설계된 도구이다

사진 1. 실행 화면

구매 가격은 이런저런 수수료와 세금을 포함하여 122,100원 구매를 하게 되었다. 조금 저렴하게 사는 팁을 주자면 X-Ways 계열 프로그램을은 정품인증용 동글 usb가 필수 인데, 자신이 가지고 있는 USB를 동글로 변환하면 동글 값을 빼고 조금 저렴하게 구매 할 수 있다.

사진 2. 결제 영수증

개인적인 평가를 하자면 같은 회사에서 나온 WinHex와는 달리 X-Ways Imager는 별로 였다.

무료 도구인 FTK imager에도 있는 이미지 파일 내 파일 리스트 출력이나, 삭제된 파일 확인,디스크 이미지 마운트 등등 유용한 기능들이 있지만 X-Ways imager는 1년에 12만원 정도의 돈을 받으면서 이러한 기능이 존재 하지 않았고, 오로지 디스크를 이미징 하는 기능과 잘 작동하지 않는 RAID 복구 기능, 총 2가지가 X-Ways imager 의 모든 기능이였다.

그나마 장점을 뽑으라 한다면 FTK imager(130MB) 이미징 툴은 몇 백메가의 용량을 자랑하는 방면, X-Ways imager는 47MB의 가벼운 용량을 가졌고, 램과 cpu도 다른 툴에 비해 적게 먹었다.

또한 플라시보 효과인지는 모르겠지만, 다른 이미징 툴에 비하여 이미징 속도가 조금 빨랐고 느껴졌다.

총 정리하자면 X-Ways imager는 이미징 말고는 아무런 기능이 없으므로 디지털 포렌식을 공부하려는 학생분들에게는 구매하는 것을 비추천한다.

괜한 모험심이 들어서 필자처럼 돈 낭비 하지 말고 차라리 FTK imager를 이용하는 편이 경제적이나, 포렌식을 공부하는데나 도움이 될 것 같다는 생각을 적으며 글을 마친다.

WinHex personal 구매 방법 & 후기

디지털 포렌식을 공부 할 때 파일을 Hex로 보기 위해 무료 도구인 HxD를 주로 사용하였다.

HxD로도 만족하였으나, 편리한 기능이 적어서 CTF 등 시간이 제한된 특수한 상황에서 여러가지 삽질들을(스테가노그래피, 파일시스템 복구 등등) 100% 수동으로 해야 해서 시간을 많이 잡아먹는 단점이 있었다.

이러한 단점을 해소하고자 큰 마음을 먹고 WinHex를 구매하게 되었다.

구매하는 방법은 (https://www.x-ways.net/order.html)에 방문해서 해외직구로 쇼핑 하듯 자신이 원하는 라이센스를 고르고 주소와 카드번호를 넣고 결제하면 된다.

필자는 personal license, perpetual 53,000원 라이센스를 구매하였다(카드 수수료 등이 포함되어 실구매가는 6만원이였다.)

그럼 약 5분 뒤 6줄로 되어있는 라이센스 키가 메일로 온다.

winhex를 다운 받은 뒤 Help -> register -> 6줄 라이센스 키 입력-> OK 순서대로하면 정품 인증이 완료된다.

winhex는 프로그램에 제 이름과 집주소도 적어주는게 마음에 들었다.

당분간 여러 기능들을 이리저리 써보면서 CTF에서 어떻게 활용할지 연구해봐야겠다