2. 둘째날
Zsh를 깔긴 깔았는데 이건뭐...화면이 별로 엣지가 없다. 색깔고 그냥 단색이고...아무튼 이상하다. .zshrc를 고쳐야 될것 같다. 일단 아래처럼 고치자.
$ vim ~/.zshrc
autoload -U compinit promptinit
compinit
promptinit
prompt walters
마지막줄이 walters라는 프롬프트로 설정해주는 줄이다. Zsh는 프롬프트 모양에 이름을 줘서 저장할 수 있다. 테마라고 하는데 기본적으로 몇개가 깔려있다. 아래처럼 입력하면 리스트를 볼 수 있다. -h 옵션을 주면 help가 나오니 나머지는 알아서 하자.
$ prompt -l
맘에 드는걸로 바꺼보고 몇가지 alias 를 추가해서 .zshrc를 고쳐보자. Key binding 그딴거는 엣지랑 별관계없으니...신경끄자.
autoload -U compinit promptinit
compinit
promptinit
prompt elite2 red
# alias setting
alias du='du -h'
alias df='df -h'
alias less='less -r'
alias ls='ls -hF --color=tty'
alias dir='ls --color=auto --format=vertical'
alias vdir='ls --color=auto --format=long'
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'
alias vi='vim '
alias vin='vim '
윈도우7은 정말이지 퍼팩트한 OS인데..한가지 단점이 있다면 CLI 쉘이 좀 불편해서 허세질하기에 적합하지 않다는 거라능. 시커먼 화면에 글씨들이 쫙 스크롤되면서 코딩하는 그런 허세 ㅋ. 아무튼 이런 허세질에는 리눅스가 좋다. 혹자는 맥 OSX를 쓰면 되지 않느냐고 반문하겠지만 앱등이 효과때문에 허세가 반감된다.
내가 좋아하는 우분투를(만화 우분츄때문에 좋아하는거 아님) 깔면 기본으로 Bash를 쉘로 사용한다. Bash에서 여러가지 CLI 유틸들을 쓰다보면 허세력이 막 상승하는데 어느순간 한계에 부딪친다. 이 시점에서 엣지있는 무언가가 필요하다. 엣Z있는 Zsh로 갈아탈 때가 온거라능.
Zsh 써보기 그 첫날이다.
1. 첫날
일단 apt-get으로 땡겨서 설치한다.
$ sudo apt-get install zsh
설치가 끝나면 zsh를 실행시켜본다. 뭐라뭐라고 막 나오는데 .zshrc를 만들어주면 담부터 안나온다.
$ touch ~/.zshrc
자기 계정의 기본 쉘을 zsh로 바꾼다.
$ sudo vim /etc/passwd
저장하고 로그아웃 했다가 다시 로그인한다. 아래처럼 입력해서 쉘을 확인한다.
$ echo $SHELL
zsh로 로그인됐다. >_<.
잘 분간은 안되겠지만 Zsh이다. 터미널 foreground 컬러가 녹색이라 시커먼고 파릇파릇한 화면이 나왔다능.
전편에서 ZIP의 전체 구조를 살펴봤다. ZIP파일은 n개의 Local file entry와 1개의 Central directory로 구성되어 있다능. Local file entry는 Local file header와 File data, Data descriptor로 구성되어 있다고 했따능. 일단 그림을 다시 한번 살펴보자능.
그림 4 Local File Entry
Local file header는 파일의 메타 데이터를 담고 있고 실제 데이터는 File data에 저장되어 있다. Data descriptor는 Local file header의 어떤 필드의 값에 의해서 있을 수도 있고 업ㅂ을 수도 있다. 각 섹션들이 어떤 필드들로 구성되어 있고, 각 필드 길이와 의미만 알면 그리 어렵지 않게 ZIP파일을 읽어낼 수 있다. 어떤 ZIP 파일의 local file entry를 통체로 들고 올태니 그걸 반찬삼아 각 섹션들을 분석해 보자능.
Local file header는 local file header signature로 시작한다. local file header signature의 값은 0x04034B50 인데, ZIP파일 포맷은 멀티 바이트 필드들은 little endian으로 저장하게 되어 있다. 따라서 눈으로 읽으면 순서가 거꾸로 뒤집힌 값을 보게 된다능. offset 0x0에서 나오는 50 4B 03 04 가 signature가 된다. 이런식으로 필드들을 해석하면 된다능. 역시 Local file header의 전체 구조를 살펴보고 이야기를 진행하자. 이제부터는 좀 지루한 내용이 될꺼라능.
Field
size
comment
local file header signature
4 bytes
0x04034b50
version needed to extract
2 bytes
general purpose bit flag
2 bytes
compression method
2 bytes
last mod file time
2 bytes
last mod file date
2 bytes
crc-32
4 bytes
compressed size
4 bytes
uncompressed size
4 bytes
file name length
2 bytes
extra filed length
2 bytes
file name
variable size
extra filed
variable size
표 1 Local file header
필드가 참...빌어도 못 먹을 만큼 많다. compressed size와 같이 직관적으로 의미도 알 수 있고 해석도 가능할 것 같은 것도 있고 general purpose bit flag 처럼 정체 불명인 것도 있다. 파일의 내용만을 복구할 거라면 compression method하고 file name만 가지고도 충분하지만...위에서 설명한 local file header signature를 제외한 12 필드의 의미를 다 살펴보고 넘어가자능.
앞 쳅터에서 우리는 ZIP 파일 포맷을 하향식으로 살펴본다고 했다. 모르는 사람은 업ㅂ겠지만 하향식 (Top-Down)으로 살펴본다는 말은 최상위 구조를 먼저 파악한 후 디테일한 내용은 나중에 설명하겠다는 말이다. 그래서 이번 쳅터에서 설명할 ZIP 파일 포맷의 전체 구조는 뒤에 오는 내용들을 가늠하게 될 중요한 내용이다. 최상위 레벨에서 바라 보았을 때 ZIP 파일의 구조는 심플하기 짝이 업ㅂ으니 일단 가벼운 맘으로 시작하자능.
ZIP 파일의 전체 구조는 위의 그림처럼 생겼다. 자질구레한 섹션들은 삭제하고 굵직굵직한 섹션만 포함시켰을 때 위와 같은 모습이 된다. 복수의 Local File Entry와 하나의 Central Directory로 구성되어 있다. 저것만 알아도 ZIP파일의 Hex 덤프를 보고 내용을 어떤 파일들이 압축되어 있는지 내용을 파악할 수 있다.
Local File Entry가 어떻게 생겼는지 구조만 살펴보고 넘어가보자. 자세한 내용들은 다음 쳅터에서 설명하기로 했으니 우리는 그림만 살펴보고 넘어가자.
점선으로 표시한 Data Descriptor는 Local File Header의 내용에 따라 있을 수도 있고 업ㅂ을 수도 있다. 짐작은 하겠지만 Local File Header에 파일 이름이나 뭐 이런 정보가 저장돼있고 File Data에 실제 파일의 내용이 압축된 상태로 저장돼 있다. Local File은 Local File Header와 File Data의 내용만 멀쩡하다면 전체 ZIP 파일이 완전하지 않더라도 원본 파일로 복원할 수 있다. 우리가 받다 말은 ZIP파일의 내용을 훔쳐볼 수 있는 이유가 바로 이 때문이다.
Central Directory는 Local File Entry들의 메타 데이터를 담고 있다. 역시 자세한 내용은 뒤에서 다룰 테니 그림을 먼저 보자.
Central Directory의 File Header는 Local File Entry의 Local File Header와 매우 유사한 데이터를 담고 있다. 데이터가 중복 저장되는 이유는 이렇게 하면 Central Directory만 파싱하면 전체 ZIP 파일의 구조를 한번에 파악할 수 있기 때문이다. Central Directory를 파싱하면 한번에 모든 Local File의 메타 데이터를 획득할 수 있으니 꽤 중요하다고 할 수 있겠다. 이런 이유로 Central Directory의 File Header는 Local File Header와의 relative offset도 담고 있어 빠르게 Local File을 찾을 수 있게 해준다. 참고로 실제 압축 파일에 Local File Entry가 담겨 있는 순서와 Central Directory의 File Header가 담겨 있는 순서가 틀려도 관계 없다.
Digital Signature는 있어도 그만 없어도 그만인 것 같은데 PKWARE의 Application Note에서 정확한 정보를 찾을 수 없었다. 실제로 파일을 압축해보면 Digital Signature가 들어있지 않다. 정확한 정보를 계속 찾고 있으니 찾아 내는 데로 문서에 반영될 꺼라능.
전체 구조를 대충 살펴 봤으니 이제 PKWARE의 Application Note에서 소개해주는 진짜 전체 구조를 살펴보자.
위에서 봤던 구조랑 비슷한데 뭐가 이것저것 더 붙어 있다. 일단 처음 나오는걸 살펴보자능. EFS라고 표시된 섹션들은 Strong Encryption Specification과 관련이 있다. 우리는 Encryption과 관련된 내용은 다루지 않을 거기 때문에 저건 없다고 생각하자.
이름이 Zip64로 시작하는 섹션들은 오리지널 ZIP 포맷의 크기 제한을 없에는 ZIP64 포맷과 관련이 있다. 우리는 이 내용도 다루지 않을 꺼다. 참고로 오리지널 ZIP 포맷의 크기 제한이란 전체 ZIP 파일의 크기와 Local File의 압축된 크기 및 압축이 해제된 크기의 4GB 제한과 전체 Local File Entry의 개수가 65535개로 제한되는 것을 말한다. 아무튼 저 두 섹션들도 없다고 생각하자.
각각의 Central Directory의 File Header는 version needed to extract라는 이름으로 자신의 압축을 해제하기 위해 구현해야 되는 ZIP 파일 포맷의 스펙의 버전을 명시하고 있다. 이걸 보고 위의 두 가지 특징들이 사용되었는지 알 수 있다.
다음 챕터부터 Local File Entry와 Central Directory의 구조를 살펴보면서 리얼 월드에서 돌아다니고 있는 ZIP파일의Hex dump를 분석해볼 꺼라능. 이 과정에서 프로그램으로 ZIP파일을 분석하려면 어떻게 해야 하는지에 대한 노하우도 조금은 얻을 수 있을꺼라능.....아마도 -_-
이 문서에서 우리는 .ZIP 압축 파일을 읽는 방법을 살펴볼 꺼라능. 물론 ZIP 파일 포맷을 읽어내는 라이브러리가 많이 있긴 하지만 우리는 배움을 목적으로 바퀴를 다시 발명해 볼 껑미.
아마도 이 문서는 ZIP 파일 포맷을 하향식으로 분석해 보면서 기존의 압축 유틸리티를 사용해 생성된 ZIP 파일의 Hex dump를 눈으로 읽어보는 방식으로 진행 될 꺼라능. 그리고 부록으로 소스코드가 제공 될 꺼라능. 내 계획이 바뀌지 않는다면 말이삼. 실습에 사용하는 압축 유틸리티는 7zip을 사용할 꺼고 hex 에디터는 HxD를 사용할 태니 긔찬아도 설치를 하도록 하자능.
모두들 알다시피 ZIP 파일 포맷은 데이터를 압축해서 보관하기 위해서 사용하는 파일 모맷이라능. N개의 파일을 묶어서 하나로 묶어서 크기를 줄여서 저장하는데 사용하는 파일 포맷임. 스펙에는 꽤 많은 압축 알고리즘을 지원하지만 근래에는 Deflate 알고리즘이 대세다. 다른 건 쌩까도 될 정도로 Deflate 알고리즘이 많이 사용되고 있다능.
ZIP 파일 포맷은 1989년 Phil Katz가 PKZIP에 사용하려고 만들었다고 한다. ARC 파일 압축을 발전 시킨 건데 지금에 와서는 메이저 OS는 모두 별다른 유틸리티 프로그램이 없이 ZIP 파일 포맷을 해제 또는 압축 할 수 있다능.사실상 업계에서 가장 널리 쓰이고 있는 압축 포맷임.
일반적으로 확장자는 “.zip” 또는 “.ZIP”를 사용하고 MIME 형식으로는 application/zip으로 표시한다고 한다. 알께뭐임..나는 임베디드 플머라 MIME 형식 따위는 모름. 아무튼 많은 소프트웨어에서 파일 저장 형식으로 사용된다고 한다. 대표적으로 .jar, .odt, .docx 등이 ZIP 파일 포맷으로 저장된다고 한다. 이 경우에는 확장자의 이름만 바꾼 방식으로 사용되고 있다. 못 믿겠으면 .docx를 7zip같은 압축 유틸리티로 풀어보라능.
여담이지만 ZIP의 아버지인 Phil Katz 알코올중독으로 고생하다가 2000년에 4월에 호텔방에서 급성 알콜 중독으로 사망했따능. 손에는 술병을 들고 있었다던데.....나도 조금 조심해야겠음.
이번편에서 수동으로 FAT12를 구축해보고 Drilling FAT12를 마칠꺼라능. 2편에 있는 링크를 타고가서 일단 HxD를 깔자능...그리고 Virtual Floppy Drive랑 empty.img도 받자능. 일단 VFD를 켜고 Driver 탭의 Browse... 버튼을 눌러서 압축을 풀면 같이 들어있는 vfd.sys 를 선택해 주자능.
그리고 밑에있는 Start 버튼을 눌러주라능. 그리고 Drive0 텝으로 가자능. Change 버튼을 눌러서 드라이브 문자를 바꿔주라능. 맘에 드는걸로 바꿔주고 Open... 버튼을 누른 다음에 Browse... 버튼을 눌러서 empty.img를 선택해주고 Disk Type를 FILE로 선택해 골라주자능.
됐다능. 이제 가상드라이브가 작동하게 되었심. 탐색기를 켜보면 새 드라이브가 생겨난걸 볼 수 있을꺼라능. 더블클릭하면 포멧을 할꺼냐고 물어보는데 반드시 쌩까도록하삼. 그리구 나서 HxD를 켜자능. HxD의 Extras 메뉴에서 Open Disk를 눌러서 방금 만든 가상드라이브를 골라주라능. Open as Readonly는 꼭 꺼놓으라능.
OK를 눌르면 뭐라고 경고창이 뜨는데 우리 같은 프로들 한태는 필요업ㅂ은 소리라능. 쌩까자능. 아무튼 여기까지 끝냈으면 아래 그림과 같은 모습이 될꺼심. 준비끝이라능. 한 화면에 한 섹터의 전체를 다 볼 수 있게 창크기를 조절하는 센스가 있으면 더욱 좋다능.
이제부터 다음과 같은 순서로 진행할꺼라능
(1) 디스켓을 FAT12로 포멧된 상태로 만든다.
(2) 루트 디렉토리에 서브 디렉토리를 하나 추가한다.
(3) 루트 디렉토리랑 서브 디렉토리에 각각 하나씩 파일을 추가해본다.
(1) 포멧시키기
화면에 Drilling FAT12 1편을 열어 놓고 표를 봐가면서 내용을 채우자능. 2바이트 이상되는 필드를 채울때는 엔디안을 주의해야된다능. 아..ㅅㅂ 귀차늠. intel 훡훡. 10진수를 16진수로 바꿀때는 윈도우 계산기가 참 좋음. 일단 32바이트를 채웠다능.
EB 4E 90 44 43 49 4E 53 49 44 45 00 02 01 01 00
02 E0 00 40 0B F0 09 00 12 00 02 00 00 00 00 00
필드 별로 색을 번갈아 칠해 놨으니까 표를 보면서 값이 어떻게 들어갔나 확인해보라능. OEM 네임은 DCINSIDE를 넣어놨다능 ㅋㅋㅋㅋ. 아무튼...표를 보고 쓰라는 데로 똑같이 쓰면 된다능. 나머지 48바이트도 마져 채워넣자능. 참...아스키 문자를 넣고 싶을때는 코드표를 찾아가면서 16진수를 쓰지말고 옆에 아스키코드로 보여주는 칸에다 커서를 놓고 쓰면 된다능. 괜히 삽질하지 말자능. 아무튼 나머지 48바이트임.
주의 사항에 보면 33번 섹터를 사용할꺼라고 표시할때는 First logical sector에 2를 쓰라고 했다능. 이제 33번 섹터로 이동하자능. 아..주의할꺼는 위의 두줄은 offset 00002620 부터 써넣는거임. 00002610에 0만 잔뜩 써있다고 여기다 넣으면 젖된다능. 00002610은 볼륨 라벨의 뒤쪽 16바이트 자리라능. 해깔리지 않도록 조심하라능. 주의 사항에 보면은 서브 디렉토리에는 "." 이랑 ".." 이 반드시 있어야 된다고 했다능. 만들어 주자능.
총 3회에 걸쳐서 FAT12에 대해서 알아봤다능.FAT12는 간단한 파일 시스템이고...현재는 거의 쓰이지 않는다능. 디스켓 따위를 누가 쓰냐능 -_-;;; FAT32를 배워보기전에 몸풀기 용으로 배워본다고 하는데 의의를 두자능. 이 글에서 자세히 다뤄보지 않은건 여러 섹터에 걸쳐있는 파일에 대한 FAT 엔트리를 집어넣는건데...이건 나도 어캐하는지 모른다능. -_-;; 누가좀 가르쳐 주삼 읭읭.
댓글을 달아 주세요
끵..?
끵?!