한RSS 구독자수

최근 덧글

난 공짜로 원하는 ..
by Natash at 05:25
내가 원하는 다운로..
by Natash at 01/26
어디에 다운로드 X..
by Natash at 01/26
난 공짜로 원하는 ..
by Natash at 01/25
난 당신 의 모든 ..
by SHEATT at 01/20
난 우리 모두 그말..
by SHEATT at 01/20
i_i) 그림 올리..
by ryusei at 01/20
이미지 2, 3 올..
by Mitz at 01/20
-_-;;
by xeraph at 06/07
국민의례와 자주자주..
by 페리 at 06/03
그렇죠 뭐.. 전 ..
by xeraph at 03/17
악용된 사례가 있을..
by darkhi at 03/10
http://rgb..
by xeraph at 02/04
공개되고 있습니다...
by aljjam at 02/03
오오 자비로운 MS..
by 고르엡 at 01/16

최근 트랙백

윈도우보안업데이트
by neoteny'.. at 10/13
[윈도우 LNK 취약점..
by hemoptys.. at 07/20
많은 보안관련 사이트에..
by Zasfe Note at 01/02
MS 10월 보안 패치
by nchovy's.. at 10/14
제로보드 4.1pl9 ..
by nchovy's.. at 09/25
SMB v2 제로데이 ..
by nchovy's.. at 09/18
MS09-048: TC..
by nchovy's.. at 09/09
MS 9월 보안 패치,..
by nchovy's.. at 09/09
IIS 5/6 FTP ..
by nchovy's.. at 09/01
Pinkren 플래시 ..
by nchovy's.. at 08/26

DNS HIT 쿼리 남기기

앞서 다룬 Fast-Flux 도메인을 탐지하기 위해서는 여러가지 방법이 있지만, 네임서버에서 DNS 쿼리 로그를 수집하여 분석하는 것이 가장 간단한 방법 중 하나일 것입니다. 

가장 대중적으로 사용하는 네임서버인 BIND의 경우, 기본적으로 DNS 쿼리를 로그로 남기지 않습니다. 그렇기 때문에 별도의 설정을 해야합니다. 일단 간단하게 쿼리를 로그로 남기게 설정해둔 named.conf 파일을 살펴보겠습니다.

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        channel default_dnshit {
                file "data/dnshit.log";
                print-time yes;
        };
        category queries {
                default_dnshit;
        };
};

어떤 것인지 대충 감이 오나요? 

서버에 쿼리(category queries)가 오면, default_dnshit; 설정에 따라 로그를 남기라고 하는 것입니다.

channel default_dnshit은 dnshit.log라는 파일에 로그를 남기고(file "data/dnshit.log";), 시간을 남기도록(print-time yes;) 설정되어 있습니다.

이 설정에 따라 dnshit.log 에 남겨진 로그를 살펴보면 다음과 같습니다.

[root@******* data]# tail -f dnshit.log
19-Jan-2012 17:00:27.772 client 121.167.11.1#25401: query: nchovy.kr IN A -E
19-Jan-2012 17:00:36.320 client 121.138.224.7#15593: query: nchovy.kr IN A -E
19-Jan-2012 17:00:38.275 client 210.94.11.122#13063: query: xeraph.com IN A -E
19-Jan-2012 17:00:48.782 client 210.94.11.106#15154: query: ns2.nchovy.com IN A -E
19-Jan-2012 17:00:48.782 client 210.94.11.106#50051: query: ns3.nchovy.com IN A -E
19-Jan-2012 17:01:08.538 client 207.46.200.37#49745: query: ns1.nchovy.com IN A -

이런식으로 파일에 쿼리 로그를 남긴 후, 파싱하여 분석할 수 있습니다. 그러나 이렇게 한다면 매번 로그를 보기 위해 DNS 서버에 접속해서 별도의 파일을 살펴봐야 합니다.

그러나 bind 의 설정과 syslog 의 설정을 이용해 syslog로 남기거나, 외부의 syslog 서버로 보낼 수도 있습니다.

named.conf 에 아래와 같이 설정을 추가하였습니다. 굵게 표시된 부분이 추가된 부분입니다.

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        channel default_dnshit {
                file "data/dnshit.log";
                print-time yes;
        };
        channel syslog {
                syslog local7;
        };

        category queries {
                default_dnshit;
                syslog;
        };
};

syslog에 로그 분류(facility) local7 으로 보내도록 설정이 추가되었습니다. 기본적으로 syslog 설정에는 local7 설정이 없기 때문에 아래에 나와있는 설정을 syslog.conf 에 추가합니다. syslog에서 시간을 기록하기 때문에 시간을 기록하는 옵션("print-time yes;")은 설정하지 않습니다.

local7.*                        /var/log/local7

이렇게 설정을 추가한 뒤 named 와 syslog를 재시작하고, /var/log/local7 파일을 보면 아래와 같이 로그가 기록됩니다.

[root@******* log]# tail -f local7
Jan 19 16:58:29 ******* named[12230]: client 202.188.1.27#36711: query: krakenapps.org IN A -
Jan 19 16:58:33 ******* named[12230]: client 208.78.69.150#58826: query: ns2.nchovy.com IN A -E
Jan 19 16:58:33 ******* named[12230]: client 208.78.69.150#18435: query: krakenapps.org IN A -E
Jan 19 16:58:33 ******* named[12230]: client 208.78.69.150#13351: query: ns3.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#59556: query: ns2.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#24909: query: ns4.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#18610: query: ns3.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#3692: query: ns1.nchovy.com IN A -E

이 로그를 원격으로 보내기 위해선 아래처럼 syslog.conf 를 수정하면 됩니다.

local7.*                        @100.100.100.100

그리고 해당 syslog 서버가 로그를 받도록 설정합니다.

레퍼런스

by 8con | 2012-01-19 17:17:19 | 미분류 | 트랙백 (0) | 덧글 (2)

트랙백 주소 : http://nchovy.kr/forum/2/article/714/trackback
Natashadug

내가 원하는 다운로드 X-Rumer 7.0.10 ??
나에게 보내기 URL 하시기 바랍니다!

2012-01-26 18:34 x
NatashaHop

난 공짜로 원하는 X-Rumer 7.0.10 ELITE??
내가 URL을 하시기 바랍니다 보내기!
그것은 질량 이 포럼 에 게시 위한 최상의 프로그램입니다 ! XRumer 는 captchas 대부분의 유형 을 깰 수 있습니다!

2012-02-04 05:25 x
이름 암호

Fast-Flux 도메인 탐지

이 글에서는 Fast Flux 서비스 네트워크가 무엇인고 어떻게 동작하는지, 어떻게 탐지하고 대응해야 하는지 다룬다. 현실에서 온라인 피싱사이트나 맬웨어 호스트에 대한 접근을 차단하기가 쉽지 않은데, 그 이유는 방화벽에서 특정 IP를 차단하더라도 DNS와 봇넷을 이용하여 계속해서 IP를 바꾸고 차단을 회피하여 살아남기 때문이다.

Fast Flux는 TTL을 매우 짧게 주고 도메인에 다수의 IP 주소를 매핑한다. 따라서 클라이언트는 같은 도메인이라 해도 매번 다른 IP 주소로 접속하게 된다. 공격자는 자신이 장악하고 있는 호스트(즉, 좀비)에 피싱 사이트, 스팸 사이트, 맬웨어 업데이트 서버 등을 운영하고, 도중에 복구되거나 차단되면서 제어권을 잃어버린 호스트들은 떨어내면서 Fast Flux 네트워크를 유지한다.

Fast Flux 도메인이 가리키는 호스트들은 프론트엔드 서버 혹은 프록시 역할을 할 뿐이고 실제로는 모선에 해당하는 C&C 서버로부터 데이터를 받아 서비스하게 된다. C&C 서버를 차단하면 전체 Fast Flux 네트워크를 셧다운 시킬 수 있겠지만, 한 단계 뒤에 숨어있는 C&C 서버를 찾아내기란 쉽지 않다. 공개된 자료에 의하면 단 두 대의 C&C 서버가 수천개의 Fast-Flux 도메인을 운영하면서 네트워크를 유지한 경우도 있었다고 한다.

위 도식은 honeynet.org에서 가져온 것으로, Single Flux 운영 방식을 보여주고 있다. 위와 같이 flux.example.com을 요청했을 때 네임서버가 좀비 PC의 IP 주소를 반환하고, 좀비가 C&C로부터 내려받은 악성 컨텐츠를 클라이언트에게 반환하는 방식을 Single Flux라 부른다.

Single Flux에서 한 단계 더 나아가면 Double Flux가 된다. Double Flux는 Authoritative 네임서버 도메인도 여러 개 등록해서 이중으로 Fast-Flux 네트워크를 구성하는 것을 의미한다.  이러한 구성을 하게 되면 더 추적과 차단이 어려워지고, 한 두 개 호스트가 단절된다고 해도 안정적으로 전체 네트워크가 유지되는 특성을 가지게 된다. 이들은 뒤에 숨어있는 C&C 서버만 관리하면 되므로 비용을 적게 들이고 차단을 회피하면서 악성 컨텐츠를 효과적으로 뿌릴 수 있다.

맬웨어들은 Fast Flux 네트워크를 이용해서 안정적으로 업데이트를 수행할 수 있게 되고, 각종 변종을 만들어내거나 DDoS 공격 명령을 수신하면서 움직일 수 있다. 어떤 맬웨어들은 시간의 흐름과 미리 정해진 규칙에 따라 도메인 이름을 동적으로 만들어내면서 접속을 시도하고 다운로드한다. 이 경우 미리 정해진 도메인 이름이 아니기 때문에 생성될 수 있는 모든 조합의 도메인을 차단하는 것도 어렵다. (만약 도메인 주소 생성 규칙을 알고 도메인을 미리 등록한다면 얼마나 많은 수의 호스트가 해당 맬웨어에 감염되었는지 파악할 수도 있을 것이다.) 

의심되는 도메인 주소를 확보했다면, 일정한 주기로 DNS 쿼리를 수행하면서 IP 주소 집합을 수집할 수 있다. 만약 TTL이 매우 짧고 비교적 최근에 등록된 도메인이면서 시간이 지남에 따라 전체 IP 주소 집합이 계속해서 증가한다면 이는 Fast Flux 도메인으로 규정할 수 있다. DNS 정보를 모니터링하면서 수집된 IP를 분석하면 외부에서도 어느 회사/조직이 감염되었는지 파악할 수 있을 뿐 아니라, 전체 봇넷의 크기를 유추할 수 있고, IP 집합의 유사성으로 각 악성 도메인 간의 연관 관계를 분석할 수 있다.

원문

레퍼런스

by 8con | 2012-01-18 13:35:30 | 미분류 | 트랙백 (0) | 덧글 (0)

트랙백 주소 : http://nchovy.kr/forum/2/article/713/trackback
이름 암호

DEP와 ASLR의 실효성에 대하여

이 글은 마이크로소프트 SRD 블로그의 On the effectiveness of DEP and ASLR을 번역한 글입니다.

DEP와 ASLR의 실효성

DEP (데이터 실행 방지)와 ASLR (주소공간 레이아웃 랜덤화) 기법은 현실의 다양한 익스플로잇에 대응하는 효과적인 대응 방법입니다. 이런 대응 기술들은 필연적으로 많은 관심을 받게 되기 때문에, 지금까지 DEP와 ASLR을 우회하는 방법에 대한 많은 연구와 논의가 이루어져 왔습니다. 이 글에서는 여러 연구에서 언급된 우회 기술에 대해 이러한 대응 기술이 얼마나 실효성을 가지는지 다뤄보겠습니다. 이 글을 간단하게 요약하면 아래와 같습니다.

  • DEP와 ASLR은 공격자의 익스플로잇 개발 비용을 증가시켜서 투자 수익(ROI)을 감소시키도록 설계되었습니다.
  • DEP와 ASLR의 조합은 오늘날 볼 수 있는 익스플로잇을 매우 효과적으로 막을 수 있습니다. 하지만 둘 다 우회 가능한 환경도 존재합니다.
  • 마이크로소프트나 서드파티의 취약점을 공격하는 익스플로잇 중에 DEP와 ASLR 우회가 가능한 것들은 모두 웹 브라우저나 서드파티 응용프로그램 환경에서 동작합니다.
  • 우리는 지금까지 내장된 윈도우 서비스나 응용프로그램 환경에서 DEP와 ASLR을 우회하는 어떤 원격 익스플로잇도 찾아볼 수 없었습니다.
  • 잠재적인 우회 기술에 대한 지식은 앞으로 DEP, ASLR, 기타 대응 기술을 더욱 발전시키는데 일조할 것입니다.

DEP의 실효성 (ASLR이 없을 때)

이전 포스팅 시리즈에서 DEP가 어떻게 동작하는지 세부사항을 다루었습니다. (1편, 2편) 요약하자면, DEP는 공격자가 데이터를 코드인 것처럼 실행하지 못하도록 막아주는 역할을 합니다. DEP는 공격자가 스택, 힙, 코드가 아닌 메모리 영역에서 코드를 바로 실행하지 못하도록 합니다. 보통 DEP가 걸린 상태에서 힙 스프레이나 스택으로 리턴하는 기법을 바로 사용할 수는 없습니다.

DEP의 실효성은 공격자가 1) 기존의 이미 실행 가능한 코드를 이용할 수 없다는 점과 2) 공격자의 데이터가 실행 가능하게 전환되지 않는 것에 좌우됩니다. 그런데 ASLR이 없는 플랫폼(즉, 윈도우 비스타 이전 버전)에서는 공격자가 프로세스 주소 영역에서 이미 예측 가능한 위치에 적재되어 있는 모듈에 존재하는 코드를 찾아 이용하는 것이 매우 쉽습니다. Return-oriented Programming (ROP)는 쉘코드에서 기존의 모듈에 존재하는 코드를 이용하는 기법으로, 널리 사용되고 있습니다. [3,1] 이 뿐만 아니라, JIT 컴파일러와 같은 특정 기능들을 이용하면 공격자가 외부에서 일부 영역만 제어할 수 있더라도 실행 가능한 코드를 생성해 낼 수 있습니다. 이를 통해 쉘코드를 정상적인 인스트럭션 스트림에 끼워넣을 수 있습니다. (“JIT 스프레이”) [2]

ASLR이 없고 모듈이 예측 가능한 위치에 적재된다면, 공격자의 데이터를 실행 가능한 코드로 전환시키는 것도 역시 가능합니다. 여러가지 방법이 있지만 가장 간단한 방법은 기존의 모듈에서 VirtualAlloc이나 VirtualProtect와 같은 시스템 함수를 호출하는 코드를 찾아서 공격자의 데이터를 실행 가능하게 만드는데 이용하는 것입니다.

요약: DEP는 공격자가 지금까지 의존하고 있던 가정들을 무너뜨리지만 ASLR이 없는 DEP는 대부분의 경우 임의의 코드를 실행하지 못하도록 막는데 충분하지 않습니다.

ASLR의 실효성 (DEP가 없을 때)

공격자들은 익스플로잇을 개발할 때 보통 프로세스의 주소공간 레이아웃에 대한 가정을 합니다. 예를 들면, 공격자는 모든 PC의 특정 주소에 읽기/쓰기 가능한 메모리가 있거나 특정 위치에 모듈이 적재된다고 가정합니다. ASLR은 공격자가 머신에 직접 접근할 수 없는 상태에서 프로세스의 주소공간 레이아웃에 대한 가정을 세우지 못하도록 설계되었습니다. 이는 공격자가 적재된 모듈에 있는 코드를 안정적으로 사용할 수 없게 만듭니다.

ASLR의 실효성은 공격자가 주소공간 레이아웃을 완전히 모른다는 점에 달려있습니다. 그런데 ASLR에도 불구하고 메모리가 예측 가능한 위치에 매핑되는 경우들이 있습니다. /DYNAMICBASE 링커 플래그를 설정하지 않으면, DLL이나 EXE가 예측 가능한 위치에 적재됩니다. 인터넷 익스플로러 8.0 이전까지는 공격자들이 브라우저에서 예측 가능한 위치에 적재된 특정 닷넷 모듈들을 사용할 수 있었습니다. [6] 그 외에도 공격자들은 자신이 원하는 주소에 코드나 데이터를 놓으려고 힙 스프레이나 JIT 스프레이 등 주소공간 스프레이 기법들을 사용하곤 합니다.

주소공간이 초기에 예측 불가능한 경우라면 공격자는 특정 메모리 영역의 위치를 찾아내려고 주소공간 정보유출이나 무작위 공격을 시도할 수 있습니다.[5] 주소공간 정보유출은 공격자가 하나 이상의 주소(DLL 내부에 있는 함수 주소 등)를 유출하도록 강제할 수 있을 때 발생합니다. 가령 공격자가 문자열의 NULL 종결자를 덮어쓰고 응용프로그램이 해당 문자열을 읽어서 결과를 반환하도록 하는 경우를 상정할 수 있습니다. [4] 이렇게 하면 NULL 종결자 이전까지의 메모리 정보가 노출됩니다. 지금 설명한 것은 하나의 예일 뿐이고, 여러가지 방식을 시도해서 메모리 정보를 알아낼 수 있습니다.

한편, 무작위 공격으로는 공격자가 원하는 코드나 데이터가 존재할 것으로 예상되는 모든 주소에 대하여 여러 번 익스플로잇을 시도할 수 있습니다. 무작위 공격이 어떤 경우에는 통할지 몰라도 윈도우 응용프로그램을 공격할 때는 별로 실용적이지 못합니다. 한 번 잘못 찍으면 응용프로그램 자체가 종료되기 때문입니다. 무작위 공격에 노출될 수 있는 응용프로그램(윈도우 서비스나 인터넷 익스플로러 등)은 일정 횟수 이상 충돌이 발생하면 프로세스가 자동으로 재시작 되지 못하도록 설계되어 있습니다. 하지만 모든 예외를 잡도록 되어있는 코드 경로에 취약점이 존재하는 응용 프로그램과 같은 특정 환경에서는 이러한 무작위 공격이 가능할 수도 있습니다.

특정한 종류의 취약점들은 부분적인 덮어쓰기라 불리는 기법으로 ASLR을 우회할 수 있기도 합니다. 이 기법은 공격자가 주소의 하위 비트를 덮어쓸 수 있는 점을 이용합니다. (ASLR이 주소의 상위 비트만 랜덤화하는 특성을 이용)

요약: ASLR은 공격자가 프로세스의 주소공간 내에 코드와 데이터가 존재하는 위치에 대한 가정을 하지 못하도록 합니다. ASLR은 공격자가 특정 메모리 영역(특히 DLL 매핑)에 대해 예측, 발견, 제어할 수 있는 경우 우회 가능합니다. DEP가 없는 경우 공격자는 힙 스프레이를 이용하여 코드를 주소공간의 예측 가능한 위치에 둘 수 있습니다.

DEP와 ASLR 조합의 실효성

지금까지 DEP와 ASLR의 실효성에 대해 각각 알아보았습니다. 사실 DEP와 ASLR은 조합되어 사용하도록 설계되었습니다. DEP와 ASLR은 운영체제와 함께 배포되는 모든 중요한 응용 프로그램(인터넷 익스플로러 8, 마이크로소프트 오피스 2010, 내장 윈도우 서비스 및 응용 프로그램)에서 활성화되어 있습니다. 이는 공격자들이 이러한 환경의 취약점을 익스플로잇하려고 할 때 두 개의 장애물을 동시에 극복해야 한다는 것을 의미합니다.

지금까지 DEP와 ASLR의 조합을 우회하는 기법에 대한 연구는 ASLR 우회 기법을 가다듬는 것에 집중되어 있습니다. ASLR을 먼저 우회할 수 있다면 DEP도 ROP 등의 기법을 통해 우회할 수 있습니다. 현재 웹 브라우저나 특정 서드파티 응용프로그램 환경에서는 DEP와 ASLR 조합을 우회할 수 있는 익스플로잇들이 많이 나왔습니다. 이러한 익스플로잇들은 예측 가능한 DLL 매핑, 주소공간 정보유출, JIT 스프레이를 통해 ASLR을 우회하고, ROP나 JIT 스프레이를 통해 DEP를 우회하였습니다. 대부분의 경우 이러한 익스플로잇들은 서드파티 컴포넌트와 함께 배포되는 DLL로 인한 예측 가능한 매핑에 의존하거나, 사용자가 추가로 설치하는 브라우저 플러그인에서 제공하는 JIT 컴파일 기능을 이용하고 있습니다. 만약 이러한 컴포넌트들이 설치되어 있지 않다면 익스플로잇들은 실패하게 됩니다.

DEP와 ASLR 조합을 우회할 수 있는 익스플로잇을 만들 수는 있지만, 오늘날 만들어진 대부분의 익스플로잇은 대응 기술을 활성화하지 않은 응용프로그램이나 플랫폼을 목표로 하고 있습니다. 이는 DEP와 ASLR의 조합이 현재 구현의 취약점에도 불구하고 매우 강력한 기법이라는 것을 의미합니다.

요약: DEP와 ASLR의 조합은 매우 효과적입니다. 그러나 이 조합의 실효성은 ASLR의 실효성에 크게 의존합니다. 현재 웹 브라우저와 서드파티 응용프로그램에서 DEP와 ASLR의 조합을 우회할 수 있는 익스플로잇들이 나와있습니다. 그럼에도 불구하고, 현 시점까지 대부분의 익스플로잇은 DEP와 ASLR 조합을 우회하려고 시도하지 않고 있습니다.

앞으로의 방향

앞으로 대응 기술이 일반화되면 공격자들은 DEP와 ASLR의 조합을 우회할 수 있는 익스플로잇을 개발하는데 많은 노력을 기울이게 될 것입니다. 앞으로도 우회 기술에 대한 연구 내용을 이용하여 대응 기술을 발전시키는데 노력할 것이지만 지금 이 자리에서 알리고 싶은 2가지 개선 사항이 있습니다.

첫번째는 Enhanced Mitigation Experience Toolkit (EMET) 최신 버전에 포함된 ASLR 강제 (mandatory ASLR) 기능입니다. 이 기능은 모듈이 ASLR을 고려하여 작성되든 말든 상관없이 ASLR을 강제합니다. (이는 윈도우 비스타 이상의 운영체제에서 예측 가능한 DLL 매핑을 효과적으로 제거합니다.) 이 기능은 위에서 언급했던 ASLR 우회 기법을 불능화하고 이미 실전에서도 효과적으로 익스플로잇을 막아낸 바 있습니다. 두번째는 JIT 스프레이에 대응하는 기술인데 최근에 릴리스된 인터넷 익스플로러 9 베타의 자바스크립트 JIT 컴파일러에 포함되어 있습니다. 이 기술들은 JIT 스프레이 기법에 대한 대책입니다.

이러한 대응 기술들은 알려지지 않거나 패치되지 않은 취약점을 가진 소프트웨어를 사용하는 고객에게 추가적인 보호 수단을 제공합니다. 궁극적으로 우리의 목표는 안정적으로 동작하는 익스플로잇을 만들기 매우 어렵게 하는 것입니다.

권고사항

기업 및 일반 사용자 대상

현재 사용하고 있는 모든 핵심적인 응용 프로그램을 대상으로 DEP를 활성화하고 ASLR을 지원하는 윈도우 버전(윈도우 7 등)을 사용하시기 바랍니다. EMET를 이용하면 DEP를 쉽게 활성화할 수 있습니다. 아래 링크를 참조하십시오.

http://support.microsoft.com/kb/2458544

소프트웨어 벤더 대상

DEP와 ASLR 대응 기술이 효과를 발휘하려면 벤더가 이 기술들을 적용해야 합니다. DEP, ASLR 등 대응 기술을 활성화하는데 필요한 세부사항은 아래 가이드를 참조하십시오.

http://msdn.microsoft.com/en-us/library/bb430720.aspx

Matt Miller, MSEC Security Science

레퍼런스

[1] Dino Dai Zovi. Practical Return-Oriented Programming. 2010년 4월
[2] Dionysus Blazakis. Interpreter Exploitation: Pointer Inference and JIT Spraying. 2010년 2월
[3] Hovav Shacham. Return-Oriented Programming: Exploits Without Code Injection. 2008년 8월
[4] Peter Vreugdenhil. Pwn2Own 2010 Windows 7 Internet Explorer 8 Exploit. 2010년 3월
[5] Hovav Shacham et al. On the Effectiveness of Address-Space Randomization. 2004년
[6] Alexander Sotirov, Mark Dowd. Bypassing Browser Memory Protections. 2008년 8월

by xeraph | 2011-02-06 02:29:22 | 미분류 | 트랙백 (0) | 덧글 (0)

트랙백 주소 : http://nchovy.kr/forum/2/article/667/trackback
이름 암호