QR Code에 빨간색으로 낙서가 되어있어 제대로 인식하지 못하고 있습니다. 



QR code에 구조를 알아보라는 문제같습니다. 


빨간색으로 칠해져 있는 부분은 "위치 찾기 심볼" 이라고 부르며 360도 어느 방향에서든 인식할 수 있게 만들어 놓은 곳입니다.


하지만 지금 해당 구역이 오염되어 있어 정확한 값을 찾을 수 없게 되는 것입니다.


"Fix it!" 고치라고 한 내용은 해당 부분을 올바르게 만들어서 인식할 수 있게 만들라는 내용입니다.



Google에 검색해서 아무 qr코드를 가져와 "위치 찾기 심볼" 부분을 캡처하여 그림판으로 모양을 잘 잡아줍니다.


https://webqr.com/index.html 과 같은 사이트에 업로드하여 확인해 보면 됩니다.


하지만 Error가 발생하고 인식을 하지 못하게 됩니다.


빨간 부분으로 더럽혀 있어서 그런거 같으니 해당 부분도 지워줍니다.



수작업으로 하나하나 하얗게 칠하면 조금 지저분하지만 QR code를 인식하기에는 문제가 없습니다.


해당 파일로 업로드하면 올바른 인증키 값을 얻을 수 있습니다.




흔히 쓰는 QR코드가 어떻게 작동하는지 알아보게 하려는 문제였습니다.


따로 정리할 필요가 있겠네요.


[참고]

http://www.qrcode.com/ko/about/

'WarGame > SuNiNaTaS' 카테고리의 다른 글

SuNiNaTaS_5 [WEB]  (0) 2018.09.13
SuNiNaTaS_31 [FORENSIC]  (0) 2018.09.13
SuNiNaTaS_28 [FORENSIC]  (0) 2018.09.12
SuNiNaTaS_13 [MISC]  (0) 2018.09.11
SuNiNaTaS_11 [BINARY]  (0) 2018.09.09

쉽다고..!?



파일을 받으면 다음과 같이 확장자를 알 수 없는 파일이 하나 생기게 됩니다.



HxD로 확인해보면 앞에 시작부분이 PK인걸 보아하니 ZIP파일임을 눈치챌 수 있고 해당 파일에 확장자를 추가해줍니다.



확장자를 추가하고 열어보니 암호가 걸려있고 암호에 대한 힌트는 조금도 존재하지 않습니다....


여기서 진짜 막막했습니다 ㅜ



이 문제는 알집 Header에 관한 문제였습니다.


아래와 같이 zip파일은 다양한 파일을 하나로 모아주는 역할을 합니다.


파일마다 각각의 "Local header"가 존재하고 마지막에는 "Central directory"에 파일의 정보를 다시 작성합니다.


[출처: 위키피디아]



zip파일의 헤더 항목 중에 "General purpose bit flag"라는 항목이 있습니다. (2byte)


아래와 같은 정보를 담고 있는 값입니다. 그중 첫번째 bit는 암호 유무를 판단하는 bit 값입니다.


이 값이 설정되어 있으면 해당 zip파일은 암호화 되어 있다고 판단하게 됩니다.


        Bit 0: If set, indicates that the file is encrypted.


        (For Method 6 - Imploding)

        Bit 1: If the compression method used was type 6,

               Imploding, then this bit, if set, indicates

               an 8K sliding dictionary was used.  If clear,

               then a 4K sliding dictionary was used.


        Bit 2: If the compression method used was type 6,

               Imploding, then this bit, if set, indicates

               3 Shannon-Fano trees were used to encode the

               sliding dictionary output.  If clear, then 2

               Shannon-Fano trees were used.


        (For Methods 8 and 9 - Deflating)

        Bit 2  Bit 1

          0      0    Normal (-en) compression option was used.

          0      1    Maximum (-exx/-ex) compression option was used.

          1      0    Fast (-ef) compression option was used.

          1      1    Super Fast (-es) compression option was used.


        (For Method 14 - LZMA)

        Bit 1: If the compression method used was type 14,

               LZMA, then this bit, if set, indicates

               an end-of-stream (EOS) marker is used to

               mark the end of the compressed data stream.

               If clear, then an EOS marker is not present

               and the compressed data size must be known

               to extract.


        Note:  Bits 1 and 2 are undefined if the compression

               method is any other.


        Bit 3: If this bit is set, the fields crc-32, compressed 

               size and uncompressed size are set to zero in the 

               local header.  The correct values are put in the 

               data descriptor immediately following the compressed

               data.  (Note: PKZIP version 2.04g for DOS only 

               recognizes this bit for method 8 compression, newer 

               versions of PKZIP recognize this bit for any 

               compression method.)


        Bit 4: Reserved for use with method 8, for enhanced

               deflating. 


        Bit 5: If this bit is set, this indicates that the file is 

               compressed patched data.  (Note: Requires PKZIP 

               version 2.70 or greater)


        Bit 6: Strong encryption.  If this bit is set, you MUST

               set the version needed to extract value to at least

               50 and you MUST also set bit 0.  If AES encryption

               is used, the version needed to extract value MUST 

               be at least 51. See the section describing the Strong

               Encryption Specification for details.  Refer to the 

               section in this document entitled "Incorporating PKWARE 

               Proprietary Technology into Your Product" for more 

               information.


        Bit 7: Currently unused.


        Bit 8: Currently unused.


        Bit 9: Currently unused.


        Bit 10: Currently unused.


        Bit 11: Language encoding flag (EFS).  If this bit is set,

                the filename and comment fields for this file

                MUST be encoded using UTF-8. (see APPENDIX D)


        Bit 12: Reserved by PKWARE for enhanced compression.


        Bit 13: Set when encrypting the Central Directory to indicate 

                selected data values in the Local Header are masked to

                hide their actual values.  See the section describing 

                the Strong Encryption Specification for details.  Refer

                to the section in this document entitled "Incorporating 

                PKWARE Proprietary Technology into Your Product" for 

                more information.


        Bit 14: Reserved by PKWARE.


        Bit 15: Reserved by PKWARE. 


다음과 같이 "Local" 과 "Central directory"의 "General purpose bit flag"의 위치가 살짝 다르다는 것을 알아야 합니다.


Local Header

 Central directory file header

4Byte: Local file header signature

2Byte: Version needed to extract

2Byte: General purpose bit flag

4Byte: Local file header signature

2Byte: Version made by

2Byte: Version needed to extract

2Byte: General purpose bit flag



이것을 알고 문제로 가보면 아래와 같이 "09 08"로 되어있는 부분을 확인 할 수 있습니다.


리틀엔디안 방식을 쓰기때문에 bit값을 확인할때는 08 09 → 1000 1001 로 아셔야 합니다.


첫번째 bit가 1로 되어있어 해당 파일이 암호화 됬다고 나타나고 있습니다. 이 값을 0으로 바꾸려면


"08 08" 로 수정하시면 됩니다. 모든 "General purpose bit flag" 값을 수정해 주시면 해당 파일이 깔끔하게 열리게 됩니다.



두개의 txt파일은 "Dummy"라는 무수한 글자로 채워져 있었고, 실제 zip파일에 txt가 필요했던 겁니다.


해당 인증값으로 인증해도 안되는데 base64로 인코딩 되어있는 거 같아 decode하고 인증하면 성공하게 됩니다.



[참고]

Zip (file format): https://en.wikipedia.org/wiki/Zip_(file_format)

Zip 압축파일 헤더 구조: http://downrg.com/403

Zip파일 헤더 구조: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT



[여담]

이 문제는 암호 자체가 없던 파일입니다.

직접 다른 암호화된 zip파일을 만들고 해당 bit값만 조작해보면 압축파일이 손상되어 있다고 나오니 주의하시기 바랍니다.

'WarGame > SuNiNaTaS' 카테고리의 다른 글

SuNiNaTaS_31 [FORENSIC]  (0) 2018.09.13
SuNiNaTaS_17 [MISC]  (0) 2018.09.12
SuNiNaTaS_13 [MISC]  (0) 2018.09.11
SuNiNaTaS_11 [BINARY]  (0) 2018.09.09
SuNiNaTaS_10 [BINARY]  (0) 2018.09.08

"KEY Finding"이라는 글자만 덩그러니 나와있고...


<!-- Hint : 橇肺弊贰赣狼 肋给等 家胶归诀 嚼包 -->

<!-- Hint : The programmer's bad habit of backup source codes -->


주석을 보니 프로그래머의 나쁜 습관으로 백업파일이 있다는거 같은데..


저 위에 한자는 도대체 무슨 의미인지 모르겟네요..



아무튼 문제를 푸는데 URL창을 이용하셔야 합니다.


소스코드에는 아무런 단서가 없으니 소스코드에서 무언가를 해낼 수는 없으리라 보입니다.


백업파일이라고 했으니 .swp .zip .tar .. 이런 종류의 확장자가 생각나게 됩니다.


그래서 본 URL에 다음과 같이 다양하게 시도해 보았습니다.



   http://suninatas.com/Part_one/web13/web13.asp.swp

   http://suninatas.com/Part_one/web13/web13.asp.zip

   http://suninatas.com/Part_one/web13/web13.asp.tar



하지만 페이지 오류라고 나오고 실패하게 됩니다.

그러다 아래와 같이 "asp"를 지우고 해보니까 파일이 하나 다운로드가 되었습니다!


   http://suninatas.com/Part_one/web13/web13..zip


파일에는 다음과같이 암호가 걸려있으며 압축 비밀번호는 4자리 정수라고 나와있으니 


툴이나 알집 자체 기능을 이용해서 쉽게 알아낼 수 있을 것 같습니다.


최근 버전 알집에는 제공을 하고있지는 않고 7.13 버전까지는 지원이 되는거 같습니다.


저는 그래서 알집 버전을 다운그레이드시키고 사용해봤습니다.



4자리 정수라고 했으니 다음과같이 설정하면 2초만에 결과 같이 나오게 됩니다.


다음과 같이 4개의 사진과 1개의 txt파일이 나오게 됩니다.


txt 파일 내용은 4개의 사진에서 각각 키값을 찾아 모두 합치면 된다고 합니다.



HxD 툴을 이용해서 확인해보시면 바로 눈에보이게 키값을 알려줍니다. 









[뒷말]

橇肺弊贰赣狼 肋给等 家胶归诀 嚼包 

이 한자가 무슨의미인가해서 다른 분들 블로그를 가봤는데... 인코딩 문제였던건지 한글로 잘 나와있었네요..

진짜 저거 때문에 무슨말인지 몰라서... 엄청 해맸는데 ㅜ


[참고]

알집 7.13 암호찾기: http://need-jip.tistory.com/182

'WarGame > SuNiNaTaS' 카테고리의 다른 글

SuNiNaTaS_17 [MISC]  (0) 2018.09.12
SuNiNaTaS_28 [FORENSIC]  (0) 2018.09.12
SuNiNaTaS_11 [BINARY]  (0) 2018.09.09
SuNiNaTaS_10 [BINARY]  (0) 2018.09.08
SuNiNaTaS_4 [WEB]  (0) 2018.09.07

+ Recent posts