Hầu như mọi người quen thuộc với NT đã từng nghe nói tới có một API ẩn được NT sử dụng nội bộ. API này, được gọi là Native API, nó hầu như được ẩn đi khỏi tầm nhìn, với chỉ một số ít trong các function của nó được documented để có thể được truy nhập công cộng. Việc che dấu này có thể dẫn tới một niềm tin rằng Native API có thể cung cấp các ứng dụng có năng lượng diệu kỳ, thậm chí có thể cho phép chúng bypass các biện pháp an ninh được implemented bởi các API chuẩn như Win32. Những suy nghĩ theo dòng này thường dẫn đến Native API conspiracy theory: Microsoft đang giữ API cho chính họ và các ứng dụng của họ để tạo ra lợi thế không cân bằng. Native API lộ ra một vài sắc thái không có sẵn thông qua các documented APIs (Ví dụ, bạn có thể xác định được các file đang mở có phân biệt chữ hoa, chữ thường, những thứ là không thể đối với Win32's CreatFile() hay OpenFile() ), tuy nhiên phần lớn khả năng của APIs là có thể truy nhập thông qua documented channels.
Bài viết này sẽ giới thiệu cho bạn về Native API và cung cấp cho bạn một lộ trình để tìm hiểu những gì có trong API này. Đầu tiên tôi sẽ mô tả Native API là gì, làm thế nào nó được yêu cầu trong các hoạt động bình thường, và làm thế nào sử dụng nó như là một cơ sở hỗ trợ cho các APIs của NT's operating environment subsystems. Sau đó tôi sẽ dẫn bạn vào một tour của API nơi tôi phân chia nó thành các tập hợp của các hàm liên quan (quản lý bộ nhớ, đồng bộ, etc.). Tôi sẽ nói về các khả năng sẵn có thông qua các hàm API và ghi chú Win32 APIs ánh xạ đến các Native APIs cụ thể nơi áp dụng. Một cái nhìn toàn diện về Native API giúp làm rõ các khái niệm sai lầm về cách nó được dùng, tại sao sử dụng nó, và những undocumented APIs đang được ẩn đối với chúng ta (như là có hay không consipary theory hợp lệ).
Native API Architecture
Windows NT Native API phục vụ một mục đích: Như là một ý nghĩa cho việc gọi các dịch vụ hệ điều hành đặt tại kernel-mode trong một thói quen được điều khiển. Kernel-mode nơi nhân của NT thực thi và trong kernel các thành phần có thể truy nhập trực tiếp đến hardware và các dịch vụ thực hiện quản lý tài nguyên máy tính bao gồm bộ nhớ, các thiết bị và các tiến trình. Do vậy, bất cứ khi nào một chương trình thực thi trong user-mode muốn thực thi I/O, cấp phát hay giải phóng bộ nhớ ảo, bắt đầu một thread hoặc một process, hay là tương tác với các tài nguyên cục bộ. Nó phải gọi trên một hoặc nhiều dịch vụ "sống" tại kernel-mode.
Native API là tương tự như giao tiếp gọi hệ thống (system call interface) trên các hệ điều hành nguyên khối truyền thống ví dụ như họ UNIX. Tuy nhiên trên hầu hết các hệ điều hành Unix, system call interface được documented rất tốt và nó luôn sẵn sàng cho các ứng dụng chuẩn. Ví dụ, read() call thực hiện việc đọc dữ liệu từ một file, socket, hoặc một thiết bị đầu vào trong hầu hết các UNIX OS là một system call được thực hiện bởi code trong kernel-mode. Trong Windows NT Natvie API, system call interface của nó, được ẩn khỏi programmers đằng sau APIs cấp cao như Win32, OS/2, POSIX, hoặc DOS/WIN16. Nguyên nhân sự việc đó là do kiến trúc NT.
NT là một kiến trúc "modified microkernel ". Thay cho việc hỗ trợ một OS API cơ bản, NT implement một vài API. Việc đó được thực hiện hiệu quả bởi việc implementing operating environment subsystems trong user mode để xuât khẩu các APIs cụ thể đến các chương trình người dùng. "national language" API của NT là Win32 và kiến trúc Win32 chứng minh khái niệm này. Win32 operating environment subsystem được phân chia giữa một server process , CSRSS.EXE (Client/Server Runtime Subsystem), và client-side DLLs mà được liên kết với các chương trình sử dụng Win32 API. Nhân của Win32 API được chia thành 3 loại: windowing và messaging, drawing và base services. Windows và messaging APIs bào gồm CreateWindow() và SendMessage() , và được export đến Win32 programs thông qua thư viện USER32.dll. BitBlt() và LineTo() là Win32 drawing functions được cung cấp trong GDI32.dll. Cuối cùng, base services bao gồm tất cả Win32 I/O, process và thread, quản lý bộ nhớ, và các APIs đồng bộ và Kernel32.dll là thư viện export chúng.
Khi một Win32 program gọi một Win32 API điều khiển được chuyển từ trong không gian địa chỉ của nó vào một trong những Win32's client-side DLLs. DLL có thể thực thi một hay nhiều lựa chọn sau:
- Lập tức quay lại caller
- Gửi một message đến Win32 server để yêu cầu sự trợ giúp
- cầu khẩn Native APIs để thực hiện function
Lựa chọn thứ nhất hiếm khi xảy ra và chỉ có thể xảy ra khi DLL có thể phục vụ function mà không cần sự giúp đỡ của các dịch vụ hệ điều hành. Một ví dụ là GetCurrentProcess(). API này đơn giản trả lại một handle đến trạng thái hiện hành đã được cached trong KERNEL32 khi process bắt đầu.
Lựa chọn thứ hai cũng hiếm khi được cần đến. một client-side DLL chỉ cần gửi messages đến Win32 server khi server phải cùng tham gia, và phải nhận thức được, thực thi của function. Win32 server tạo một Win32 execution environment cho client của nó mà liên quan đến duy tri một vài trạng thái liên quan đến client processes của nó. Do vậy, CreatProcess() API, exported bởi Win32, yêu cầu một tương tác với Win32 Server. Server trong trường hợp này chuẩn bị một process mới cho việc thực thi thông qua việc mapping trong một excutable image, tạo một command-line argument structure và tương tự. Win32 server gọi Native API functions để tạo process image thực sự và chuẩn bị không gian địa chỉ ánh xạ.
Không có nhận xét nào:
Đăng nhận xét