yarrick/iodineDNS 서버를 통해 IPv4 데이터를 터널링하여 방화벽 제한을 우회하고 침투 테스트를 위한 은밀한 네트워크 접근을 제공합니다.
이 소프트웨어는 DNS 서버를 통해 IPv4 데이터를 터널링할 수 있게 해주는 도구입니다. 인터넷 접속은 방화벽으로 차단되어 있지만 DNS 쿼리는 허용되는 다양한 상황에서 유용하게 사용할 수 있습니다.
iodine에는 configure 스크립트가 없습니다. Linux에는 두 가지 선택적 기능(SELinux 및 systemd 지원)이 있으며, 관련 헤더 파일이 /usr/include에서 발견되면 자동으로 활성화됩니다.
(./src/osflags의 스크립트 참조)
make를 실행하여 서버 및 클라이언트 바이너리를 컴파일하세요.
make install을 실행하여 바이너리와 manpage를 대상 디렉터리에 복사하세요.
make test를 실행하여 단위 테스트를 컴파일하고 실행하세요. (check 라이브러리 필요)
자체 LAN 내에서 사용해 보세요! 다음의 간단한 단계를 따르십시오:
./iodined -f 10.0.0.1 test.com을 실행하세요.
이미 10.0.0.0 네트워크를 사용 중이라면 172.16.0.0 같은 다른 내부 네트워크를 사용하세요../iodine -f -r 192.168.0.1 test.com을 실행하세요.
192.168.0.1을 서버의 IP 주소로 바꾸세요.10.0.0.2를, 서버는 10.0.0.1을 갖게 됩니다.실제로 중계 네임서버를 통해 사용하려면 아래를 참조하세요.
참고: 서버와 클라이언트는 정확히 동일한 프로토콜을 사용해야 합니다. 대부분의 경우 이는 동일한 iodine 버전을 실행해야 한다는 뜻입니다. 안타깝게도 프로토콜의 이전 및 이후 버전 간 호환성을 구현하는 것은 일반적으로 불가능합니다.
이 터널을 사용하려면 실제 도메인(예: mydomain.com)에 대한 제어 권한과 iodined을 실행할 공용 IP 주소를 가진 서버가 필요합니다. 이 서버가 이미 DNS 프로그램을 실행 중이라면 수신 포트를 변경한 다음 iodined의 -b 옵션을 사용하여 iodined이 DNS 요청을 전달하도록 하십시오. (이 방법은 iodined의 DNS 전달이 완전히 투명하지 않으므로, 예를 들어 영역 전송(zone transfer)이 작동하지 않기 때문에 프로덕션 환경에서는 권장되지 않습니다.) 또는 DNS 서버의 하위 도메인을 iodined으로 전달할 수 있으며, 이 경우 iodined은 다른 포트(-p)에서 실행되어야 합니다.
그런 다음 하위 도메인(예: t1.mydomain.com)을 iodined 서버에 위임하십시오. 도메인에 BIND를 사용한다면 존 파일에 다음과 같은 두 줄을 추가하세요:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
NS 줄만 있으면 t1 하위 도메인에 대한 쿼리를 t1ns 서버로 라우팅할 수 있습니다. 데이터 트래픽에 사용할 수 있는 공간을 최대한 확보하기 위해 하위 도메인은 짧은 이름을 사용합니다. NS 줄 끝에는 iodined 서버의 이름이 옵니다. 이 이름은 어디를 가리키든 어떤 이름이든 될 수 있지만, 이 경우에는 같은 존 파일에 쉽게 유지할 수 있습니다. 반드시 이름(IP 주소가 아님)이어야 하며, 그 이름 자체에는 CNAME이 아닌 A 레코드가 있어야 합니다.
iodined 서버의 IP가 동적이라면 동적 DNS 제공업체를 사용하세요. NS 줄이 해당 제공업체를 가리키게 하고 A 줄은 빼면 됩니다:
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
그런 다음 네임서버 프로그램을 리로드하거나 재시작하세요. 이제 t1.mydomain.com으로 끝나는 도메인에 대한 모든 DNS 쿼리가 iodined 서버로 전송됩니다.
마지막으로 서버에서 iodined을 시작하세요. 첫 번째 인자는 터널 내부의 IP 주소로, 아직 사용하지 않는 모든 범위에서 선택할 수 있으며(예: 192.168.99.1), 두 번째 인자는 할당된 도메인입니다(이 경우 t1.mydomain.com). -f 옵션을 사용하면 iodined이 포그라운드에서 계속 실행되므로 테스트할 때 유용합니다. iodined은 가상 인터페이스("tun device")를 열고 UDP 포트 53에서 DNS 쿼리 수신도 시작합니다. 명령줄에서(-P pass) 또는 서버 시작 후 비밀번호를 입력하세요. 이제 클라이언트를 위한 모든 준비가 완료되었습니다.
예상치 못한 환경에서 iodine 터널을 사용할 가능성이 있다면 -c 옵션과 함께 iodined을 시작하세요.
이 예시 상황에서의 결과 명령줄:
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
모든 설정이 완료되었으니 iodine을 시작하기만 하면 됩니다. 인자는 하나 또는 두 개를 받으며, 첫 번째는 로컬 중계 DNS 서버(선택 사항)이고 두 번째는 사용한 도메인(t1.mydomain.com)입니다. 첫 번째 인자를 지정하지 않으면 시스템의 현재 DNS 설정이 사용됩니다.
DNS 쿼리가 모든 컴퓨터에 허용된다면 첫 번째 인자로 iodined 서버의 주소를 직접 지정할 수 있습니다(예: t1ns.mydomain.com 또는 10.15.213.99). 이 경우 어떤 컴퓨터의 DNS 포트(53 UDP)로 모든 트래픽이 허용될 수도 있습니다. iodine은 이를 감지하고 가능하면 raw UDP 터널링으로 전환합니다. 어떤 경우에도 DNS 터널링을 강제하려면 -r 옵션을 사용하세요(자체 네트워크 내에서 테스트할 때 특히 유용합니다).
클라이언트의 터널 인터페이스는 서버와 가까운 IP(이 경우 192.168.99.2 또는 .3 등)와 적절한 MTU를 갖게 됩니다. 서버와 동일한 비밀번호를 명령줄 옵션으로 또는 클라이언트 시작 후 입력하세요. -f 옵션을 사용하면 iodine 클라이언트가 포그라운드에서 계속 실행됩니다.
이 예시 상황에서의 결과 명령줄입니다. -r을 추가하면 raw UDP 터널링이 가능하더라도 DNS 터널링을 강제합니다:
./iodine -f -P secretpassword t1.mydomain.com
이제 양쪽 어느 쪽에서든 터널 반대편의 IP 주소로 ping을 보낼 수 있어야 합니다. 이 경우 iodine 클라이언트에서는 ping 192.168.99.1을, iodine 서버에서는 192.168.99.2를 ping합니다.
터널 내부의 데이터는 IPv4만 지원됩니다.
서버는 기본적으로 수신 요청에 대해 IPv4와 IPv6 모두에서 수신합니다. 하나의 프로토콜에서만 수신하려면 -4 또는 -6 옵션을 사용하세요. Raw 모드는 로그인에 사용된 것과 동일한 프로토콜로 시도됩니다.
클라이언트는 IPv4 또는 IPv6 네임서버를 사용하여 iodined에 연결할 수 있습니다. 중계 네임서버는 필요에 따라 프로토콜 간 변환을 자동으로 수행합니다. -4 또는 -6 옵션을 사용하여 클라이언트가 DNS 쿼리에 특정 IP 버전을 사용하도록 강제할 수 있습니다.
서버가 IPv6로 수신 중이고 연결 가능하다면 DNS 설정에 AAAA 레코드를 추가하세요. 위 예시를 확장하면 다음과 같습니다:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
t1ns IN AAAA 2001:db8::1001:99
모든 트래픽을 DNS 터널을 통해 라우팅할 수 있습니다. 이렇게 하려면 먼저 기본 게이트웨이를 게이트웨이로 사용하여 유선/무선 인터페이스를 통해 iodine이 사용하는 네임서버에 호스트 경로를 추가하세요. 그런 다음 기본 게이트웨이를 DNS 터널 내부의 iodined 서버 IP 주소로 교체하고 서버에서 NAT를 수행하도록 구성하세요.
단, 터널링된 데이터 트래픽은 전혀 암호화되지 않으므로 외부에서 비교적 쉽게 읽고 변경할 수 있다는 점에 유의하세요. 최대한의 보안을 위해서는 DNS 터널을 통해 VPN을 실행하거나(=이중 터널링), 포트 포워딩이 가능한 보안 셸(SSH) 접속을 사용하세요. 후자는 서버에서 웹 프록시(예: Privoxy)를 실행할 때 웹 브라우징에도 사용할 수 있습니다.
iodined 서버는 터널 도메인의 하위 도메인으로 전송된 NS 요청에 응답합니다. iodined 하위 도메인이 t1.mydomain.com이라면 foo123.t1.mydomain.com에 대한 NS 요청을 보내 위임이 작동하는지 확인하세요.
dig가 이 작업에 좋은 도구입니다:
% dig -t NS foo123.t1.mydomain.com
ns.io.citronna.de.
또한 iodined 서버는 지원되는 모든 요청 유형에 대해 'z'로 시작하는 요청에 응답합니다. 예를 들어:
dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com
이 모든 경우에 응답은 깨진 텍스트처럼 보여야 합니다.
Mac OS X 10.6 이상에서 iodine은 OS에 내장된 기본 utun 디바이스를 지원합니다 - -d utunX를 사용하세요.
DNS 응답 프래그먼트 크기는 일반적으로 최대 대역폭을 얻기 위해 자동 탐지됩니다. 특정 값을 강제하려면(그리고 속도를 높이려면) -m 옵션을 사용하세요.
DNS 호스트 이름은 일반적으로 최대 길이인 255자까지 사용됩니다. 일부 DNS 릴레이는 전체 길이 쿼리에 매우 불안정하게 응답하여 프래그먼트 크기 자동 탐지가 반복 시도 때마다 크게 다른(대부분 매우 나쁜) 결과를 주는 것으로 확인되었습니다. 이러한 경우 -M 스위치를 사용하여 DNS 호스트 이름 길이를 예를 들어 200자로 줄이면 이러한 DNS 릴레이가 훨씬 안정적으로 작동합니다. 이는 또한 쿼리의 전체 복사본 두 개를 응답에 채워 넣어 다운스트림 데이터를 위한 공간을 거의 남기지 않는 일부 "비최적화(de-optimizing)" DNS 릴레이에서도 유용합니다(EDNS0도 지원하지 않음). -M 스위치는 업스트림 대역폭 일부를 다운스트림 대역폭과 맞바꿀 수 있습니다. 프로토콜이 패킷(최대 1200바이트)을 16개의 프래그먼트로만 분할할 수 있어 프래그먼트당 최소 75바이트의 실제 데이터가 필요하므로 -M의 최소값은 약 100입니다.
업스트림 데이터는 gzip으로 압축된 후 Base32로 인코딩되어 전송됩니다. 릴레이 서버가 도메인 이름에서 대소문자 혼용과 +를 지원하면 Base64, _를 지원하면 Base64u, 높은 바이트 값의 문자를 지원하면 Base128이 사용됩니다. 이 업스트림 인코딩은 자동 탐지됩니다. DNS 프로토콜은 패킷당 하나의 쿼리를 허용하며, 하나의 쿼리는 최대 256자입니다. 각 도메인 이름 부분은 최대 63자입니다. 따라서 최대 업스트림 처리량을 얻으려면 도메인 이름과 하위 도메인을 가능한 한 짧게 유지해야 합니다.
여러 DNS 요청 유형이 지원되며, NULL 및 PRIVATE 유형이 가장 큰 다운스트림 대역폭을 제공할 것으로 예상됩니다. PRIVATE 유형은 사설 사용 범위의 값 65399를 사용합니다. 사용 가능한 다른 유형으로는 대역폭이 큰 순서대로 TXT, SRV, MX, CNAME 및 A(CNAME 반환)가 있습니다. 일반적으로 "최적"의 요청 유형이 자동 탐지되어 사용됩니다. 그러나 DNS 릴레이가 예를 들어 NULL 및 TXT에 제한을 두어 실제로는 SRV 또는 MX가 최선의 선택이 될 수 있습니다. 이는 자동 탐지되지 않지만 -T 옵션을 사용하여 강제할 수 있습니다. 특히 자동 탐지된 요청 유형이 200바이트 미만의 다운스트림 프래그먼트 크기를 제공하는 경우 다양한 대안을 시도해 보는 것이 좋습니다.
SRV, MX 및 A(CNAME 반환) 쿼리는 "스마트" 캐싱 네임서버가 실제 IP 주소를 얻기 위해 추가 조회를 유발할 수 있으며, 이로 인해 속도가 느려지거나 완전히 실패할 수 있습니다.
비-NULL/PRIVATE 쿼리에 대한 DNS 응답은 업스트림 데이터와 동일한 코덱 세트로 인코딩할 수 있습니다. 이 역시 일반적으로 자동 탐지되지만 완전히 철저한 테스트는 수행되지 않으므로, 더 고급 코덱을 선택할 때 일부 문제가 발견되지 않을 수 있습니다. 이 경우 프래그먼트 크기 자동 탐지에서 실패/손상이 나타납니다. 특히, 일부 DNS 릴레이는 호스트 이름(SRV, MX, CNAME, A)을 반환하는 응답을 해당 호스트 이름이 약 180자를 초과할 때만 소문자로 변경하는 것으로 확인되었습니다. 이러한 경우 및 유사한 경우에는 -O 옵션을 사용하여 다른 다운스트림 코덱을 시도하세요. Base32는 항상 작동해야 합니다.
이제 일반적인 운영 방식은 다음 DNS 요청이 들어올 때까지 서버가 DNS 요청에 응답하지 않는 것, 즉 "지연(lazy)" 방식입니다. 이렇게 하면 서버는 새로운 다운스트림 데이터를 보내야 할 때 항상 DNS 요청을 준비해 둘 수 있습니다. 이는 (대화형) 성능과 지연 시간을 크게 개선하며, 기본적으로 유휴 ping 요청 간격을 4초로 늦추고 훨씬 더 느리게 설정할 수도 있습니다. 사실 이제 ping의 주요 목적은 이전 ping에 대한 응답을 강제하고 DNS 서버 시간 초과(보통 RFC1035에 따라 최소 5-10초)를 방지하는 것입니다. 일부 DNS 서버는 더 성급하여 터널링된 데이터 트래픽이 없는 기간에 SERVFAIL 오류(시간 초과)를 발생시킵니다. 이러한 경우에도 모든 데이터는 여전히 통과해야 하지만, iodine은 오류 메시지 수를 줄이기 위해 어쨌든 ping 간격을 1초(-I1)로 줄입니다. dnsadvantage.com(ultradns)처럼 1초 이하로 시간 초과되는 매우 성급한 DNS 릴레이에는 도움이 되지 않을 수 있습니다. 그래도 데이터는 여전히 통과하므로 SERVFAIL 오류는 무시해도 됩니다.
중간에 DNS 서버가 없는 로컬 네트워크에서 실행하는 경우 -I 50을 시도해 보세요(iodine과 iodined은 60초간 통신이 없으면 연결을 닫습니다). 속도 저하를 느낄 수 있는 유일한 경우는 DNS 응답 패킷이 유실될 때입니다. 이 경우 iodined 서버는 데이터를 다시 보내기 위해 새 ping을 기다려야 합니다. 업스트림 트래픽(키 입력, ping)을 생성하면 속도를 높일 수 있습니다. 이런 일이 자주 발생하면 네트워크의 병목 지점을 확인하고/하거나 -I1로 실행하세요.
지연 모드에서의 응답 지연으로 인해 일부 "통신사급(carrier grade)" 상용 DNS 릴레이가 동일한 DNS 쿼리를 iodined 서버에 반복적으로 재전송하게 됩니다. DNS 릴레이가 실제로 병렬 서버 풀로 구현된 경우 중복 요청이 여러 소스에서 도착할 수도 있습니다. 이 효과는 iodined 서버의 네트워크 트래픽에서만 볼 수 있으며 클라이언트의 연결에는 영향을 미치지 않습니다. iodined은 이러한 중복을 감지하고(응답 시점이 되면) 원래 쿼리와 가장 최근의 중복 쿼리 양쪽에 동일한 응답을 보냅니다. 그 후 전체 응답은 잠시 동안 캐시됩니다. 더 늦게 서버에 도착하는 지연된 중복 요청에는 iodine 클라이언트가 무시할 응답(클라이언트에 도달한다면)이 전송됩니다.
문제가 발생하면 tcpdump나 ethereal/wireshark 같은 네트워크 모니터링 도구로 트래픽을 검사하고, 중계 DNS 서버가 응답을 캐시하지 않았는지 확인하세요. 캐시된 오류 메시지는 서버보다 클라이언트를 먼저 시작했다는 뜻일 수 있습니다. 서버의 -D(및 -DD) 옵션으로 수신 및 전송된 쿼리를 확인할 수도 있습니다.
특정 인터페이스에서 포트 53을 사용하지 않는 애플리케이션이 점유하고 있다면, iodined에서 -p를 사용하여 대체 포트(예: -p 5353)를 지정하고 예를 들어 iptables(Linux)를 사용하여 트래픽을 전달하세요:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
(Tom Schouten 제공)
iodined은 60초 이상 활동(데이터/ping)이 없는 클라이언트의 데이터를 거부합니다. 마찬가지로 iodine은 60초 동안 다운스트림 데이터를 수신하지 못하면 종료됩니다. 장시간 네트워크 중단 등의 경우에는 iodine을 다시 시작(재로그인)하기만 하면 되며, 이전 IP 주소를 되찾을 때까지 여러 번 시도해야 할 수도 있습니다. IP 주소를 되찾은 후 잠시 기다리면 중단 전에 중단되었던 지점부터 터널링된 TCP 트래픽이 계속 흐르는 것을 볼 수 있습니다.
서버에 다운스트림 패킷 큐가 도입되면서 기본 구성에서 메모리 사용량이 수 메가바이트 증가했습니다. 저메모리 환경(예: DSL 라우터에서 실행)에서 사용하려면, 동시에 최대 한 명의 클라이언트만 연결된다고 가정할 때 user.h에서 USERS를 줄이고 OUTPACKETQ_LEN을 정의 해제해도 아무런 문제가 없습니다. DNSCACHE_LEN은 작은 값(가급적 2 이상)을 유지하는 것이 좋습니다. 다만 몇 킬로바이트를 더 절약하려면 정의를 해제할 수도 있습니다.
하나의 iodine 서버는 여러 도메인을 처리할 수 있습니다. 동일한 도메인에 모두 같은 호스트를 가리키는 서로 다른 NS 레코드를 설정하고, 최상위 도메인 인자 시작 부분에 와일드카드를 사용하세요(예: *.mydomain.com). iodine은 해당 패턴과 일치하는 모든 도메인의 터널 트래픽을 허용합니다. 와일드카드는 최상위 도메인 인자의 시작 부분에 있어야 하며 그 뒤에 점이 와야 합니다.
이 섹션은 일부 성능 측정 결과를 표로 정리한 것입니다. 제대로 보려면 Courier 같은 고정폭 글꼴을 사용하세요.
측정은 프로토콜 00000502, 지연 모드에서 수행되었습니다. 업스트림 인코딩은 항상 Base128, iodine -M255, iodined -m1130이 사용되었습니다. 네트워크 조건이 매우 유리하지는 않았으며, 결과는 벤치마크가 아니라 유사한 상황에서 기대할 수 있는 실제 성능을 현실적으로 보여줍니다.
업스트림/다운스트림 처리량은 이전에 /dev/urandom에서 읽은(즉, 압축 불가능한) 파일을 scp로 전송하고, 별도의 비터널 연결에서 ls -l ; sleep 30 ; ls -l로 크기를 측정하여 구했습니다. scp 블록 크기가 16kB로 크기 때문에 해상도는 4.3kbit/s이며, 이는 일부 값이 정확히 동일한 이유를 설명합니다.
ping 왕복 시간은 ping -c100으로 측정했으며, 평균 rtt와 평균 편차(평균 주변의 분포를 나타냄)를 밀리초 단위로 제시합니다.
Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter iodine DNS "relay" bind9 DNS cache iodined
downstr. upstream downstr. ping-up ping-down
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
-----------------------------------------------------------------------------
iodine -> Wifi AP :53
-Tnull (= -Oraw) 982 43.6 131.0 28.0 4.6 26.8 3.4
iodine -> Home server :53
-Tnull (= -Oraw) 1174 48.0 305.8 26.6 5.0 26.9 8.4
iodine -> DSL provider :53
-Tnull (= -Oraw) 1174 56.7 367.0 20.6 3.1 21.2 4.4
-Ttxt -Obase32 730 56.7 174.7*
-Ttxt -Obase64 874 56.7 174.7
-Ttxt -Obase128 1018 56.7 174.7
-Ttxt -Oraw 1162 56.7 358.2
-Tsrv -Obase128 910 56.7 174.7
-Tcname -Obase32 151 56.7 43.6
-Tcname -Obase128 212 56.7 52.4
iodine -> DSL provider :53
wired (no Wifi) -Tnull 1174 74.2 585.4 20.2 5.6 19.6 3.4
[174.7* : these all have 2frag/packet]
Laptop -> Wifi+vpn / wired -> Home server iodine iodined
downstr. upstream downstr. ping-up ping-down
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
-----------------------------------------------------------------------------
wifi + openvpn -Tnull 1186 166.0 1022.3 6.3 1.3 6.6 1.6
wired -Tnull 1186 677.2 2464.1 1.3 0.2 1.3 0.1
성능은 낮은 ping 시간과 밀접한 관련이 있습니다. iodine은 다음 데이터 프래그먼트로 넘어가기 전에 모든 프래그먼트에 대한 확인을 요구하기 때문입니다. TCP처럼 여러 프래그먼트를 동시에 전송 중으로 허용하면 성능이 향상될 수 있지만, 중간 DNS 서버에 심각한 과부하를 초래할 가능성이 높습니다. 현재 프로토콜은 DNS 응답성에 따라 성능이 확장됩니다. DNS 서버는 평균적으로 클라이언트당 최대 하나의 DNS 요청을 처리하기 때문입니다.
iodine은 Linux(arm, ia64, x86, AMD64 및 SPARC64), FreeBSD(ia64, x86), OpenBSD(x86), NetBSD(x86), MacOS X(ppc 및 x86, http://tuntaposx.sourceforge.net/ 사용) 및 Windows(OpenVPN TAP32 드라이버 사용, win32 readme 파일 참조)에서 테스트되었습니다. TUN/TAP 터널링을 지원하는 다른 유닉스 계열 시스템으로의 포팅은 쉬울 것입니다. 다른 플랫폼에서 실행하는 데 성공하면 알려주세요.
iodine이라는 이름은 IOD(IP Over DNS)로 시작하고, iodine(요오드)의 원자 번호가 53인데, 이는 마침 DNS 포트 번호와 같기 때문에 선택되었습니다.
Copyright (c) 2006-2014 Erik Ekman [email protected], 2006-2009 Bjorn Andersson [email protected]. 또한 Anne Bezemer의 주요 기여가 있습니다.
이 소프트웨어를 어떤 목적으로든 유료 또는 무료로 사용, 복사, 수정 및/또는 배포할 수 있는 권한은, 위의 저작권 고지와 본 허가 고지가 모든 사본에 포함된다는 조건으로 여기에 부여됩니다.
본 소프트웨어는 "있는 그대로" 제공되며, 저자는 상품성 및 특정 목적에의 적합성에 대한 묵시적 보증을 포함하여 본 소프트웨어와 관련된 모든 보증을 부인합니다. 어떠한 경우에도 저자는 계약, 불법 행위 또는 기타 불법 행위로 인해 발생하든, 본 소프트웨어의 사용 또는 성능과 관련하여 또는 이와 관련하여 발생하는 특별, 직접, 간접 또는 결과적 손해 또는 사용, 데이터 또는 이익의 손실로 인한 어떠한 손해에 대해서도 책임을 지지 않습니다.
MD5 구현: L. Peter Deutsch (라이선스 및 소스는 src/md5.[ch]에 있음)
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved.