일단 tunn3l v1s10n 문제의 파일 다운로드 시작
다운받으면 파일이
이런 식으로 확장자도 없고 단순히 문서라고 되어 있는 것을 알 수 있다.
이 파일의 확장자를 알기 위해서 일단 터미널에서 시도 해보자.
xxd tunn3l_v1s10n | head -5열어 보면
00000000: 424d 8e26 2c00 0000 0000 bad0 0000 bad0 BM.&,...........
00000010: 0000 6e04 0000 3201 0000 0100 1800 0000 ..n...2.........
00000020: 0000 5826 2c00 2516 0000 2516 0000 0000 ..X&,.%...%.....
00000030: 0000 0000 0000 231a 1727 1e1b 2920 1d2a ......#..'..) .*
00000040: 211e 261d 1a31 2825 352c 2933 2a27 382f !.&..1(%5,)3*'8/
이런 식으로 무엇인지 모르겟는데 싶은데 이럴 경우에는 https://en.wikipedia.org/wiki/List_of_file_signatures 에 들어가서 맨 처음 4글자인 42 4d를 검색해보면 바로 bmp 파일임을 알 수도 있고,
brew install exiftool명령어로 설치해서 해당 파일을 열어보면
이런 식으로 해당 파일에 대한 정보를 알 수 있다.
이 파일은 타입이 bmp이고, bit 깊이 및 이미지 가로, 세로 길이까지도 알 수 있다.
tunn3l v1s10n 파일에 확장자인 bmp를 넣고 열어보자!
아 여전히 파일이 안 열린다.
이 파일은 왜 열리지 않는걸까?
이럴 때는 AI 도움도 더 받아본다.
(별로 공부하지 않은 분야임으로 더듬더듬 일단 해본다.)
파일 bmp 데이터가 잘못되어 있어서 안열리는 것 같다. 이런 데이터를 수정하기 위해서 아래 명령어를 다운받고 해당 파일을 열어보자
brew install hexedit
hexedit tunn3l_v1s10n.bmp해당 파일을 일단 열어보면
이런 식으로 나오고 뭔가 뭔지 잘 모르겠다.
이럴 때는 일반적인 bmp 파일 데이터와 비교해보자
첫 줄에 보면 36과 28 빼면 나머지는 다 0인데, 기존 tunn3l_v1s10n 파일의 경우에는 BA DO 두 개가 반복되어서 살짝 이상함이 느껴진다.
게다가 bmp 파일의 경우에는 파일 데이터 포맷을 살펴보면 0xA이 DataOffset이 시작된다.
위키에서도 살펴보면 DataOffset의 경우에는 해당 파일의 크기가 4byte밖에 되지 않는다.
그럼 이미지에 표시한대로 BA DO 00 00 이 부분이 크기가 올바른지를 알아 보자. 참고로 비트맵의 케이스 같은 경우 리틀 엔디엔 형식을 쓰고 있으므로 그대로 읽으면 안되고 00 00 DO BA와 같이 무조건 반대로 읽어야 한다.
위키에서 보면 비트맵 파일 헤더는 14byte로 명시되어 있으며, 비트맵 인포 헤더는 40byte로 명시되어 있다. 그렇게 되면 DataOffset에 명시되어야 할 바이트 total, 54 byte라는 말이 된다.
00 00 DO BA이 얼마인지 계산해보면
앞에 '0' 4개는 아무리 계산해도 0임으로 제외하고
D0 BA는 우선 16진수에서 A=10, B=11, C=12, D=13, E=14, F=15
에 해당하므로
D는 13에 해당하고, 16진수에서 3번째자리에 있으므로 계산식으로는 16의 3제곱 X 13
0는 0에 해당하고, 16진수에서 2번째자리에 있지만 0은 아무리 곱해도 0임으로 계산 제외
B는 11에 해당하고, 16진수에서 첫번째자리에 있으므로 계산식으로는 16 X 11
A는 10에 해당하고, 16진수에서 0번째자리에 있으므로 계산식으로는 1 X 10
이렇게 됐을 때 총체적으로 계산을 해보면
(16 X 16 X 16 X 13) + (16 X 11) + (1 X 10) = 53,434임으로 54 바이트에서는 한참 벗어나 있는 것을 알 수 있다.
그럼 아까 봤던 일반적인 bmp 파일 데이터에서 있던 36 00 00 00 을 계산해보자.
리틀 엔디엔으로 하게 되면 00 00 00 36이 되고,
여기서도 앞에 '0' 6개는 아무리 계산해도 0임으로 일단 제외
36은 우선 16진수에서
3는 3에 해당하고, 16진수에서 첫번째자리에 있으므로 계산식으로는 16 X 3
6는 10에 해당하고, 16진수에서 0번째자리에 있으므로 계산식으로는 1 X 6
이렇게 됐을 때 총체적으로 계산을 해보면
(16 X 3) + (1 X 6) = 54임으로 36 00 00 00이 딱 54바이트에 알맞다는 것을 알 수 있다.
음, 36 00 00 00로 고쳐서 열어봐도 역시 똑같이 열리지 않는다.
아까 봤던 부분 중에 또 달랐던 부분이
이 부분이다. 여기 부분은 0E 부분으로 비트맵 인포 헤더에서 사이즈에 해당한다.
역시 해당 크기는 4바이트 임으로 노란색 부분에 해당한다.
아까 말한대로 비트맵 인포 헤더는 크기가 40 byte임으로 저 노란색 부분에 40 byte라고 명시해야 한다.
첫번째 계산했던 내용과 여기의 크기가 똑같으므로, 53,434의 크기는 올바르지 않다.
그럼 아까 봤던 00 00 00 28은 몇 바이트인지 알아보자!
리틀 엔디엔으로 하게 되면 00 00 00 28이 되고,
여기서도 앞에 '0' 6개는 아무리 계산해도 0임으로 일단 제외
28은 우선 16진수에서
2는 2에 해당하고, 16진수에서 첫번째자리에 있으므로 계산식으로는 16 X 2
8는 10에 해당하고, 16진수에서 0번째자리에 있으므로 계산식으로는 1 X 8
이렇게 됐을 때 총체적으로 계산을 해보면
(16 X 2) + (1 X 8) = 40임으로 28 00 00 00이 딱 40바이트에 알맞다는 것을 알 수 있다.
음, 28 00 00 00로 고쳐서 열어보면 열리긴 열리는데 좀 뭔가 이상하다.
아, 이미지가 짤린 것 같다.
사이즈 설정이 잘못된 거 같다.
비트맵의 예상 사이즈는 아래와 같은데,
너비 × 높이 × (비트깊이 ÷ 8) = 예상 이미지 크기다시 아까 위에 올렸던 파일 정보를 확인해보자.
현재 파일의 크기는 2.9MB이고, bit Depth는 24이며, 너비는 1134, 높이는 306
1134 × 306 × (24 ÷ 8) = 1,041,012(바이트) = 약 1MB2.9MB와는 맞지 않는다.
아까 열린 이미지를 봤을 때는 가로 길이는 1000이 넘어서, 부족해보는 Hegiht를 늘려보자
2.9MB는 바이트로 2.9 × 1024 × 1024 = 3,040,870 바이트에 해당한다. 그러므로
3,040,870 ÷ (3 × 1134) = 약 893높이는 893을 넣으면 제대로된 이미지의 크기가 나올 것으로 보인다.
해당 데이터에서 보면 오프셋은 16에서 시작한다는 걸 알 수 있다.
다만, 해당 숫자인 893을 그대로 넣을 수는 없기 때문에
이걸 16진수로 변환할 것이다.
893 ÷ 16 = 나눗몫 55, 나머지 13
55 ÷ 16 = 나눗몫 3, 나머지는 73은 더이상 나눌몫이 없으므로 나눗몫인 3을 포함하여 아래부터 위로 나머지를 나열하게 되면 3, 7, 13 이 나온다. 13은 16진수에서 D이니까 03 7D가 나오고 리틀 엔디엔 형식때문에 반대로 7D 03 00 00 바꿔서 넣는다.
그렇게 되면 원하는 답이 나올 것이다.
상단에 있는 정답을 넣으면 문제 해결!
