Welcome to gwimong's Blog!
안녕하세요. 귀몽이의 개인 블로그입니다.-
해커의 분류(Gilbert Alaverdian 분류)
-
레이머(Lamer)
해커가 되고 싶지만 경험도 없고 컴퓨터 관련 지식도 많지 않은 해커이다. 이들은 네트워크와 운영체제 대한 지식도 없다. 컴퓨터를 단순히 게임과 채팅, 인터넷 웹서핑 정도로만 사용하다. 대중매체를 통해 해커에 대해 듣고 관련 사이트에서 간단한 해킹 툴을 내려받아 이용하는 초보적은 수준의 해커이다. 컴퓨터에 대한 지식이 없는 채 단순히 해커를 동경하는 사람이 여기에 속한다. -
스크립트 키디(Script Kiddie)
네트워크와 운영체제에 대한 약간의 기술적인 지식을 갖고 있는 해커들이다. 이 분류에 속한 해커들은 GUI 환경의 운영체제에만 익숙하며, 공격 기법도 기존에 잘 알려진 툴을 이용하여 인터넷 사용자를 괴롭히는 것이 전부다. -
디벨롭트 키디(Developed Kiddile)
이 분류에 속한 해커들은 대부분의 해킹 기법을 알고 있다. 해킹 수행 코드가 적용될 수 있는 취약점을 발견할 때까지 여러 번 시도해 시스템 침투에 성공할 수 있는 해커들이다. 보안상의 새로운 취약점을 발견하거나 최근에 발견된 취약점을 주어진 상황에 맞게 바꿀 만한 실력은 없다. -
세미 엘리트(Semi Elite)
이 분류에 속한 해커들은 컴퓨터에 대한 포괄적인 지식이 있고 운영체제와 네트워크에 대한 지식도 갖추고 있으며, 운영체제에 존재하는 특정 취약점을 알고 이 취약점을 공격할 수 있는 해킹 코드를 만들 수 있다. 하지만 해킹 흔적을 완벽하게 지우지 못해 추적당할 수 있다. -
엘리트(Elite)
컴퓨터, 네트웤, 운영체제, 프로그래밍 등 컴퓨터에 대한 포괄적인 지식을 갖추고 있으며, 해킹하고자 하는 시스템의 새로운 취약점을 찾아내어 해킹할 수 있는 최고 수준의 해커다. 또한 해킹을 한 후 흔적을 완벽하게 지울 수 있어 추적하기 힘들다.
-
-
OSI 7 Layer
1984년 OSI(Open System Interconnection)의 네트워크 모델.
이 계층에 따라 최상의 계층에서 최하위 계층으로 데이터를 보낸 후 다시 이의 역순으로 상대 시스템으로 데이터를 전달한다.
(각 계층은 수행하는 역활에 따라 개념적으로 분류한 것임.)-
Physical layer (물리 계층)
물리 계층은 두 시스템간의 무리적 연결을 위한 전기적 메커니즘, 절차, 기능 등을 정의한다.
즉, 전압 레벨, 전압 변환 시기, 물리적 데이터 최대 전송량, 최대 전송 거리, 물리적 커넥터 등과 같은 특성을 정의한다.
일반적으로 랜 카드와 같은 하드웨어 적인 데이터 전송 단계를 물리 계층이라 한다. -
Data Link layer (데이터 링크 계층)
이 계층에서는 로컬 네트워크에서 프레임을 안전하게 전송하는 것을 목적으로 한다.
물리 계층에서 단순히 하드웨어 간에 데이터를 전송하는 것을 담당하였다면 데이터 링크 계층에서는 물리 계층에서 전송하는 데이터의 신뢰성을 제공한다.
즉, 물리적 주소지정, 네트워크 토폴로지, 오류 통지, 프레이므이 순차적 전송, 흐름 제어 등의 기능을 한다. -
Network layer (네트워크 계층)
네트워크를 통한 데이터 패킷의 전송을 담당한다. 경로 제어(routing)와 통신량 제어 등을 수행한다. 각 시스템의 네트워크 주소를 할당하여 관리하는 계층. -
Transport layer (전송 계층)
데이터 전달의 유효성을 제어한다. 즉, 데이터 패킷이 올바르게 전송되었는지를 확인하고 전송 실패한 패킷을 재전송하도록하는 흐름을 제어한다. -
Session layer (세션 계층)
Point-to-Point 연결에 신뢰성 있고 투명한 데이터 전송을 제공한다.
즉, 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다.(동시 송수신 방식, 반이중 방식, 전이중 방식 등) -
Presentation layer (표현 계층)
코드 간의 번역을 담당하여 서로 다른 사용자 시스템이 데이터 전송이 가능하게 한다. -
Application layer(응용 계층)
응용 계층을 프로세스와 직접 관계하여 해당 프로세스와 연결을 제공한다.
예시
파일 전송 시
- 컴퓨터의 랜카드에서 케이블을 통해 데이터를 전송(물리 계층)
- Mac 주소를 바탕으로 데이터를 패키징(데이터 링크 계층)
- 할당된 IP주소를 기반으로 라우터를 통해 목적지까지 데이터 패킷을 전송(네트워크 계층)
- TCP 프로토콜을 이용하여 전송된 패킷의 오류 검사를 통해 해당 패킷이 올바르게 전송되었는지를 검사( 전송 계층)
- 응용프로세스에서 원하는 패킷이 올바르게 전송되었는지를 확인하고 연결 상태를 관리(세션 계층)
- 전송된 EBCDIC로 인코딩된 문서 파일을 ASCII로 인코딩된 파일로 바꿈(표현 계층)
- 파일을 전송하고자하는 시스템의 응용프로세스와 수신하고자 하는 응용프로세스의 연결을 관리(응용계층)
-
-
시디 굽는 방법 - Nero
CD 굽는데 가장 일반적으로 사용되는 Nero 프로그램입니다.
데이터 레코딩 방법
일반적으로 데이터를 단순히 저장용도로 사용하기 위해 굽는 방법입니다.
오디오 레코딩
CDP나 오디오에서 음악을 재생시킬때 사용되는 오디오 cd를 굽는 방법입니다.
디스크 복사
cd를 복사하여 같은 cd를 굽고자 할 때 사용하는 방법입니다. 가상 시디롬을 이용하여 이미지 파일을 cd로 굽고자 할 때 이 방법을 이용합니다.
현재 제 컴퓨터 드라이브 상태입니다.
E:드라이브는 실제 물리적인 cd-rom이 할당되어 있는 드라이브이고, F:드라이브는 데몬으로 인식시킨 가상의 cd-rom드라이브입니다.
F:드라이브에 Adobe Acrobat 9.iso이미지를 불러와 마치 F: 드라이브에 Adobe Acrobat 9 cd가 들어있는것처럼 인식시켰습니다. (데몬 사용법 참조)
이 상태에서 복사하기를 하면 Adobe Acrobat 9 CD를 생성할 수 있습니다.
-
인터럽트와 예외
인터럽트(Interrupt) 정의
: 프로세서가 실행하는 명령어의 순서를 바꾸는 사건
인터럽트는 흔히 동기적(Synchronous)인 인터럽트와 비동기적(Asynchronous)인 인터럽트로 나뉩니다.
동기적 인터럽트는 CPU가 명령어를 실행하는 도중에 발생하는데, 실행중인 명령어의 실행을 마친 뒤에 이를 발생시킵니다. 보통 ‘예외’라고 명시합니다. 프로그래밍을 할때 예외처리 부분을 구현하는데, 이처럼 에러나 커널이 처리해야 비정상적인 상황에 CPU가 이 상황에 대처하기 위한 작업들입니다.
비동기적 인터럽트는 다른 하드웨어 장치가 CPU의 클록 신호와는 상관없이 즉각적으로 발생시킵니다. 보통 인터럽트라하면 이 비동기적 인터럽트를 말합니다. 입출력장치에 의한 경우와 같이 외부의 돌발적인 상황이 발생하였을 경우 CPU는 실행중인 작업들을 일시 중지하고 정해진 인터럽트 작업을 수행하게 됩니다.
인터럽트의 분류
- Maskable Interrupt :
Interrupt Mask가 가능한 인터럽트, 인트럽트 마스크는 인터럽트가 발생하였을 때 요구를 받아들일지 받아들이지 않을지를 지정하는 것입니다. 즉, 마스크 가능한 인터럽트라는 것은 도중에 다른 인터럽트가 발생하였을 경우 CPU는 이를 수용할수도 않할수도 있는 인터럽트 입니다. 입출력 장치가 제기하는 인터럽트 요청과 거의 대부분의 인터럽트가 여기에 해당됩니다. - Nonmaskable Interrupt: Interrupt Mask가 불가능한 인터럽트, 몇몇 심각한 사건(예를 들면 정전이나, 하드웨어 고장과 같은 어찌할 수 없는 오류)만이 이 마스크 불가능한 인터럽트를 발생시킵니다.
예외 분류
프로세서가 감지하는 예외
: CPU가 명령어를 실행하다가 비정상적인 상황을 감지할 때 발생. cpu가 예외를 발생시킬 때 커널 모드 스택에 저장장하는 eip 레지스터의 값에 따라 3분류로 나뉩니다.
-
Faults : 저장된 eip 값은 폴트를 일으킨 명령어의 주소이기 때문에 일반적으로 고칠 수 있으며, 고쳐지면 해당 프로그램은 재시작되어 하던 작업을 이어서 수행할 수 있습니다. 자주 볼수 있는 ‘페이지 폴트’가 이에 해당됩니다.
-
Traps : 트랩을 발생시키는 명령어를 실행하자마자 발생합니다. 프로그램은 커널로부터 제어권을 다시 돌려 받은 후에 이어서 실행할 수 있습니다. eip에는 트랩을 발생시킨 명령어 다음에 실행해야 하는 명령어의 주소입니다. 즉, 트랩은 종료한 명령어가 다시 이어서 수행될 필요가 없을때 사용됩니다. 트랩의 주용도는 디버깅입니다. 디버깅할때 braking point가 이해 해당됩니다.
-
Aborts(중단) : 하드웨어 고장이나 시스템 테이블에 잘못된 값이 들어가 있는 경우가 같이 심간한 오류 상황이 생겼을때 발생합니다. eip 레지스터에 예외를 일으킨 정확한 위치를 저장하지 못하는 경우가 많습니다. 이 예외가 발생하였을 경우에는 문제가 발생한 프로세스를 강제로 종료하는 수 밖에 없습니다.
프로그래밍에 의한 예외
: 프로그래머의 요청이 int, int3 명령어에 의해 발생합니다.
Overflow나 Bound(주소범위 조사)명령어에서 프로그래밍에 의해서 예외를 발생시킵니다. cpu는 이 예외를 Traps로 처리합니다. 이 예외의 일반적인 용도는 시스템 콜을 구현하거나 디버거에 특별한 사건이 발생하였음을 알리기 위한 용도로 사용됩니다.인터럽트가 수행되는 과정
장치에서 인터럽트 신호발생- IC(Inturrupt Controller)에서 신호를 감지
- IC의 입출력 포트에 벡터를 저장하여 cpu가 데이터 버스를 통해 이를 읽을 수 있도록 한다.
- IC는 cpu의 INTR핀으로 발생한 신호를 보낸다. 즉 인터럽트를 발생시킴.
- cpu는 IC의 입출력 포트 중 하나에 값을 써넣어 cpu가 인터럽트 신호를 받았음을 알려준다.
- 마지막으로 INTR선의 값을 0으로 만든다.
80x86 마이크로프로세서의 예외들
IDT(Interrupt Descriptor Table)
이 시스템 테이블은 각 인터럽트와 인터럽트 핸들러의 주소, 예외 벡터와 예외 핸들러의 주소를 연결합니다. 각 엔트리는 인터럽트 벡터 또는 예외 벡터 하나에 대응합니다. IDT에는 세 종류의 이스크립터가 들어갈 수 있습니다.
-
Task gate
인터럽트 신호가 발생할 때 현재 프로세스를 대체할 프로세스의 TSS 셀렉터를 가진다.
-
Interrupt gate
인터럽트나 예외 핸들러의 세그먼트 셀렉터와 세그먼트 내 오프셋을 가진다. 해당 세그먼트로 ㅈ제어를 넘길 때 프로세서는 IF 플래그를 0으로 만들어 마스크 가능한 인터럽트가 더는 발생하지 않게 한다.
-
Trap gate
인터럽트 게이트와 비슷하지만 해당 세그먼트로 제어를 넘길 때 프로세서가 IF플래그를 바꾸지 않는다는 차이점이 있다.
인터럽트와 예외의 처리 과정
인터럽트 수행 과정
- 발생한 인터럽트나 예외의 해당하는 벡터 i(8bit이므로 0 <= i <= 255)값을 구한다.
- idtr 레지스터가 가리키는 IDT에서 i번째 엔트리를 읽어 들인다.
- gdtr 레지스터에서 GDT의 기본 주소를 가져와서 IDT 엔트리에 있는 셀렉터가 가리키는 세그먼트 디스크립터를 GDT에서 읽어 들인다. 디스크립터는 인터럽트 핸들러나 예외 해늗ㄹ러나 예외 핸들러를 포함한 세그먼트의 시작 주소를 지정한다.
- 인터럽트가 발생한 곳이 인증된 곳인지 검사한다. 먼저 cs 레지스터의 마지막 두 비트에 들어 있는 CPL(Current Privilege Level, 현재 특권 수준)과 GDT에 들어있는 세그먼트 디스크립터의 DPI(Descriptor Privilege Level, 디스크립터 특권 수준)을 비교한다. 인터럽트 핸들러는 인터럽트를 발생시킨 프로그램보다 낮은 특권을 가질 수 없으므로 CPL이 DPI보다 낮으면 ‘일반보호(General Protection)’을 발생시킨다.
-
선택한 세그먼트 디스크립터의 DPL과 CPL이 다른지 검사한다. 만약 다르다면 제어 유닛은 새로운 특권 수준에 맞는 스택을 사용해야 한다
-
current 프로세스의 TSS 세그먼트에 접근하기위해 tr 레지스터를 읽어 들인다.
-
새로운 특권 수준과 관련된 올바른 스택 세그먼트와 스택 포인터의 값으로 ss와 esp 레지스터를 설정한다. 이 값은 TSS에 들어있다.
-
이전 특권 수준과 연계된 스택의 논리 주소 ss와 esp의 이전 값을 새로운 스택에 저장한다.
-
- Fault가 발생했다면 예외를 발생시킨 명령어의 논리 주소로 cs와 eip를 설정하여 명령어를 다시 실행 할 수 있게 한다.
- efags와 cs, eip의 내용을 스택에 저장한다.
- 예외에 따른 하드웨어 에러 코드가 있으면 스택에 저장한다.
- cs와 eip를 각각 IDT의 i번째 엔트리에 저장된 게이트 디스크립터의 세그먼트 셀렉터와 오프셋 필드로 설정한다. 이 값은 인터럽트 핸들러나 예외 핸들러의 첫 번째 명령어의 논리 주소이다.
인터럽트나 예외를 처리하고 나면 제어권을 원래 프로세스로 돌려주어야 한다.
제어권 이양 (iret)
- 스택에 저장했던 값으로 cs와 eip, eflags 레지스터를 복구한다. 스택에서 eip 다음에 하드웨어 에러 코드가 들어 있다면 iret를 실행하기 전에 이를 꺼내야 한다.
- 핸들러의 CPLL이 cs의 하위 두 비트에 들어 있는 값과 같은지 검사한다. (만약 같다면 인터럽트 되었던 프로세스가 핸들러와 동일한 특권 수준에서 실행 중이었다는 것을 의미한다) 값이 같으면 iret는 실행을 종료하고 그렇지 않으면 다음 단계로 진행한다.
- 스택에서 ss와 esp 레지스터를 가져와서 이전 특권 수준과 연계된 스택으로 돌아간다.
- ds와 es, fs, gs, 세그먼트 레지스터의 값을 검사한다. 이 중 하나라도 DPL이 CPL보다 낮은 세그먼트 디스크립터를 가리키면 해당 세그먼트 레지스터를 지운다. 제어 유닛이 이런 일을 하는 이유는 CPL이 3인 사용자 모드 프로그램이 이전에 커널 코드에서 사용한(DPL이 0인) 세그먼트 레지스터를 사용하는 것을 막기 위함이다. 레지스터를 지우지 않으면 악의적인 사용자가 이를 이용하여 커널 주소 공간에 접근할 수 있다.
Exception Handing
프로세스에 비정상적인 상황을 알려주기 위한 목적의 시그널을 송신하기 위해 필요.
예외처리를 위한 레지스터 저장
중요 함수들
trap_init() : 예외에 관한 모드 IDT entry에 최종적인 값, 즉 예외를 처리하는 함수들을 지정.
set_trap_gate(0, ÷_error);
set_trap_gate(1, &debug);
set_intr_gate(2, &nmi);
set_system_intr(3, &int3);
set_system_gate(4, &overflow);
set_system_gate(5, &bound);
set_trap_gate(6, &invalid_op);
set_trap_gate(7, &device_not_available);
set_task_gate(8, &31);
set_trap_gate(9, &coprocessor_segment_overrun);
set_trap_gate(10, &invalid_TSS);
set_trap_gate(11, &segment_not_present);
set_trap_gate(12, &general_protection);
set_intr_gate(14, &page_fault);
set_trap_gate(15, &coprocessor_error);
set_trap_gate(17, &alignment_check);
set_trap_gate(18, &machine_check);
set_trap_gate(19, &simd_coprocessor_error);
set_system_gate(128, &system_call);위의 함수들을 trap_int()에서 호출함으로써 예외를 처리하는 함수들을 지정.
ret_from_exception() : 스택에 저장한 사용자 모드 레지스터 주소와 하드웨어 에러 코드를 스택에서 꺼낸 후 jmp 명령어 수행
Interrupt Handiling
인터럽트는 관련된 프로세스가 중단된 후 한참 후 또는 관련 없는 프로세스가 실행 중일 경우 시그널이 도착하는 경우가 많음
-> 현재 수행중인 프로세스에 무작정 시그널을 보내면 안됨- 입출력 인터럽트 핸들링
- IRQ선의 상태를 나타내는 주요 디스크립터 사이의 관계도
- Maskable Interrupt :
-
Windows 기본 프로세스 정리
Visual Studio를 깔아놓으니까 먼 충돌을 이리 많이 일으키는지.. 툭하면 오류나서 디버깅할거냐고 물어보고 해서 제 컴터에서 기본적으로 필요한 프로세스에 대해서 정리 한번 해놓고자 합니다.
alg.exe
주로 방화벽이나 보안과 관련되어 실행되기 때문에 간단하게 말하자면 방확벽 프로세스라고 할 수 있습니다. 다른 응용프로그램들이 클라이언트에서 서버로 포트 통신을 할 때, 수동 TCP/UDP 포트를 동적으로 사용 할 수 있도록 해주는 역확을 합니다.
taskmgr.exe
Windows 작업 관리자 프로세스입니다.
igfxpers.exe
인텔 그래픽 관련 프로세스 입니다.
hkcmdexe
인텔 그래픽 관련 소프트웨어를 설치하면 실행되는 단축기 관련 프로세스입니다.
tp4mon.exe
레노버 ThinkPad 제품에서 실행되는 프로세스입니다. 소위 말하는 ‘빨콩(TrackPoint)’을 위한 프로세스입니다.
spoolsv.exe
프린트 관련 프로세스입니다. 컴퓨터와 프린트 사이의 데이터 전송 속도의 차이를 해결하기 위한 스풀 기능을 위한 프로세스입니다.
svchost.exe
Microsoft Service Host Process로써 DLL로 실행되는 프로세스들을 그룹화 하는데 사용됩니다.
uphclean.exe
유저 정보를 정리해주는 프로세스입니다.
mDNSResponder.exe
아도비사에 만든 “Bonjour”서비스라고 하네요. 아도비사 프로그램을 설치하면 자동으로 실행되는 프로세스입니다.
제거하는 자세한 방법 : http://badnom.com/139
sqlwriter.exe
마이크로소프트 SQL Sever 응용프로그램입니다.
제거하는 제사한 방법 : http://www.windowexe.com/bbs/board.php?bo_table=board01_s&wr_id=383
npkcmsvc.exe
nProtect사의 키보드 보안 프로그램입니다. 평소에는 아무일도 하지 않고 가만히 있다가 키보드 보안이 필요할때 실행되는 프로세스입니다.
게임이나 인터넷 뱅킹하시다보면 자동으로 설치되는 프로그램입니다.
IMEDICTUPDATE.exe
마이크로소프트사에서 제공하는 다국어 문자입력 서비스입니다.
ibmpmsvc.exe
IBM 노트북에서 사용되는 파워관련 프로세스입니다.
isass.exe
윈도우 로그온시 계정과 윈도우의 보안정책을 연결시켜주는 연확을 합니다.
services.exe
시스템 서비스의 시작, 중지 및 시스템 서비스와의 상호 작용을 담당하는 서비스 제어 관리자입니다.
winlogon.exe
로그인 관리자로 로그인과 로그아웃을 처리합니다.
csrss.exe
Clinet/Server Run-time SubSystem의 약어로써 콘솔 윈도우, 쓰레드의 생성/삭제, 16비트 가상 머신의 처리를 담당합니다.
이 프로세스는 강제로 종료할 수 없기때문에 문제가 생기면 조금 골치가 아픕니다.
문제가 생겼을 경우 : http://blog.naver.com/aoobc?Redirect=Log&logNo=70084948457
smss.exe
Session Manager SubSystem의 약어로써 사용자 세션을 위한 프로세스입니다.
문제가 생겼을 경우 : http://blog.naver.com/aoobc?Redirect=Log&logNo=70084948457
wuauclt.exe
윈도우 업데이트 관련 프로세스입니다.
natsvc.exe
그리드 방식으로 데이터를 업로드 시키는 프로세스입니다. 주로 p2p나 웹하드에 접속시 사용되는 프로세스입니다.
하드디스크에 무리를 많이 주는 프로세스이므로 사용하지 않는 경우 종료시켜놓는게 좋습니다.
wscntfy.exe
MS에서 제공하는 윈도우 보안센터 풍선 도움말 프로세스입니다.
ctfmon.exe
고급 입력 서비스 프로세스입니다. 거의 사용되지 않는 프로세스입니다. 제거하는 자세한 방법 : http://qaos.com/article.php?sid=1362
-
NDIS 드라이버와 App 통신하기(IOCTL 통신)
NDIS 드라이버도 여타 다른 드라이버와 마찬가지로 IRP를 이용하여 통신하면 됩니다.
IRP를 이용한 통신은 시스템 버퍼에 데이터를 넣고 드라이버나 어플쪽에서 다시 시스템 버퍼에 접근하여 데이터를 가져오는 방식으로 데이터를 교환하게 됩니다.
드라이버와 App가 연결되었을때 IRP_MJ_CREATE메세지가 생성되고, 해제되었을 때 IRP_MJ_CLOSE 메세지가 생성됩니다. 그리고 App에서 드라이버로 입력이 있을경우 IRP_MJ_DEVICE_CONTROL 메세지가 생성됩니다. 이렇게 생성된 IRP메세지를 저장하고 있는 Irp스택에서 메세지를 가져와 해석하여 App가 어떤 일을 수행하고 있는지를 알수 있습니다.
Passthru에서는 PtDispatch()에 IRP관련된 코드들이 있습니다. 이를 수정하여 드라이버에서 어플에서 보낸 데이터를 가져오는 소스입니다.
먼저 사용할 IOCTL 코드를 만듭니다. CTL_CODE를 이용하여 생성하면 됩니다.
#define IOCTL_EXAMPLE_SAMPLE_DIRECT_IN_IO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_IN_DIRECT, FILE_READ_DATA | FILE_WRITE_DATA) #define IOCTL_EXAMPLE_SAMPLE_DIRECT_OUT_IO CTL_CODE(FILE_DEVICE_UNKNOWN,0x801, METHOD_OUT_DIRECT, FILE_READ_DATA | FILE_WRITE_DATA) #define IOCTL_EXAMPLE_SAMPLE_BUFFERED_IO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x802, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA) #define IOCTL_EXAMPLE_SAMPLE_NEITHER_IO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x803, METHOD_NEITHER, FILE_READ_DATA | FILE_WRITE_DATA)METHOD_IN_DIRECT METHOD_IOUT_DIRECT METHOD_BUFFERED <– 요놈 METHOD_NEITHER
FILE_READ_DATA | FILE_WRITE_DATA <– 이부분이 버퍼에 접근 옵션입니다. 이 옵션에 따라서 SystemBuffer에 IO매니저가 하는 일이 조금 달라지는것 같습니다. FILE_ANY_ACCESS<– 이 옵션으로 해놓은 경우에 어플에서 드라이버로는 갈떄는 시스템버퍼에 데이터를 복사하는데, 다시 드라이버에서 어플로 돌아갈때 시스템버퍼에 잇는 값을 어플에서 받은 outBuffer로 복사하지를 않습니다. (이거때문에 엄청 고생했네요…-_-)
드라이버 입출력하는 방법은 여러가지가 있는데 그중에 METHOD_BUFFERED 방식을 다룰겁니다.
어플에서 DeviceIoControl를 호출하면 드라이버에서선 IRP_MJ_DEVICE_CONTROL 메세지를 날리는데, 이때 SystemBuffer의 주소값을 얻어 여기에 데이터를 읽고 쓰면 됩니다.
[응용프로그램 <->IO관리자<->드라이버]
- 어플에서 InputBuffer를 이용하여 IO관리자에게 넘겨줌
- IO관리자는 이 값을 SystemBuffer에 복사, 드라이버는 SystemBuffer값을 참조하여 데이터를 가져옴
- 드라버에서 SystemBuffer에 어플로 보내고자 하는 데이터를 복사
- IO관리자가 어플로 SystemBuffer의 값을 어플에서 받고자 하는 OutBuffer으로 복사
APP
소스보기
```C #include#include #include //#include #include #include #include #include #include #define IOCTL_EXAMPLE_SAMPLE_DIRECT_IN_IO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_IN_DIRECT, FILE_READ_DATA | FILE_WRITE_DATA) #define IOCTL_EXAMPLE_SAMPLE_DIRECT_OUT_IO CTL_CODE(FILE_DEVICE_UNKNOWN,0x801, METHOD_OUT_DIRECT, FILE_READ_DATA | FILE_WRITE_DATA) #define IOCTL_EXAMPLE_SAMPLE_BUFFERED_IO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x802, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA) #define IOCTL_EXAMPLE_SAMPLE_NEITHER_IO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x803, METHOD_NEITHER, FILE_READ_DATA | FILE_WRITE_DATA) void main() { HANDLE hDevice; LIST_ENTRY first; BOOL hResult; int counter; int buffer_counter; ULONG outputLength; ULONG inputLength; int order; char OutputBuffer[1024] = "bbbbbbbbbbbbbb"; char InputBuffer[1024] = "aaaaaaaaaaaaaa"; ZeroMemory(OutputBuffer, 1024); hDevice = CreateFile(L"\\\\.\\PassThru", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, (HANDLE)INVALID_HANDLE_VALUE); if(hDevice == INVALID_HANDLE_VALUE) { printf("드라이 핸들 얻기 실패\n"); } while(1) { scanf("%d", &order); switch(order) { case 1: hResult =DeviceIoControl ( hDevice,(DWORD)IOCTL_EXAMPLE_SAMPLE_BUFFERED_IO, (PVOID)InputBuffer, sizeof( InputBuffer), (PVOID)OutputBuffer, sizeof( OutputBuffer), &outputLength,NULL); printf("num : %s\n", OutputBuffer); break; } } } ``` </details>  --- ## Driver  > 참고로 2285576 값은 IOCTL_CODE로 생성한 IOCTL_EXAMPLE_SAMPLE_BUFFERED_IO의 값입니다.소스보기
```C NTSTATUS PtDispatch( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp ) /*++ Routine Description: Process IRPs sent to this device. Arguments: DeviceObject - pointer to a device object Irp - pointer to an I/O Request Packet Return Value: NTSTATUS - STATUS_SUCCESS always - change this when adding real code to handle ioctls. --*/ { PIO_STACK_LOCATION irpStack; NTSTATUS status = STATUS_SUCCESS; PCHAR pInputBuffer; PCHAR pOutputBuffer; ULONG inputBufferLength; ULONG outputBufferLength; ULONG FunctionCode; char pData[1024]; pData[0] = 'h'; pData[1] = 'e'; pData[2] = 'l'; pData[3] = 'l'; pData[4] = 'o'; pData[5] = '\n'; UNREFERENCED_PARAMETER(DeviceObject); DBGPRINT(("==>Pt Dispatch\n")); irpStack = IoGetCurrentIrpStackLocation(Irp); switch (irpStack->MajorFunction) { case IRP_MJ_CREATE: DbgPrint(" IRP_MJ_CREATE \n"); break; case IRP_MJ_CLEANUP: DbgPrint(" IRP_MJ_CLEANUP \n"); break; case IRP_MJ_CLOSE: DbgPrint(" IRP_MJ_CLOSE \n"); break; case IRP_MJ_DEVICE_CONTROL: // // Add code here to handle ioctl commands sent to passthru. // DbgPrint(" IRP_MJ_DEVICE_CONTROL \n"); pInputBuffer = Irp->AssociatedIrp.SystemBuffer; pOutputBuffer = Irp->AssociatedIrp.SystemBuffer; inputBufferLength = irpStack->Parameters.DeviceIoControl.OutputBufferLength; FunctionCode = irpStack->Parameters.DeviceIoControl.IoControlCode; switch(FunctionCode) { case 2285576: RtlCopyMemory(pOutputBuffer, pData, strlen(pData)); break; } DBGPRINT(("==> FunctionCode : %d\n", FunctionCode)); break; default: break; } Irp->IoStatus.Status = status; Irp->IoStatus.Information = 1024; IoCompleteRequest(Irp, status, 1024); DBGPRINT(("<== Pt Dispatch\n")); return status; } ```