윈도우 XP 의 메모장 비밀 두가지

윈도우 XP 에서 노트패드와 관련한 재미있는 것을 알게 되었다. 나만 모르고 있었던 건지는 모르지만, 노트패드의 비밀 두가지를 소개하면 다음과 같다 :

1) 로그 정보 기록

1. 메모장을 오픈한다.
2. 첫 번째 라인에 ".LOG" 라고 입력한다. ( " 는 제외) 그리고 엔터를 입력하여 다음 라인으로 넘긴다.
3. 바로 저장하고 끝내도 되고 또는 필요한 텍스트 정보를 더 입력하여도 된다.
4. 그리고 다시 해당 파일을 오픈 하면 다음과 같이 시간과 날짜 정보가 나타난다. (시간은 오픈할때 마다 계속 바뀐다)

예제>
.LOG

오후 11:56 2011-03-29


2) 텍스트를 읽을 수 없는 상태로 만들기

1. 메모장을 오픈한다.
2. 첫 번째 라인에, "dont eat the donut" 라고 입력하고 저장한다.  ( " 는 제외) 다음 라인으로 넘어가서는 안되며, 한 라인만 있어야 한다.
3. 다시 해당 파일을 열어보면, 원래의 메시지를 읽을 수 없는 상태로 이상한 문자가 표시된다.

윈도우 XP에서는 정상적으로 다 수행되며, 윈도우 7 에서 테스트 해보니 1번째 방법만 가능하다.

잠깐 쉬어갈겸, 한번 해보는 것은 어떨까 한다. 머, 사실 별로 쓸데는 없지만 과연 될까 하고 실행해 봤는데, 잘 된다. 과거 '이스트에그' 라고 해서 요렇게 재밌는 기능을 넣어놓은것이 많았는데 오랜만에 보게 되니 그냥 재밌다.  이 글을 간단히 쓰고, 대충 찾아보니 알려진지는 꽤 오래되었다는 사실. ㅋㅋ

그래도 모르시는 분들에게는 ~

오래간만에 실행해본 와이어샤크 리눅스 버전

리눅스 환경에서는 와이어샤크 GUI 버전을 크게 사용할 일이 없었다. 거의 모든 작업이 터미널 기반으로 이뤄지다 보니, tshark 만 주로 이용하였을 뿐이었다. 그러다 최근 실행해 본 GUI 화면이다. 1.4 버전은 아니고 1.2 버전이다. 컴파일을 새로 하려니 필요한 것들도 많고 하다 보니, 맘 편히 그냥 패키지로 설치하여서 버전이 조금 낮다.

눈에 들어오는건, 윈도우 환경보다 더 직관적으로 잘 보이는것 같다. 별 차이는 없는데, 그냥 느낌이 그렇다 :-)

P.S IP 주소는 tcpdpriv 로 랜덤한 IP 로 변경된 것이다. tcpdpriv 가 궁금하다면 패킷인사이드에서 검색해 보면 된다.

패킷을 보다 자주 접하는 캡슐화(Encapsulation)는 무엇이지?

네트워크 패킷 분석을 하다가 또는 도구를 사용하다 보면, 그 과정에서 인캡슐레이션(Encapsulation) 이라는 용어를 자주 보게 된다. 그런데, 이 인캡슐레이션 이라는 것은 무엇인가? 말은 많이 들어본것 같은데, 딱히 개념이 잘 서지 않는다면 지금 이 글을 집중하시면 된다.

일단, Encapsulation 은 영어 단어이므로 사전적 의미부터 한번 살펴보자. '명사' 로 의학과 관련된 피포, 피막형성이라는 뜻을 가지고 있다. 아니, 이런 단어가 왜 IT 에서 많이 사용되는 것과 밀접한 연관이 있는 것일까.
컴퓨터 관점에서 보면 이 것은 흔히 '캡슐화' 라고 불린다. 통신 상에서 상위계층의 툥신규약 정보를 하위 통신 규약 프레임 사용자 정보영역에 내장시켜 전송하는 기술이라고 네이버 용어사전에 정의되어 있다.

자바에서도 캡슐화라는 것이 이용되는데 클래스나,멤버에 private, public 같은 키워드를 이용해서 접근 제어를 사용하는데 바로 이것을 객체지향개념의 캡슐화 라고 볼수 있다. 자바에서 이렇게 사용하는 이유는 클래스의 내부에 선언된 데이터를 보호하기 위함이다.

다시 TCP/IP 네트워크 관점으로 돌아와 간단하게 생각해 보면 encapsulation 은 이렇다. TCP/IP 의 하위 레이어의 프로토콜 정보에 상위 레이어 데이터,헤더 정보를 캡슐화 하는 것이다. 이 캡슐화 라는 것을 Wrap 한다고 보면 된다. 우리가 음식물을 보관하기 위해 랩을 해서 싸는 것과 같이 말이다.

이렇게 캡슐화된 정보는 네트워크 디바이스를 통해 전송되고, 도착지에서는 캡슐화와 반대로 이 랩을 풀어내는 Decapsulation 을 수행한다. 이런 작업을 통해서 이기종 장비간에도 상호 표준 프로토콜 규약을 지키면서 데이터 통신을 할 수 있는 것이다. 이 작업들이 OSI 7 Layer 를 이해하면 더욱 이해가 쉬어진다. 자세한 OSI 7 Layer 는 추후에 설명하기로 하고, 아래 그림을 살펴보자

[출처] home-network-help.com

컴퓨터 A 에서 -> 컴퓨터 B 로 데이터를 전송하기 위해서는 일단 상위계층인 Application 레이어 (프로그램) 에서 Transport 레이어 단으로 내려간다. 하위 레이어로 전송하기 위해서는 다시 TCP 헤더와 데이터 정보를 캡슐화하여 내려 보내고 IP 레이어 단에서는 다시 IP 헤더 정보를 추가하여 하위 레이어로 다시 내려보낸다. 즉, 내려가면서 각 필요한 헤더가 붙으면서 캡슐화가 이뤄지는 것이다. 반대로 컴퓨터 B 가 이 데이터를 받으면, 상위 레이어로 올라갈때마다 캡슐화된 헤더 정보등을 제거하면서 전달되는 것이다. 이렇게 하여 최종 적인 정보 전달이 완료되는 것이다. 

이런 캡슐화는 네트워크 관점에서 보면 많이 이용되고 있는데, IPv6 의 터널링 에서도 IPv4 망에서 IPv6 를 이용할 수 있도록 해당 데이터를 통신 과정에 맞게 캡슐화한다. 또는 ATM 프레임 망에서 TCP/IP 형태의 데이터를 통신할 수 있도록 TCP/IP 패킷을 ATM 프레임 구조에 맞게 캡슐화한다. 데이터 구조가 다르더라도 이런 캡슐화를 통해 이기종 네트워크 기기 간에 통신 구현이 가능한 것이다.

알고보면 어렵지 않은 것이 이 캡슐화며, 또 우리의 네트워크를 더 윤택하게 해주고 있는 것이기도 하다. 

From Rigel

:-)

리눅스 커널 2.6.38 에 포함된 XPS(Transmit Packet Steering)는 무엇이지?

최근 리눅스커널 2.6.38 버전이 공개되었다. 이번 2.6.38 의 주요 변화중 눈에 띄는것이 XPS 였다.

XPS 는 Transmit Packet Steering 으로, 네트워크 카드의 멀티 큐 기능을 소프트웨어 구성요소가 프로세스 코어와 연관되어 큐를 사용할 수 있도록 한 것이라고 정의하고 있다. 그 결과, 특정 상황에서는 프로세서 캐쉬의 효율을 가져오고, 이것은 결국 네트워크 카드의 데이터 처리량을 증가시킨다는 것이다. XPS 의 기본 아이디어는 RPS 를 기본으로 하고 있다고 한다.

RPS 는 Receive Packet Steering 으로 커널 2.6.35 에 RFS(Receive Flow Steering) 와 함께 들어간 기능이다.

개발자의 테스트에 의하면 16 개의 프로세서 코어에서 XPS 는 20 퍼센트 정도 향상된 성능을 보였다고 한다.
이번 패치는 구글에서 일하는 개발자에 의해 개발된 것이고, 구글은 현재 TCP 스택의 기본 설정값들이 현재의 인터넷 환경하고는 이상적이지 않은 부분이 있어, 앞으로도 구글 개발자는 수정된 패치를 제공할 예정이라고 한다. 2.6.38 커널의 config 를 보면

CONFIG_RPS=y 아래에
CONFIG_XPS=y 가 설정되었음을 확인할 수 있다.

참고로, 커널 2.6.39 에서는 초기 congestion window 을 좀더 크게 조정한 패치를 추가될 것이라고 하며 이로 인해 10% 정도 네트워트 통신 대기시간을 줄일 수 있을것으로 예상된다. 이와 관련한 자세한 것은 LWN 기사중 "Increasing the TCP initial congestion window" 를 참고해 보면 된다.

http://lwn.net/Articles/427104/

이런것들을 보면 구글이 생각하는 범위는 작은 것부터 시작해 큰 것까지 소홀히 하는 부분이 없다는 것을 느낀다. 우리 라면 어땠을까? 그냥 주어진 OS 환경 대로 사용하는 경우가 대부분이 아닐까? 하드웨어, 주변 시스템 동작 환경, 운영체제, 클러스트 등 그들이 사용하는 기술이 안겨주는 느낌은 정말 '이게 최선입니까? ' 를 느끼게 할 만큼 노력한다는 것이 보여진다. 물론, 필자만의 생각이다.

[참고]
1. xps: Transmit Packet Steering
http://lwn.net/Articles/412062/
2. The Linux Kernel Archives
http://www.kernel.org/

일본 지진에 의한 해저 케이블 손상과 인터넷 지연

이번에 발생한 일본의 강진으로 해외 인터넷 사이트 연결이 지연되거나 끊기는 일이 발생했다. 물론, 이와 관련한 여러 보도기사도 많이 나왔기 때문에 이러한 원인에 대해서는 이미 알고 있을 것이다.

한국-일본-미국간의 해저케이블이 일부 손상되면서 발생된 것으로, 지진으로 인한 피해가 비단 일본뿐만 아니라 해당 해저케이블을 이용하는 곳에 영향을 주고 있다. 해저케이블이란? 간단히 대륙과 대륙, 육지, 섬등과 같이 바다를 사이로 격리된 두 지점 사이가 해저에 설치된 케이블로 연결된 것이다.
해저에 설치된 케이블 이기 때문에 어업활동에 의한 닻 등에 의해 파손되기도 하고, 이번 지진과 같은 영향으로 큰 피해를 입기도 한다.

피해현황을 좀더 자세히 알기 위해 기사를 좀 찾아보았다. 일단, 미국과 일본의 JUCN 케이블과 일본-동남아의 APCN 이 손상돼 국내에 타격을 주었다고 한다. 일본이 아시아와 북미간 통신 네트워크 관문이라는 것은 어느정도 알고 있었지만, 케이블 연결현황을 살펴보니 북미쪽과의 연결이 일본하고 많이 연결되어 있었다.

[출처] TeleGeography (http://www.telegeography.com/)


리서치기관인 Telegeography 사에 의하면 현재 손상된 케이블은 다음과 같다:

• APCN-2, which is an intra-Asian cable, forms a ring linking China, Hong Kong, Japan, the Republic of Korea, Malaysia, the Philippines, Singapore and Taiwan.
• Pacific Crossing West and Pacific Crossing North, which are out of service.
• PacNet has reported outages on segments of its East Asia Crossing network.
• Korea Telecom reports that a segment of the Japan-U.S. Cable Network is damaged
• NTT has reported damage to some segments of the PC-1 submarine cable system.

이번 일본 지진에 의한 해저 케이블 손상을 보니 2009년의 태풍 모라꼿에 의한 대만 해저케이블 손상도 생각이 났는데. 그 당시 중국 전역에 인터넷 서비스가 차질을 빚고 한국,미국,일본 등지로 연결된 국제 통신 서비스도 영향을 받았다고 한다. 아무래도 해저 광케이블을 통한 의존도가 상대적으로 높고, 단순히 전화 통신이외에 인터넷과 같은 데이터가 중요하게 자리잡고 있는 만큼, 케이블 손상은 통신에 있어 큰 문제를 가져올 수 있다.

이번 사고를 계기로 통신시장에서 해저 케이블이 차지하고 있는 비중이 얼마나 큰지 새삼 다시 느끼게 되었다. 그리고 패킷이 흘러갈 곳이 없다면, 패킷인사이드가 존재할 이유도 없는 것이고 :-0

아, 그리고 이번 지진으로 인해 큰 상처를 입은 일본 국민들에게 힘내라고 전해주고 싶다.

HTTP 패킷 정보에서 호스트별 통계정보를 쉽게 뽑아보기

전달받은 패킷 파일을 열어보았더니, 대부분이 HTTP 트래픽이다. 그런데, 이 데이터는 특정 사이트 몇 군데를 대상으로 한 DDoS 트래픽으로 추정된다.  자 , 이렇게 가정해 보고 각 사이트별로 트래픽이 얼마나 발생되었는지 데이터를 추출해 본다면 어떻게 해야 할까?

지금 여러분들의 머리속에 딱 떠오르는 방법은 무엇인가? HTTP 프로토콜의 호스트 필드 헤더가 있으니 이걸로 필터를 걸어 일일이 다 추출해야 하나? 아니면 프로그램을 간단히 작성해야 하는가. 방법은 여러가지가 있을 것 같은데 막상 하려니 정리가 잘 되지 않는다면 와이어샤크에서 제공하는 통계 정보를 이용해 쉽게 얻을 수 있다.

앞서 여러 포스팅에서도 와이어샤크의 Statistics 의 몇 가지 기능에 대해서 소개한 적이 있다. 이럴때 가장 쉽고 빠르게 통계 데이터를 알아낼 수 있는 방법은 Statistics -> HTTP -> Requests... 메뉴를 이용하면 된다.  선택하게 되면 필터를 걸수 있는 화면이 나오는데, 전체를 대상으로 할 것이므로 그냥 'Create Stat' 를 바로 누르면 아래와 같은 정보를 볼 수 있다.

HTTP 호스트별로 구분하여 전체 Count 가 얼마이며, 전체 패킷중 몇 % 를 차지하고 있는지도 보여준다. 급하게 필요하여 사용하려고 하면 떠오르지도 않고, 빨리 호스트별로 트래픽 정보를 산출하고자 할때는 이만한게 없다. 

기본기능만 잘 알아두어도 패킷분석의 반은 끝난다. 더불어, 패킷인사이드 내용만 머리속에 잘 기억해 두어도 나중에 언젠가는 유용하게 사용될 것이다.   :-)

From Rigel

와이어샤크 개발자/사용자 컨퍼런스 - SharkFest '11

패킷인사이드에서는 소개한 적이 없는것 같은데, 와이어샤크 개발자, 사용자 컨퍼런스가 있다. 이름하여 SharkFest 이다. 이번 2011 년에도 어김없이 열리며, 장소는 미국의 스탠포드 대학으로 2011년 6월13-16 일 까지 열린다. 미처 소개한다는 것이 계속 미루다 보니 3월15일이 사전등록 마감이다. 지금이 한국시간으로 3월15일이니, 등록하실 분들은 빨리 서둘러 주시길.

3일동안의 컨퍼런스 비용은 $695 이며, 사전등록하면 $595 이다.

컨퍼런스 등록과 관련한 자세한 내용은 다음 사이트를 참고하면 된다 :

http://sharkfest.wireshark.org/

패킷분석과 와이어샤크에 관한 많은 내용을 얻을 수 있는 컨퍼런스로 생각되며,
개인적으로도 기회가 주어지면 한번 가보고 싶다. 과거 컨퍼런스 자료도 살펴볼 수 있는데,
패킷 분석과 관련한 좋은 내용이 참 많다. 혹시 참석해 보셨거나, 참석할 예정이라면 패킷인사이드에 살짝 공유 부탁드려요 ~

VMWare 에서 지정한 스냅샵이 동작하지 않는 경우

VMWare 가상 머신 중 하나가 동작이 이뤄지지 않았다. 에러메시지는 아래와 같았다:

Detected an invalid snapshot configuration

File <unspecified filename>was not found

아무 문제없이 잘 동작하던 가상 머신에 왜 이런일이 나타난 것일까? 콘솔로 로그인 하여 검토하던 중 vmx 파일에서 문제를 발견하였다.

vmx 파일 내용중 가상머신 파일인 vmdk 를 지정한 부분이 있다.

scsi0:0.fileName = "VirtualMachine-000001.vmdk"

실제 존재하는 vmdk 는 000002 였으나, 어찌된 영문인지 000001로 되어 있었다.  000002로 변경하고 가상머신을 동작시키니 정상적으로 동작한다.

무슨 이유에서인지, fileName 에 지정한 vmdk 가 존재하지 않는 것으로 변경이 되어 있었던 것이다.
혹시 위와 같은 메시지를 보게되면 살펴보기 바란다.

VMWare ESX 볼륨 디스크를 변경하는 경우, 이미지 재 설정하기

VMWare ESX 를 사용하는 도중, 마운트된 볼륨 한개의 하드디스크를 교체할 이유가 있었다. 단순한 생각으로는, 새로 들어가는 디스크에 똑같이 그대로 복사해 주면 일단 동작할 수 있지 않을까 생각했다. 새로 다시 이미지를 생성하는 일은 힘들기 때문에 어찌되었든, 기존 이미지를 그대로 유지해야만 했다.

이미지를 카피만 한 후, vSphere 클라이언트에서 확인해 보면 기 존재했던 가상머신 리스트들이
Unknown (inaccessible) 하고 흐릿하게 되어 있었다. 즉, 실행을 시킬 수 없다. 일단,
콘솔로 로긴하여 볼륨을 확인했다.

아래것은 기존에 존재하던 볼륨의 출력화면인데, Storage4 가 교체된 디스크이다.
drwxr-xr-t 1 root root 4060 Dec  2 11:49 4cf5def9-58109560-9ac8-0022196ba845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage1 -> 4bdad755-e0b14358-4a7f-00[삭제]843
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage2 -> 4bdfd27b-72617197-994f-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage3 -> 4bdeccc2-cb8a6f83-4f2a-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage4 -> 4cf5def9-58109560-9ac8-00[삭제]845

아래와 같이 확인해 보면 새로 구성한 볼륨의 UUID 값이 변경되었다.

# ls -l /vmfs/volumes/
total 4096
drwxr-xr-t 1 root root 5460 Dec  2 19:09 4bdad755-e0b14358-4a7f-00[삭제]843
drwxr-xr-t 1 root root 2940 Dec  6 14:15 4bdeccc2-cb8a6f83-4f2a-00[삭제]845
drwxr-xr-t 1 root root 5740 Dec  2 12:14 4bdfd27b-72617197-994f-00[삭제]845
drwxr-xr-t 1 root root 1120 Dec  6 15:41 4cfc855d-9bad2bdf-bb1b-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage1 -> 4bdad755-e0b14358-4a7f-0[삭제]843
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage2 -> 4bdfd27b-72617197-994f-0[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage3 -> 4bdeccc2-cb8a6f83-4f2a-0[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage4 -> 4cfc855d-9bad2bdf-bb1b-0[삭제]845

Storage4 번에 있던 이미지들이 제대로 엑세스 할 수 없는 환경임을 추정해 볼 수 있다.
아래 경로의 xml 파일을 확인해 보면, 각 가상머신에 대한 경로가 기록되어 있다.

/etc/vmware/hostd/vmInventory.xml

해당되는 디스크에 속해있던 디스크 UUID 값으로 변경해주고,

  <ConfigEntry id="0084">
    <objID>2864</objID>
    <vmxCfgPath>/vmfs/volumes/4cfc855d-9bad2bdf-bb1b-00[삭제]845/Image110/Image110.vmx</vmxCfgPath>
  </ConfigEntry>

다시 재 반영해 주기 위해 mgmt-vmware 를 통해 재시작을 시켜주었다.

# ./mgmt-vmware restart
Stopping VMware ESX Management services:
   VMware ESX Host Agent Watchdog                          [  OK  ]
   VMware ESX Host Agent                                   [  OK  ]
Starting VMware ESX Management services:
   VMware ESX Host Agent (background)                      [  OK  ]
   Availability report startup (background)                [  OK  ]

이후 vSphere Client 프로그램을 통해 보면 기존에는 접근할 수 없었던 이미지가 이제 접근이 된다. 파워온을 하면 한가지 confirm 을 요청하는 것을 물어보고

OK 를 해주면 이제 정상적으로 동작이 된다. 디스크를 교체하게 되면서, 빠르게 기존 이미지를 그대로 복구할 수 있는 방법을 찾다보니 그냥 이렇게 간단히 문제가 해결될 수 있다.

비슷한 경우를 겪는 분들이라면 참고하길 바란다.

(IN)SECURE 보안 매거진 ISSUE 29 가 나왔어요!

(IN)SECURE 매거진 ISSUE 29 가 나왔습니다. 이번 3월달에 나온 것인데, 재미있는 내용들이 많이 있으니 보안에 관심있는 분들은 한번 살펴보시기 바랍니다. 해당 홈페이지는 아래와 같습니다:

http://www.net-security.org/insecuremag.php

그리고, 이번 호에 실린 주제는 다음과 같습니다. 패킷쪽에 관심이 있다면, PacketWars 라는 주제가 제목만 보고 눈에 띄이네요.

• Virtual machines: Added planning to the forensic acquisition process
• Review: iStorage diskGenie
• Managers are from Mars, information security professionals are from Venus
• PacketWars: A cyber security sport for a cyber age
• Q&A: Graham Cluley on Facebook security and privacy
• Financial Trojans: Following the money
• Mobile encryption: The new frontier
• Report: RSA Conference 2011
• Combating public sector fraud with better information analysis
• Q&A: Stefan Frei on security research and vulnerability management
• The expanding role of digital certificatesÉ in more places than you think
• 5 questions to ask when reevaluating your data security solution
• How to achieve strong authentication on the Web while balancing security, usability and cost

PDF 주소는 : http://www.net-security.org/dl/insecure/INSECURE-Mag-29.pdf

구글에 접속하는 IPv6 사용자는 얼마나 될까?

오늘 잠깐 소개하고자 하는 것은 구글에서 제공하는 IPv6 Statistics 이다. 구글은
필자가 느끼기에 IPv6 환경에 대해서 많이 준비하고 있다는 느낌을 받는 기업중에 하나이다.
다음 URL 을 방문해 보면, 구글사용자들에 대한 IPv6 현황 그래프를 볼 수 있다.

Google IPv6 Statistics : http://google.com/ipv6

[출처] 구글 IPv6

2008년 9월부터 구글 사용자들이 IPv6 로 접속한 것을 통계낸 것이다. 그래프를 보면
Native 가 있고 6to4 나 Teredo 와 같은 터너링을 이용한 것으로 나뉘어 있는데,
2011년 2월 24일 기준의 상황을 보면 전체 IPv6 는 0.26 %이다.  아직까지는 IPv6 이용자가
아주 미미 하지만, IPv4 할당이 곧 중지되는 만큼 IPv6 접속량은 점차 크게 증가되리라 예상된다.

참고로, 여기서 IPv6 통계를 내고 있는 것은 다음 문서를 참고하면 더욱 자세히 알 수 있다.

Evaluating IPv6 adoption in the Internet
http://www.google.com/research/pubs/archive/36240.pdf

P.S 최근 3월3일 발생한 DDoS 공격으로 떠들석하다. 이번 DDoS 건이 마무리되고 하면, 2009년의 7.7 대란과 함께 네트워크 관점에서 살펴볼까 한다. 어여 빨리 DDoS 사건이 잘 마무리 되어야 편해질텐데 말이다.

와이어샤크 1.4.4 , 1.2.15 버전 릴리즈

와이어샤크 최신버전인 1.4.4 와 1.2.15 가 릴리즈 되었다.

1.4.4 와 1.2.15 에서 몇가지 보고된 취약점이 Fix 되었다.  조작된 pcap-ng 파일을 읽는
과정에서 발생되는 문제점과 pcap-ng 의 큰 패킷 길이등에 의한 취약점이다.
이외 몇 가지 메모리 관련 버그 및 기타 사항등이 업데이트 되었으며,
세부적인 내용은 다음 릴리즈 노트를 참고하면 된다.

[와이어샤크 1.4.4 릴리즈 노트]
http://www.wireshark.org/docs/relnotes/wireshark-1.4.4.html
[와이어샤크 1.2.15 릴리즈 노트]
http://www.wireshark.org/docs/relnotes/wireshark-1.2.15.html

다운로드는 아래 경로에서 할 수 있다.

http://www.wireshark.org/download.html