'공부합시다'에 해당되는 글 70건
- 2009.10.09 ID3v2 분석
- 2009.10.08 ID3v2 Frame ID List
- 2009.10.08 MP3 ID3 tag 분석
- 2009.10.06 [MFC] 프로세스 접근 권한 얻기
- 2009.09.30 [MFC] 리스트 컨트롤 폰트 바꾸기
- 2009.09.18 TCP 헤더 분석 3
- 2009.09.16 ether_header 구조체와 iphdr 구조체를 이용한 패킷 분석
- 2009.09.16 바이트별로 노가다 작업을 통한 패킷 분석-ㅅ-; 1
- 2009.09.15 패킷 캡쳐로 살펴본 이더넷 프레임
- 2009.09.15 이더넷 프레임의 구조
mp3 파일은 크게 보면 아래와 같은 구조로 이루어져 있다.
ID3v2는 중복해서 들어갈 수 있기 때문에 하나만 있을 수도 있고 여러개가 있을 수도 있다. ID3v1은 파일의 끝에 붙는다. 오늘은 ID3v2에 대해 더 자세히 알아보도록 하겠다.
=======================================================================================================
ID3v2 의 구조
ID3v2는 아래와 같은 형식으로 이루어져 있다.
헤더는 ID3v2에 대한 전체적인 정보를 가지고 있고, 각 프레임은 가수, 제목, 앨범, 앨범자켓 이미지등의 정보가 각각의 프레임으로 구성되어 있다.
실제 mp3을 헥스뷰어로 열어봐서 각 바이트별로 분석해보겠다.
=======================================================================================================
ID3v2 헤더(10 bytes)
==========================================================
Byte(Length) Content
==========================================================
0-2(3) Tag Identifier (ID3가 적힌다)
3-4 (2) Tag Version.
5(1) Flags
6-9(4) Size of Tag (Tag의 사이즈)
==========================================================
0x00 ~ 0x02 : ID3라고 되있으므로 이 부분부터는 ID3v2라는 것을 의미한다.
0x03 ~ 0x04 : 4와 0으로 되있으므로 버전이 ID3v2.4.0 임을 의미한다.
0x05 : flag 인데 대부분 0 으로 되있다.
0x06 ~ 0x09 :
tag의 크기인데 중요한것은 이 값이 mp3안에 있는 모든 tag의 크기가 아니라 자신의 크기만이란 것이다. 이 뒤에 ID3으로 시작하는 부분이 또 있을 수 있다. 즉, 위에서 말했듯이 중복해서 들어갈 수 있기 때문에 tag의 총 크기를 구하려면 크기를 누적해서 구해야한다.
또 중요한 것이 있는데 저기 적힌 값은 Encoding 된 값이다. 4바이트 중에 각 바이트의 최상위 비트를 제거하고 붙여주어야 원래 크기가 된다.
실제로 값을 구해보면 00 00 05 13 을 2진수로 표현하면, 0000 0000 , 0000 0000, 0000 0101, 0001 0011 이 된다. 여기서 각 바이트의 최상위 비트를 제거하면 000 0000, 000 0000, 000 0101, 001 0011 이 되고, 이를 한줄로 합치면
0000 0000 0000 0000 0010 1001 0011 = 0x293 가 된다.
그런데 이 값은 헤더의 길이는 포함하지 않은 길이이기 때문에 실제 ID3v2 tag의 길이는 헤더 길이 10바이트를 더해준 0x293 + 10 = 0x29D 가 된다.
=======================================================================================================
ID3v2 프레임(가변 길이)
프레임은 헤더와 내용으로 이루어져있다. 빨간색으로 표시한 부분이 헤더이고, 파란색으로 표시한 부분이 데이터이다.
=============================
- Header
Byte Content
0-3 Frame identifier
4-7 Size
8-9 Flags
=============================
0x0A ~ 0x0D : 프레임의 ID 이다. 이에 대한 자세한 정보는 이전 포스팅에서 다루었다.
TIT2는 Title/songname/content description 즉, 노래 제목이다.
0x0E ~ 0x11 : 프레임의 크기이다. 00 00 00 38 이므로 십진수로 56이다. 이것은 헤더를 제외한 프레임 크기이다.
따라서 헤더를 포함한 프레임의 크기는 헤더 10바이트를 더한 66바이트 이다.
0x12 ~ 0x13 : 플래그인데 보통 0으로 세팅되어 있다.
헤더 뒤부터는 데이터인데 프레임의 크기가 56이므로 되어있었으므로 56바이트의 크기로 TIT2 즉, 노래 제목이 저장되어 있다.
표시된 부분 다음에 보면 다시 TPE1이라고 되있는데 이것을 이전 포스팅에서 찾아보면 가수이름이라고 되있다. 이런식으로 프레임들이 이어져 붙어 있다.
ID3v2는 중복해서 들어갈 수 있기 때문에 하나만 있을 수도 있고 여러개가 있을 수도 있다. ID3v1은 파일의 끝에 붙는다. 오늘은 ID3v2에 대해 더 자세히 알아보도록 하겠다.
=======================================================================================================
ID3v2 의 구조
ID3v2는 아래와 같은 형식으로 이루어져 있다.
헤더는 ID3v2에 대한 전체적인 정보를 가지고 있고, 각 프레임은 가수, 제목, 앨범, 앨범자켓 이미지등의 정보가 각각의 프레임으로 구성되어 있다.
실제 mp3을 헥스뷰어로 열어봐서 각 바이트별로 분석해보겠다.
=======================================================================================================
ID3v2 헤더(10 bytes)
==========================================================
Byte(Length) Content
==========================================================
0-2(3) Tag Identifier (ID3가 적힌다)
3-4 (2) Tag Version.
5(1) Flags
6-9(4) Size of Tag (Tag의 사이즈)
==========================================================
0x00 ~ 0x02 : ID3라고 되있으므로 이 부분부터는 ID3v2라는 것을 의미한다.
0x03 ~ 0x04 : 4와 0으로 되있으므로 버전이 ID3v2.4.0 임을 의미한다.
0x05 : flag 인데 대부분 0 으로 되있다.
0x06 ~ 0x09 :
tag의 크기인데 중요한것은 이 값이 mp3안에 있는 모든 tag의 크기가 아니라 자신의 크기만이란 것이다. 이 뒤에 ID3으로 시작하는 부분이 또 있을 수 있다. 즉, 위에서 말했듯이 중복해서 들어갈 수 있기 때문에 tag의 총 크기를 구하려면 크기를 누적해서 구해야한다.
또 중요한 것이 있는데 저기 적힌 값은 Encoding 된 값이다. 4바이트 중에 각 바이트의 최상위 비트를 제거하고 붙여주어야 원래 크기가 된다.
실제로 값을 구해보면 00 00 05 13 을 2진수로 표현하면, 0000 0000 , 0000 0000, 0000 0101, 0001 0011 이 된다. 여기서 각 바이트의 최상위 비트를 제거하면 000 0000, 000 0000, 000 0101, 001 0011 이 되고, 이를 한줄로 합치면
0000 0000 0000 0000 0010 1001 0011 = 0x293 가 된다.
그런데 이 값은 헤더의 길이는 포함하지 않은 길이이기 때문에 실제 ID3v2 tag의 길이는 헤더 길이 10바이트를 더해준 0x293 + 10 = 0x29D 가 된다.
=======================================================================================================
ID3v2 프레임(가변 길이)
프레임은 헤더와 내용으로 이루어져있다. 빨간색으로 표시한 부분이 헤더이고, 파란색으로 표시한 부분이 데이터이다.
=============================
- Header
Byte Content
0-3 Frame identifier
4-7 Size
8-9 Flags
=============================
0x0A ~ 0x0D : 프레임의 ID 이다. 이에 대한 자세한 정보는 이전 포스팅에서 다루었다.
TIT2는 Title/songname/content description 즉, 노래 제목이다.
0x0E ~ 0x11 : 프레임의 크기이다. 00 00 00 38 이므로 십진수로 56이다. 이것은 헤더를 제외한 프레임 크기이다.
따라서 헤더를 포함한 프레임의 크기는 헤더 10바이트를 더한 66바이트 이다.
0x12 ~ 0x13 : 플래그인데 보통 0으로 세팅되어 있다.
헤더 뒤부터는 데이터인데 프레임의 크기가 56이므로 되어있었으므로 56바이트의 크기로 TIT2 즉, 노래 제목이 저장되어 있다.
표시된 부분 다음에 보면 다시 TPE1이라고 되있는데 이것을 이전 포스팅에서 찾아보면 가수이름이라고 되있다. 이런식으로 프레임들이 이어져 붙어 있다.
'공부합시다 > 파일 포맷' 카테고리의 다른 글
| PE 파일 분석 (3) | 2009.10.26 |
|---|---|
| ID3v2 Frame ID List (0) | 2009.10.08 |
| MP3 ID3 tag 분석 (0) | 2009.10.08 |
출처 : http://tagged.sourceforge.net/id3v2-Data-man.html
=======================================================================================================
List of Simple Frames
IPLS : Involved people list
MCDI : Music CD identifier
PCNT : Play counter
TALB : Album/Movie/Show title
TBPM : BPM (beats per minute)
TCOM : Composer
TCON : Content type
TCOP : Copyright message
TDAT : Date
TDLY : Playlist delay
TENC : Encoded by
TEXT : Lyricist/Text writer
TFLT : File type
TIME : Time
TIT1 : Content group description
TIT2 : Title/songname/content description
TIT3 : Subtitle/Description refinement
TKEY : Initial key
TLAN : Language(s)
TLEN : Length
TMED : Media type
TOAL : Original album/movie/show title
TOFN : Original filename
TOLY : Original lyricist(s)/text writer(s)
TOPE : Original artist(s)/performer(s)
TORY : Original release year
TOWN : File owner/licensee
TPE1 : Lead performer(s)/Soloist(s)
TPE2 : Band/orchestra/accompaniment
TPE3 : Conductor/performer refinement
TPE4 : Interpreted, remixed, or otherwise modified by
TPOS : Part of a set
TPUB : Publisher
TRCK : Track number/Position in set
TRDA : Recording dates
TRSN : Internet radio station name
TRSO : Internet radio station owner
TSIZ : Size
TSRC : ISRC (international standard recording code)
TSSE : Software/Hardware and settings used for encoding
TYER : Year
WCOM : Commercial information
WCOP : Copyright/Legal information
WOAF : Official audio file webpage
WOAR : Official artist/performer webpage
WOAS : Official audio source webpage
WORS : Official internet radio station homepage
WPAY : Payment
WPUB : Publishers official webpage
=======================================================================================================
List of Complex Frames
AENC : Audio encryption
Keys: URL, Preview start, Preview length
APIC : Attached picture
Keys: MIME type, Picture Type, Description, _Data
COMM : Comments
Keys: Language, short, Text
COMR : Commercial frame
Keys: Price, Valid until, URL, Received as, Name of Seller, Description, MIME type, _Logo
ENCR : Encryption method registration
Keys: Owner ID, Method symbol, _Data
GEOB : General encapsulated object
Keys: MIME type, Filename, Description, _Data
GRID : Group identification registration
Keys: Owner, Symbol, _Data
LINK : Linked information
Keys: _ID, URL, Text
OWNE : Ownership frame
Keys: Price payed, Date of purchase, Text
POPM : Popularimeter
Keys: URL, Rating, _Data
PRIV : Private frame
Keys: Text, _Data
RBUF : Recommended buffer size
Keys: Buffer size, Embedded info flag, Offset to next tag
RVRB : Reverb
Keys: Reverb left (ms), Reverb right (ms), Reverb bounces (left), Reverb bounces (right), Reverb feedback (left to left), Reverb feedback (left to right), Reverb feedback (right to right), Reverb feedback (right to left), Premix left to right, Premix right to left
SYTC : Synchronized tempo codes
Keys: Time Stamp Format, _Data
TXXX : User defined text information frame
Keys: Description, Text
UFID : Unique file identifier
Keys: Text, _Data
USER : Terms of use
Keys: Language, Text
USLT : Unsychronized lyric/text transcription
Keys: Language, Description, Text
WXXX : User defined URL link frame
Keys: Description, URL
=======================================================================================================
List of Other Frames
EQUA : Equalization
ETCO : Event timing codes
MLLT : MPEG location lookup table
POSS : Position synchronisation frame
RVAD : Relative volume adjustment
SYLT : Synchronized lyric/text
... 아 ㅅㅂ 졸라 많어...ㅠ
=======================================================================================================
List of Simple Frames
IPLS : Involved people list
MCDI : Music CD identifier
PCNT : Play counter
TALB : Album/Movie/Show title
TBPM : BPM (beats per minute)
TCOM : Composer
TCON : Content type
TCOP : Copyright message
TDAT : Date
TDLY : Playlist delay
TENC : Encoded by
TEXT : Lyricist/Text writer
TFLT : File type
TIME : Time
TIT1 : Content group description
TIT2 : Title/songname/content description
TIT3 : Subtitle/Description refinement
TKEY : Initial key
TLAN : Language(s)
TLEN : Length
TMED : Media type
TOAL : Original album/movie/show title
TOFN : Original filename
TOLY : Original lyricist(s)/text writer(s)
TOPE : Original artist(s)/performer(s)
TORY : Original release year
TOWN : File owner/licensee
TPE1 : Lead performer(s)/Soloist(s)
TPE2 : Band/orchestra/accompaniment
TPE3 : Conductor/performer refinement
TPE4 : Interpreted, remixed, or otherwise modified by
TPOS : Part of a set
TPUB : Publisher
TRCK : Track number/Position in set
TRDA : Recording dates
TRSN : Internet radio station name
TRSO : Internet radio station owner
TSIZ : Size
TSRC : ISRC (international standard recording code)
TSSE : Software/Hardware and settings used for encoding
TYER : Year
WCOM : Commercial information
WCOP : Copyright/Legal information
WOAF : Official audio file webpage
WOAR : Official artist/performer webpage
WOAS : Official audio source webpage
WORS : Official internet radio station homepage
WPAY : Payment
WPUB : Publishers official webpage
=======================================================================================================
List of Complex Frames
AENC : Audio encryption
Keys: URL, Preview start, Preview length
APIC : Attached picture
Keys: MIME type, Picture Type, Description, _Data
COMM : Comments
Keys: Language, short, Text
COMR : Commercial frame
Keys: Price, Valid until, URL, Received as, Name of Seller, Description, MIME type, _Logo
ENCR : Encryption method registration
Keys: Owner ID, Method symbol, _Data
GEOB : General encapsulated object
Keys: MIME type, Filename, Description, _Data
GRID : Group identification registration
Keys: Owner, Symbol, _Data
LINK : Linked information
Keys: _ID, URL, Text
OWNE : Ownership frame
Keys: Price payed, Date of purchase, Text
POPM : Popularimeter
Keys: URL, Rating, _Data
PRIV : Private frame
Keys: Text, _Data
RBUF : Recommended buffer size
Keys: Buffer size, Embedded info flag, Offset to next tag
RVRB : Reverb
Keys: Reverb left (ms), Reverb right (ms), Reverb bounces (left), Reverb bounces (right), Reverb feedback (left to left), Reverb feedback (left to right), Reverb feedback (right to right), Reverb feedback (right to left), Premix left to right, Premix right to left
SYTC : Synchronized tempo codes
Keys: Time Stamp Format, _Data
TXXX : User defined text information frame
Keys: Description, Text
UFID : Unique file identifier
Keys: Text, _Data
USER : Terms of use
Keys: Language, Text
USLT : Unsychronized lyric/text transcription
Keys: Language, Description, Text
WXXX : User defined URL link frame
Keys: Description, URL
=======================================================================================================
List of Other Frames
EQUA : Equalization
ETCO : Event timing codes
MLLT : MPEG location lookup table
POSS : Position synchronisation frame
RVAD : Relative volume adjustment
SYLT : Synchronized lyric/text
... 아 ㅅㅂ 졸라 많어...ㅠ
'공부합시다 > 파일 포맷' 카테고리의 다른 글
| PE 파일 분석 (3) | 2009.10.26 |
|---|---|
| ID3v2 분석 (0) | 2009.10.09 |
| MP3 ID3 tag 분석 (0) | 2009.10.08 |
출처 : 위키(에서 나름 요약정리 =ㅅ=)
ID3는 MP3 파일에서 사용하는 메타 데이터 포맷으로, 음악의 제목, 음악가 이름 등의 음악 파일에 관련된
정보를 담는다. ID3에는 ID3v1과 ID3v2 두 가지의 버전이 있으며, 이들은 서로 호환성이 없으며 하나의 파일
안에 동시에 존재할 수도 있다.
=======================================================================================================
ID3v1
ID3v1은 파일 끝에 128 바이트를 덧붙이는데, 'TAG'라는 문자열로 시작되므로 미디어 플레이어가 쉽게 인식할
수 있다. 초기의 MP3 재생기는 때때로 MPEG 스트림 사이에 삽입된 데이터에 적절히 대응하지 못하고, 재생을
멈추거나 잡음이 튀는 등의 문제가 있었고, 심지어 재생을 못하기도 했다(태그가 파일의 첫 부분에 있는 경우),
이 같은 문제 때문에 태그는 보통 파일의 첫 부분보다는 끝에 삽입됐다.
ID3v1 포맷
ID3v1.1 포맷
=======================================================================================================
ID3v2
ID3v1은 그 크기가 128바이트로 정해졌기 때문에, 추가적인 정보를 넣는 것이 거의 불가능했다. 이 문제를
해결하기 위해 Lyric3과 같은 다른 포맷이 제안되기도 하였으며, 마틴 닐슨(Martin Nilsson)이 제안한 ID3v2 태그
포맷도 이런 문제를 극복하였다. ID3v2 태그 포맷은 다음과 같은 특징을 가지고 있다.
ID3v2에는 다음과 같은 세 가지 버전이 있다. 각 버전들은 구조가 비슷하지만 서로 호환성은 없다.
ID3v2는 너무 많은 정보를 하나의 메타 데이터 포맷에 담기 때문에 구현이 힘들다는 단점을 갖고 있다. 예를 들어,
오디오의 길이를 저장하는 TLEN 프레임과 오디오의 인코딩 방법을 저장하는 AENC 프레임 등은 메타 데이터가
담긴 파일을 분석해도 알아 낼 수 있는 정보이며(다만 경우에 따라서 오디오의 길이를 쉽게 알 수 없는 경우는
있다), ID3v2.4에 있는 84개의 프레임이 각각 서로 다른 내부 구조를 갖고 있으며 버전마다 구조가 다른 경우도
있기 때문에 일괄적인 처리가 힘들어진다. APEv2와 같이 나중에 만들어진 메타 데이터 포맷은 내부 구조를
통일하여 이런 문제를 해결한다.
ID3는 MP3 파일에서 사용하는 메타 데이터 포맷으로, 음악의 제목, 음악가 이름 등의 음악 파일에 관련된
정보를 담는다. ID3에는 ID3v1과 ID3v2 두 가지의 버전이 있으며, 이들은 서로 호환성이 없으며 하나의 파일
안에 동시에 존재할 수도 있다.
=======================================================================================================
ID3v1
ID3v1은 파일 끝에 128 바이트를 덧붙이는데, 'TAG'라는 문자열로 시작되므로 미디어 플레이어가 쉽게 인식할
수 있다. 초기의 MP3 재생기는 때때로 MPEG 스트림 사이에 삽입된 데이터에 적절히 대응하지 못하고, 재생을
멈추거나 잡음이 튀는 등의 문제가 있었고, 심지어 재생을 못하기도 했다(태그가 파일의 첫 부분에 있는 경우),
이 같은 문제 때문에 태그는 보통 파일의 첫 부분보다는 끝에 삽입됐다.
ID3v1 포맷
| 오프셋 |
길이 |
설명 |
| 0 |
3 |
'TAG' 인식문자열 |
| 3 |
30 |
음악 제목 문자열 |
| 33 |
30 |
가수(음악가) 문자열 |
| 63 |
30 |
음반 문자열 |
| 93 |
4 |
음반 출시년도 문자열 |
| 97 |
30 |
비고 문자열 |
| 127 |
1 |
장르 바이트 |
ID3v1.1 포맷
| 오프셋 |
길이 |
설명 |
| 0 |
3 |
'TAG' 인식 문자열 |
| 3 |
30 |
음악 제목 문자열 |
| 33 |
30 |
가수(음악가) 문자열 |
| 63 |
30 |
음반 문자열 |
| 93 |
4 |
음반 출시년도 문자열 |
| 97 |
28 |
비고 문자열 |
| 125 |
1 |
바이트 분리자 (항상 0) |
| 126 |
1 |
곡 번호 바이트 |
| 127 |
1 |
장르 바이트 |
=======================================================================================================
ID3v2
ID3v1은 그 크기가 128바이트로 정해졌기 때문에, 추가적인 정보를 넣는 것이 거의 불가능했다. 이 문제를
해결하기 위해 Lyric3과 같은 다른 포맷이 제안되기도 하였으며, 마틴 닐슨(Martin Nilsson)이 제안한 ID3v2 태그
포맷도 이런 문제를 극복하였다. ID3v2 태그 포맷은 다음과 같은 특징을 가지고 있다.
* 파일의 첫 부분에 큰 데이터 블록으로 삽입되며, ID3v1과의 호환성이 없다. (ID3v2.4부터는 선택적으로 파일의 끝에 삽입할 수 있다)
* 프로그램이 파일의 끝까지 읽어 들이기 전에 태그 정보를 얻을 수 있기 때문에 스트리밍 파일을 재생할 때 이득이 된다.
* 태그의 길이가 변경될 경우 전체 파일이 재작성되어야 하기 때문에 태그를 쓸 때 효율성 면에서 불리할 수 있다. 이런 이유 때문에 ID3v2 태그 뒤에 적당한 공백을 넣어서, 태그의 길이가 어느 이상 커지지 않으면 전체 파일을 재작성하지 않는 방법을 사용하는 경우도 있다.
* 몇 개의 고정된 필드를 제공했던 ID3v1과는 달리, ID3v2 태그는 포맷이 정형화된 태그 프레임들로 이루어져 있기 때문에 확장하기 용이하다.
* 작사자, 지휘자, 매체 종류, BPM, 가사, 이미지, 볼륨, 잔향 설정, 암호화된 정보 등과 같은 다양한 정보를 넣을 수 있다.
* 태그에 가짜 동기 신호가 삽입되는 것을 방지하기 위한 비동기화(unsynchronisation) 옵션을 제공하기 때문에, ID3v2 태그가 삽입된 MP3 파일은 ID3v2를 지원하지 않는 프로그램에서도 안전하게 재생할 수 있다.
* 태그 전체의 크기는 256MB까지 허용되며 프레임 하나의 크기는 16MB까지 허용된다.
* 유니코드를 지원하므로 국제화된 태그를 이용할 수 있다. 기본적으로 UTF-16 인코딩을 지원하며, 또한 ID3v2.4부터는 UTF-8을 지원한다.
* 프로그램이 파일의 끝까지 읽어 들이기 전에 태그 정보를 얻을 수 있기 때문에 스트리밍 파일을 재생할 때 이득이 된다.
* 태그의 길이가 변경될 경우 전체 파일이 재작성되어야 하기 때문에 태그를 쓸 때 효율성 면에서 불리할 수 있다. 이런 이유 때문에 ID3v2 태그 뒤에 적당한 공백을 넣어서, 태그의 길이가 어느 이상 커지지 않으면 전체 파일을 재작성하지 않는 방법을 사용하는 경우도 있다.
* 몇 개의 고정된 필드를 제공했던 ID3v1과는 달리, ID3v2 태그는 포맷이 정형화된 태그 프레임들로 이루어져 있기 때문에 확장하기 용이하다.
* 작사자, 지휘자, 매체 종류, BPM, 가사, 이미지, 볼륨, 잔향 설정, 암호화된 정보 등과 같은 다양한 정보를 넣을 수 있다.
* 태그에 가짜 동기 신호가 삽입되는 것을 방지하기 위한 비동기화(unsynchronisation) 옵션을 제공하기 때문에, ID3v2 태그가 삽입된 MP3 파일은 ID3v2를 지원하지 않는 프로그램에서도 안전하게 재생할 수 있다.
* 태그 전체의 크기는 256MB까지 허용되며 프레임 하나의 크기는 16MB까지 허용된다.
* 유니코드를 지원하므로 국제화된 태그를 이용할 수 있다. 기본적으로 UTF-16 인코딩을 지원하며, 또한 ID3v2.4부터는 UTF-8을 지원한다.
ID3v2에는 다음과 같은 세 가지 버전이 있다. 각 버전들은 구조가 비슷하지만 서로 호환성은 없다.
*ID3v2.2 (1998년): ID3v2 태그의 첫 버전으로, 현재는 거의 사용되지 않는다.
*ID3v2.3 (1999년): 태그 프레임의 속성을 나타내는 필드가 추가되었으며 확장된 헤더를 제공한다.
*ID3v2.4 (2000년): 확장된 헤더의 구조가 바뀌었고, 푸터를 지원하므로 파일의 끝에도 삽입할 수 있다. 또한 UTF-8 인코딩을 지원한다.
*ID3v2.3 (1999년): 태그 프레임의 속성을 나타내는 필드가 추가되었으며 확장된 헤더를 제공한다.
*ID3v2.4 (2000년): 확장된 헤더의 구조가 바뀌었고, 푸터를 지원하므로 파일의 끝에도 삽입할 수 있다. 또한 UTF-8 인코딩을 지원한다.
ID3v2는 너무 많은 정보를 하나의 메타 데이터 포맷에 담기 때문에 구현이 힘들다는 단점을 갖고 있다. 예를 들어,
오디오의 길이를 저장하는 TLEN 프레임과 오디오의 인코딩 방법을 저장하는 AENC 프레임 등은 메타 데이터가
담긴 파일을 분석해도 알아 낼 수 있는 정보이며(다만 경우에 따라서 오디오의 길이를 쉽게 알 수 없는 경우는
있다), ID3v2.4에 있는 84개의 프레임이 각각 서로 다른 내부 구조를 갖고 있으며 버전마다 구조가 다른 경우도
있기 때문에 일괄적인 처리가 힘들어진다. APEv2와 같이 나중에 만들어진 메타 데이터 포맷은 내부 구조를
통일하여 이런 문제를 해결한다.
'공부합시다 > 파일 포맷' 카테고리의 다른 글
| PE 파일 분석 (3) | 2009.10.26 |
|---|---|
| ID3v2 분석 (0) | 2009.10.09 |
| ID3v2 Frame ID List (0) | 2009.10.08 |
프로세스에 대한 정보를 얻어오려면 권한이 없어서 읽어오지 못하는 경우가 있다.
그럴 경우에는 아래의 함수를 추가해주면 된다.
CreateToolhelp32Snapshot() 같은 함수로 프로세스나 모듈을 열기전에,
AdjustDebugPrivilege() 함수로 권한을 획득해주고, 핸들을 닫은 후에 RestorePrivilege() 함수로 권한을 반환해 주면 된다.
그럴 경우에는 아래의 함수를 추가해주면 된다.
CreateToolhelp32Snapshot() 같은 함수로 프로세스나 모듈을 열기전에,
AdjustDebugPrivilege() 함수로 권한을 획득해주고, 핸들을 닫은 후에 RestorePrivilege() 함수로 권한을 반환해 주면 된다.
'공부합시다 > WinAPI, MFC' 카테고리의 다른 글
| [MFC] 리스트 컨트롤 폰트 바꾸기 (0) | 2009.09.30 |
|---|---|
| [WinAPI] BMP 파일에서 특정색상을 투명하게 출력하기 (0) | 2009.07.06 |
MFC나 API로 다이얼로그를 만들어서 하다보면 폰트가 마음에 안들때가 많습니다.
리스트 컨트롤로 헥스뷰어를 만들다가 폰트가 너무 마음에 안들어서 폰트 바꾸는 방법을 찾아봤습니다.
아래의 함수를 이용하면 폰트를 바꿀 수 있습니다.
실제 사용은 아래와 같이 하면 됩니다.
m_hList는 리스트 컨트롤의 객체입니다.
만약 다른 컨트롤의 폰트를 바꾸고 싶다면 객체부분만 바꿔주면 됩니다.
리스트 컨트롤로 헥스뷰어를 만들다가 폰트가 너무 마음에 안들어서 폰트 바꾸는 방법을 찾아봤습니다.
아래의 함수를 이용하면 폰트를 바꿀 수 있습니다.
HFONT CreateFont(
int nHeight, // logical height of font
int nWidth, // logical average character width
int nEscapement, // angle of escapement
int nOrientation, // base-line orientation angle
int fnWeight, // font weight
DWORD fdwItalic, // italic attribute flag
DWORD fdwUnderline, // underline attribute flag
DWORD fdwStrikeOut, // strikeout attribute flag
DWORD fdwCharSet, // character set identifier
DWORD fdwOutputPrecision, // output precision
DWORD fdwClipPrecision, // clipping precision
DWORD fdwQuality, // output quality
DWORD fdwPitchAndFamily, // pitch and family
LPCTSTR lpszFace // pointer to typeface name string
);
int nHeight, // logical height of font
int nWidth, // logical average character width
int nEscapement, // angle of escapement
int nOrientation, // base-line orientation angle
int fnWeight, // font weight
DWORD fdwItalic, // italic attribute flag
DWORD fdwUnderline, // underline attribute flag
DWORD fdwStrikeOut, // strikeout attribute flag
DWORD fdwCharSet, // character set identifier
DWORD fdwOutputPrecision, // output precision
DWORD fdwClipPrecision, // clipping precision
DWORD fdwQuality, // output quality
DWORD fdwPitchAndFamily, // pitch and family
LPCTSTR lpszFace // pointer to typeface name string
);
실제 사용은 아래와 같이 하면 됩니다.
HFONT hNewFont;
hNewFont=CreateFont( 12,0,0,0,0,0,0,0,HANGEUL_CHARSET,3,2,1,
VARIABLE_PITCH | FF_MODERN,"돋음");
m_hList.SendMessage( WM_SETFONT, (WPARAM)hNewFont, (LPARAM)TRUE);
hNewFont=CreateFont( 12,0,0,0,0,0,0,0,HANGEUL_CHARSET,3,2,1,
VARIABLE_PITCH | FF_MODERN,"돋음");
m_hList.SendMessage( WM_SETFONT, (WPARAM)hNewFont, (LPARAM)TRUE);
m_hList는 리스트 컨트롤의 객체입니다.
만약 다른 컨트롤의 폰트를 바꾸고 싶다면 객체부분만 바꿔주면 됩니다.
'공부합시다 > WinAPI, MFC' 카테고리의 다른 글
| [MFC] 프로세스 접근 권한 얻기 (0) | 2009.10.06 |
|---|---|
| [WinAPI] BMP 파일에서 특정색상을 투명하게 출력하기 (0) | 2009.07.06 |
참고 : http://www.ktword.co.kr/abbr_view.php?mgid=125&m_temp1=347
TCP에 대한 자세한 내용은 위의 링크를 참조하면 된다.
1. TCP의 구조
TCP 프레임은 IP datagram에 캡슐화되어 저장되어 있다.
다른 프로토콜과 마찬가지로 헤더와 데이터부분으로 이루어져 있으며, 헤더의 길이는 옵션이 없을 경우 20바이트로 이루어져 있다.
2. 헤더 분석
ㅇ Sourse/Destination Port number
ㅇ Sequence Number (일련번호) 및 Acknowledgement Number (확인번호)
- TCP에 의해 전송되는 데이터 세그먼트의 순서제어를 위해 사용됨
- 32비트이므로 4기가 바이트 크기의 송신 데이터를 위해 일련번호를 붙일 수 있
다. 예를들면, 일련번호 100에 100바이트를 전송하면 다음 패킷의 일련번호는
200이 된다.
| SEQ j (데이터 20) |
| --------------------> |
| ACK j+20 |
| <------------------- |
| SEQ j+20 |
| -------------------> |
ㅇ Header length
- 4 바이트 단위로 표시. 4 비트 길이. 따라서, TCP 헤더 길이는 총 60 바이트
이하임
ㅇ 6 개의 Flag bits ☞ TCP 제어 플래그 참조
- TCP 세그먼트 전달과 관련된 제어 기능을 함. TCP 회선 및 데이터 관리를 위해
사용되는 제어용 플래그
ㅇ window size
- 흐름제어를 위해 사용하는 16 비트 필드 (65,535 bytes까지 가능)
- TCP 흐름제어를 위해서 통신의 상대편에게 자신의 버퍼 크기를 지속적으로 통
보하여주는 기능을 함. 수신측에 의해 능동적으로 흐름제어를 수행하게 됨.
ㅇ Urgent pointer
- TCP 세그먼트에 포함된 긴급 데이터의 마지막 바이트에 대한 일련번호
- urgent pointer는 현재 일련번호(sequence number)로부터 긴급 데이터까지의
바이트 오프셑(offset)을 말한다.
- 해당 세그먼트의 일련번호에 urgent point 값을 더해 긴급 데이터의 끝을 알수
있음
3. TCP 옵션
주요 옵션의 종류
Type 옵 션 내 용
---- -------------------------------------------------------------------
0 End of Option : 옵션 필드의 끝에 패딩(Padding)을 위해 사용
1 No Operatin : 옵션 사이를 채우기 위함
2 Maximum Segment Size (MSS)
: 전송되는 TCP 데이터 세그먼트의 최대 길이, 이더넷은 1460
3 Window Scale factor
4 Selective Acknowledgment Permitted (Selective Reject)
: 여러 패킷 중 손실된 패킷 만 선택적으로 재전송하기 위한 TCP 연결 설정
시의 협상 옵션
5 Selective Acknowledgment Data
8 Timestamp
TCP에 대한 자세한 내용은 위의 링크를 참조하면 된다.
1. TCP의 구조
TCP 프레임은 IP datagram에 캡슐화되어 저장되어 있다.
다른 프로토콜과 마찬가지로 헤더와 데이터부분으로 이루어져 있으며, 헤더의 길이는 옵션이 없을 경우 20바이트로 이루어져 있다.
2. 헤더 분석
ㅇ Sourse/Destination Port number
ㅇ Sequence Number (일련번호) 및 Acknowledgement Number (확인번호)
- TCP에 의해 전송되는 데이터 세그먼트의 순서제어를 위해 사용됨
- 32비트이므로 4기가 바이트 크기의 송신 데이터를 위해 일련번호를 붙일 수 있
다. 예를들면, 일련번호 100에 100바이트를 전송하면 다음 패킷의 일련번호는
200이 된다.
| SEQ j (데이터 20) |
| --------------------> |
| ACK j+20 |
| <------------------- |
| SEQ j+20 |
| -------------------> |
ㅇ Header length
- 4 바이트 단위로 표시. 4 비트 길이. 따라서, TCP 헤더 길이는 총 60 바이트
이하임
ㅇ 6 개의 Flag bits ☞ TCP 제어 플래그 참조
- TCP 세그먼트 전달과 관련된 제어 기능을 함. TCP 회선 및 데이터 관리를 위해
사용되는 제어용 플래그
ㅇ window size
- 흐름제어를 위해 사용하는 16 비트 필드 (65,535 bytes까지 가능)
- TCP 흐름제어를 위해서 통신의 상대편에게 자신의 버퍼 크기를 지속적으로 통
보하여주는 기능을 함. 수신측에 의해 능동적으로 흐름제어를 수행하게 됨.
ㅇ Urgent pointer
- TCP 세그먼트에 포함된 긴급 데이터의 마지막 바이트에 대한 일련번호
- urgent pointer는 현재 일련번호(sequence number)로부터 긴급 데이터까지의
바이트 오프셑(offset)을 말한다.
- 해당 세그먼트의 일련번호에 urgent point 값을 더해 긴급 데이터의 끝을 알수
있음
3. TCP 옵션
주요 옵션의 종류
Type 옵 션 내 용
---- -------------------------------------------------------------------
0 End of Option : 옵션 필드의 끝에 패딩(Padding)을 위해 사용
1 No Operatin : 옵션 사이를 채우기 위함
2 Maximum Segment Size (MSS)
: 전송되는 TCP 데이터 세그먼트의 최대 길이, 이더넷은 1460
3 Window Scale factor
4 Selective Acknowledgment Permitted (Selective Reject)
: 여러 패킷 중 손실된 패킷 만 선택적으로 재전송하기 위한 TCP 연결 설정
시의 협상 옵션
5 Selective Acknowledgment Data
8 Timestamp
'공부합시다 > 소켓프로그래밍' 카테고리의 다른 글
| ether_header 구조체와 iphdr 구조체를 이용한 패킷 분석 (0) | 2009.09.16 |
|---|---|
| 바이트별로 노가다 작업을 통한 패킷 분석-ㅅ-; (1) | 2009.09.16 |
| 패킷 캡쳐로 살펴본 이더넷 프레임 (0) | 2009.09.15 |
| 이더넷 프레임의 구조 (0) | 2009.09.15 |
| pcap_t, pcap_pkthdr 구조체 (0) | 2009.08.21 |
이전 포스팅에서는 바이트별로 직접 골라냈었는데(-ㅅ-;) 이번엔 라이브러리에 있는 구조체를 활용해서 더 쉽게 패킷을 분석해보자.
ether_header 구조체
/usr/include/net/ethernet.h 에 위치한다. (gcc의 버전에 따라 다를 수 있다.)
iphdr 구조체
/usr/include/netinet/ip.h 에 위치한다. (역시 gcc의 버전에 따라 다를 수 있다.)
소스 코드
실행 화면
ether_header 구조체
/usr/include/net/ethernet.h 에 위치한다. (gcc의 버전에 따라 다를 수 있다.)
/* 10Mb/s ethernet header */
struct ether_header
{
u_int8_t ether_dhost[ETH_ALEN]; /* destination eth addr */
u_int8_t ether_shost[ETH_ALEN]; /* source ether addr */
u_int16_t ether_type; /* packet type ID field */
} __attribute__ ((__packed__));
struct ether_header
{
u_int8_t ether_dhost[ETH_ALEN]; /* destination eth addr */
u_int8_t ether_shost[ETH_ALEN]; /* source ether addr */
u_int16_t ether_type; /* packet type ID field */
} __attribute__ ((__packed__));
iphdr 구조체
/usr/include/netinet/ip.h 에 위치한다. (역시 gcc의 버전에 따라 다를 수 있다.)
struct iphdr
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int ihl:4; /* header length */
unsigned int version:4; /* version */
#elif __BYTE_ORDER == __BIG_ENDIAN
unsigned int version:4; /* version */
unsigned int ihl:4; /* header length */
#else
# error "Please fix <bits/endian.h>"
#endif
u_int8_t tos; /* type of service */
u_int16_t tot_len; /* total length */
u_int16_t id; /* identification */
u_int16_t frag_off; /* fragment offset field */
u_int8_t ttl; /* time to live */
u_int8_t protocol; /* protocol */
u_int16_t check; /* checksum */
u_int32_t saddr; /* source address */
u_int32_t daddr; /* dest address */
/*The options start here. */
};
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int ihl:4; /* header length */
unsigned int version:4; /* version */
#elif __BYTE_ORDER == __BIG_ENDIAN
unsigned int version:4; /* version */
unsigned int ihl:4; /* header length */
#else
# error "Please fix <bits/endian.h>"
#endif
u_int8_t tos; /* type of service */
u_int16_t tot_len; /* total length */
u_int16_t id; /* identification */
u_int16_t frag_off; /* fragment offset field */
u_int8_t ttl; /* time to live */
u_int8_t protocol; /* protocol */
u_int16_t check; /* checksum */
u_int32_t saddr; /* source address */
u_int32_t daddr; /* dest address */
/*The options start here. */
};
소스 코드
실행 화면
'공부합시다 > 소켓프로그래밍' 카테고리의 다른 글
| TCP 헤더 분석 (3) | 2009.09.18 |
|---|---|
| 바이트별로 노가다 작업을 통한 패킷 분석-ㅅ-; (1) | 2009.09.16 |
| 패킷 캡쳐로 살펴본 이더넷 프레임 (0) | 2009.09.15 |
| 이더넷 프레임의 구조 (0) | 2009.09.15 |
| pcap_t, pcap_pkthdr 구조체 (0) | 2009.08.21 |
말그대로 제목과 같음
400바이트 이상의 패킷을 캡쳐했을때만 정보 표시 하도록 구현
실행화면
400바이트 이상의 패킷을 캡쳐했을때만 정보 표시 하도록 구현
실행화면
'공부합시다 > 소켓프로그래밍' 카테고리의 다른 글
| TCP 헤더 분석 (3) | 2009.09.18 |
|---|---|
| ether_header 구조체와 iphdr 구조체를 이용한 패킷 분석 (0) | 2009.09.16 |
| 패킷 캡쳐로 살펴본 이더넷 프레임 (0) | 2009.09.15 |
| 이더넷 프레임의 구조 (0) | 2009.09.15 |
| pcap_t, pcap_pkthdr 구조체 (0) | 2009.08.21 |
이번 포스팅에서는 실제 패킷을 캡쳐하여 바이트 별로 분석을 해보자한다.
소스는 아래를 펼쳐보면 알 수 있다.
이전 포스팅에서 얘기했듯이 이더넷 프로토콜 타입에 대한 정보가 패킷내에 존재한다. 이것은 아래의 그림과 같은 모습의 구조를 띄고 있다.
위의 소스를 실제로 돌려봤을 때 다음과 같은 화면을 볼 수 있다. (리눅스에서 구동한 것이다.)
위의 프레임 구조에서 봤듯이 붉은 색으로 표시된 부분은 도착지의 MAC address이며, 파란색으로 표시된 부분은 출발지의 MAC address이다. 이를 ifconfig 명령어로 확인해보면 출발지의 값이 다음과 같이 동일하다는 것을 알 수 있다.
도착지 다음의 2바이트는 이더넷 타입을 나타내는 0x0800은 IP를 뜻한다.
(2009/09/15 - [소켓프로그래밍] - 이더넷 프레임의 구조 를 참조하자.)
그럼 IP 헤더에 대해 다시 알아보자.
< IP 헤더 >
1. IP 헤더 사이즈
- 헤더 사이즈는 만일 옵션 미지정시 20바이트이다.
- 즉, 최소 20 바이트란 말이며, 최대는 24바이트이다.
- IPv6의 경우는 40바이트가 최소이다.
2. IP 헤더 구성
이를 캡쳐한 화면과 비교해보자.
1. Version (4 bits)
- 0x0800 다음에 오는 4비트는 IP 버전을 뜻한다. 4 이므로 IPv4임을 알 수 있다.
2. Header Length (4 bits)
- 다음 4비트는 헤더의 길이를 뜻한다. 최소 5부터 15까지의 값을 가진다.
- 이 값을 왼쪽으로 비트 쉬프트를 2번 해준 값이 헤더의 길이가 된다.
- 위의 경우에는 5이므로 5<<2 의 값은 20 이므로 20이 된다.
- 헤더의 최대 값은 15<<2 즉, 60이 된다. 따라서 헤더의 크기 범위는 20~60.
3. Type of Service (ToS) Flag (8 bits)
- 요구되는 서비스 품질을 나타내나, 현재 대부분의 시스템에서는 이 필드를 무시한다.
4. Total Packet Length (16 bits)
- IP 패킷 전체의 길이를 바이트의 수로 나타낸다. 최대 값은 0xFFFF = 65535.
- 위의 그림에서는 0x004C = 76 bytes.
5. Fragment Identifier (16 bits)
- 각 조각이 동일한 데이터그램에 속하면 같은 일련번호를 공유한다.
6. Fragmentation Flag (3 bits) : 분열의 특성을 나타내는 플래그
- 첫번 째 bit : 미사용 (항상 0)
- 두번 째 bit : DF bit, Don't Fragment
분열(조각) 0, 미분열 1
1로 셋팅되면 목적지 컴퓨터가 조각들을 다시 모을 능력이 없기 때문에
라우터로 하여금 데이터그램을 단편화하지 말라는 뜻이다.
0으로 셋팅되면 라우터에서 분열(조각, 단편)이 가능함을 뜻한다.
- 세번 째 bit : MF bit, More Fragment
현재의 조각이 마지막이면 0, 더 많은 조각이 뒤에 계속 있으면 1
- 위의 그림에서는 0x4 = 0100(2) 에서 상위 3비트 이므로 010이다.
- 첫번 째 비트는 위에서 설명한바와 같이 0이고, 두번째는 1이므로 미분열이란 뜻이고,
세번 째는 0이므로 뒤에는 더이상의 조각이 없다는 뜻이다..
7. Fragmentation offset (13 bits)
- 조각나기 전 원래의 데이터그램의 8 바이트 단위의 위치
- 위의 경우에서는 0x40 = 0100 0000(2) 에서 6번에 얘기한 상위 3비트 뒤에 오는 5비트와 그 이후의 8비트 0x00 이므로, 0 이다. (조각나지 않은 데이터 이므로 0)
소스는 아래를 펼쳐보면 알 수 있다.
이전 포스팅에서 얘기했듯이 이더넷 프로토콜 타입에 대한 정보가 패킷내에 존재한다. 이것은 아래의 그림과 같은 모습의 구조를 띄고 있다.
위의 소스를 실제로 돌려봤을 때 다음과 같은 화면을 볼 수 있다. (리눅스에서 구동한 것이다.)
위의 프레임 구조에서 봤듯이 붉은 색으로 표시된 부분은 도착지의 MAC address이며, 파란색으로 표시된 부분은 출발지의 MAC address이다. 이를 ifconfig 명령어로 확인해보면 출발지의 값이 다음과 같이 동일하다는 것을 알 수 있다.
도착지 다음의 2바이트는 이더넷 타입을 나타내는 0x0800은 IP를 뜻한다.
(2009/09/15 - [소켓프로그래밍] - 이더넷 프레임의 구조 를 참조하자.)
그럼 IP 헤더에 대해 다시 알아보자.
< IP 헤더 >
1. IP 헤더 사이즈
- 헤더 사이즈는 만일 옵션 미지정시 20바이트이다.
- 즉, 최소 20 바이트란 말이며, 최대는 24바이트이다.
- IPv6의 경우는 40바이트가 최소이다.
2. IP 헤더 구성
이를 캡쳐한 화면과 비교해보자.
1. Version (4 bits)
- 0x0800 다음에 오는 4비트는 IP 버전을 뜻한다. 4 이므로 IPv4임을 알 수 있다.
2. Header Length (4 bits)
- 다음 4비트는 헤더의 길이를 뜻한다. 최소 5부터 15까지의 값을 가진다.
- 이 값을 왼쪽으로 비트 쉬프트를 2번 해준 값이 헤더의 길이가 된다.
- 위의 경우에는 5이므로 5<<2 의 값은 20 이므로 20이 된다.
- 헤더의 최대 값은 15<<2 즉, 60이 된다. 따라서 헤더의 크기 범위는 20~60.
3. Type of Service (ToS) Flag (8 bits)
- 요구되는 서비스 품질을 나타내나, 현재 대부분의 시스템에서는 이 필드를 무시한다.
4. Total Packet Length (16 bits)
- IP 패킷 전체의 길이를 바이트의 수로 나타낸다. 최대 값은 0xFFFF = 65535.
- 위의 그림에서는 0x004C = 76 bytes.
5. Fragment Identifier (16 bits)
- 각 조각이 동일한 데이터그램에 속하면 같은 일련번호를 공유한다.
6. Fragmentation Flag (3 bits) : 분열의 특성을 나타내는 플래그
- 첫번 째 bit : 미사용 (항상 0)
- 두번 째 bit : DF bit, Don't Fragment
분열(조각) 0, 미분열 1
1로 셋팅되면 목적지 컴퓨터가 조각들을 다시 모을 능력이 없기 때문에
라우터로 하여금 데이터그램을 단편화하지 말라는 뜻이다.
0으로 셋팅되면 라우터에서 분열(조각, 단편)이 가능함을 뜻한다.
- 세번 째 bit : MF bit, More Fragment
현재의 조각이 마지막이면 0, 더 많은 조각이 뒤에 계속 있으면 1
- 위의 그림에서는 0x4 = 0100(2) 에서 상위 3비트 이므로 010이다.
- 첫번 째 비트는 위에서 설명한바와 같이 0이고, 두번째는 1이므로 미분열이란 뜻이고,
세번 째는 0이므로 뒤에는 더이상의 조각이 없다는 뜻이다..
7. Fragmentation offset (13 bits)
- 조각나기 전 원래의 데이터그램의 8 바이트 단위의 위치
- 위의 경우에서는 0x40 = 0100 0000(2) 에서 6번에 얘기한 상위 3비트 뒤에 오는 5비트와 그 이후의 8비트 0x00 이므로, 0 이다. (조각나지 않은 데이터 이므로 0)
※ 위 3개의 필드 (Fragment Identifier,Fragmentation Flag,Fragmentation Offset)(5, 6, 7)는 조각(분열)과 재배열과 관련된 필드이다. 각 조각들은 최종 목적지 시스템에 전달되기 전에는 재배열되지 않고, 최종 목적지에 전달되면 목적지 시스템의 IP 소프트웨어가 원래의 데이터그램으로 재배열한다.
8. TTL, Time To Live (8 bits) - IP 패킷의 수명 - 즉, 네트워크 상에서 패킷이 남아있을 시간이다. 점점 감소하게 된다. - 위의 그림에서는 0x40 이므로 64이다.
9. Protocol Identifier (8 bits) - 어느 상위 계층 프로토콜이 데이터 내에 포함되었는가를 나타낸다. - 프로토콜의 번호들은 다음의 사이트에서 확인할 수 있다. http://www.iana.org/assignments/protocol-numbers/ - 위의 경우는 0x06 이므로, TCP 프로토콜이란 것을 알 수 있다.
10. 헤더 검사합 checksum (16 bits) - 헤더에 대한 오류 검사를 위한 비트이다. - 위의 그림에서는 0x4540 이다.
11. source IP Address (32 bits) - 송신처 주소
12. Destination IP Address (32 bits) - 수신처 주소
13. IP 헤더 옵션 (선택옵션, 가변 길이 bits)
14. Padding (필요한 경우에만 사용, 가변 길이 bits)
'공부합시다 > 소켓프로그래밍' 카테고리의 다른 글
| ether_header 구조체와 iphdr 구조체를 이용한 패킷 분석 (0) | 2009.09.16 |
|---|---|
| 바이트별로 노가다 작업을 통한 패킷 분석-ㅅ-; (1) | 2009.09.16 |
| 이더넷 프레임의 구조 (0) | 2009.09.15 |
| pcap_t, pcap_pkthdr 구조체 (0) | 2009.08.21 |
| [소켓프로그래밍] WSAAsyncSelect (0) | 2009.07.09 |
자료 출처 : http://www.ktword.co.kr/abbr_view.php?mgid=014&m_temp1=2965
1. 개요
Ethernet Protocol Type 이란 이더넷 패킷내의 데이터부분에서 캡슐화된 데이터가 어느 프로토콜에 해당하는지를 나타내고자, 13~14번째 바이트에 이를 표시하는 영역을 말한다.
2. 이더넷 프레임의 통상적인 형식 : IEEE 802.3 또는 DIX 2.0
- Preamble(10101...) 및 SFD(10101011) : 10101......10101011
- D A : Destination Address, S A : Source Address ☞ MAC 주소
- Len/Type : 0x 600 이상이면 Type (DIX 2.0), 이하이면 Length (802.3) 로 해석
. Length : 길이(3~1500 바이트)를 나타냄 ☞ MTU
. Type : Data에 담겨있는 상위 프로토콜 ☞ Ethertype
- Type의 대표적인 값들 (0x600 이상의 값 만이 가능함)
0600h Xerox XNS IDP
0800h IP
0805 X.25
0806h ARP
0835h RARP
6003h DEC DECnet Phase Ⅳ
8137h Novell Netware IPX
8191h NetBIOS
8847h MPLS
8863h PPPoE Discovery Stage
8864h PPPoE PPP Session Stage
4. 각 프레임의 형태
5. 참고사항
ㅇ 위 프레임들 간의 주요한 차이는,
MAC 부계층 바로 상위계층인 LLC 부계층 관련 부분(3 바이트)의 포함 여부에 있
다. (DIX Ethernet frame : 미포함, IEEE 802.3 frame : 포함)
ㅇ 각 바이트별 비트들의 송신 순서
- 이더넷 프레임의 각 바이트의 비트들은 FCS를 제외하고, 모두 LSB 부터 송신된다.
1. 개요
Ethernet Protocol Type 이란 이더넷 패킷내의 데이터부분에서 캡슐화된 데이터가 어느 프로토콜에 해당하는지를 나타내고자, 13~14번째 바이트에 이를 표시하는 영역을 말한다.
2. 이더넷 프레임의 통상적인 형식 : IEEE 802.3 또는 DIX 2.0
- Preamble(10101...) 및 SFD(10101011) : 10101......10101011
- D A : Destination Address, S A : Source Address ☞ MAC 주소
- Len/Type : 0x 600 이상이면 Type (DIX 2.0), 이하이면 Length (802.3) 로 해석
. Length : 길이(3~1500 바이트)를 나타냄 ☞ MTU
. Type : Data에 담겨있는 상위 프로토콜 ☞ Ethertype
- Type의 대표적인 값들 (0x600 이상의 값 만이 가능함)
0600h Xerox XNS IDP
0800h IP
0805 X.25
0806h ARP
0835h RARP
6003h DEC DECnet Phase Ⅳ
8137h Novell Netware IPX
8191h NetBIOS
8847h MPLS
8863h PPPoE Discovery Stage
8864h PPPoE PPP Session Stage
4. 각 프레임의 형태
5. 참고사항
ㅇ 위 프레임들 간의 주요한 차이는,
MAC 부계층 바로 상위계층인 LLC 부계층 관련 부분(3 바이트)의 포함 여부에 있
다. (DIX Ethernet frame : 미포함, IEEE 802.3 frame : 포함)
ㅇ 각 바이트별 비트들의 송신 순서
- 이더넷 프레임의 각 바이트의 비트들은 FCS를 제외하고, 모두 LSB 부터 송신된다.
'공부합시다 > 소켓프로그래밍' 카테고리의 다른 글
| 바이트별로 노가다 작업을 통한 패킷 분석-ㅅ-; (1) | 2009.09.16 |
|---|---|
| 패킷 캡쳐로 살펴본 이더넷 프레임 (0) | 2009.09.15 |
| pcap_t, pcap_pkthdr 구조체 (0) | 2009.08.21 |
| [소켓프로그래밍] WSAAsyncSelect (0) | 2009.07.09 |
| [소켓프로그래밍] setsockopt (0) | 2009.07.08 |
Prev
Rss Feed