Bài này thảo luận khái niệm thư viện chia sẻ trong cả Windows và Linux. Đồng thời cũng lướt qua các kiểu cấu trúc dữ liệu khác nhau để giải thích liên kết động làm việc như thế nào trong các hệ điều hành này. Bài này rất hữu ích cho các nhà phát triển hứng thú nghiên cứu vấn đề về hàm ẩn bảo mật, liên quan tới tốc độ liên kết động. Và cũng khẳng định một số kiến thức cơ bản về liên kết động đã được đưa ra trước đây.
Phần một giới thiệu các khái niệm cho cả Linux và Windows, trong đó tập trung chủ yếu vào Linux. Bây giờ trong phần hai chúng ta sẽ xem xét liên kết động hoạt động như thế nào trong Windows và tiến tới so sánh hai môi trường với nhau. Các bạn nên xem lại phần một trước khi tiếp tục với phần hai này. 
Cấu trúc dữ liệu Windows Portable Executable File Format (PE)
Chúng ta biết rằng một section (phân đoạn) là một đoạn mã lệnh hay dữ liệu hợp logic với nhau, và dữ liệu cho một bảng nhập thực thi thì nằm trong một section. Trong phần này chúng ta sẽ xem xét một số section trong các file Windows PE.
Exports section (.edata)
Section “.edata” bắt đầu với cấu trúc thư mục xuất IMAGE_EXPORT_DIRECTORY. Thư mục xuất bao gồm RVAs (relative virtual addresses - địa chỉ ảo quan hệ) của Bảng địa chỉ xuất. Bảng này bao gồm địa chỉ của các điểm vào xuất, dữ liệu xuất và tuyệt đối. Một dãy số thứ tự được dùng để đánh chỉ mục cho bảng địa chỉ. Cơ sở thứ tự (Ordinal Base) phải được trừ cho các số thứ tự trước khi đánh chỉ mục vào bảng.
Export Name Table Pointers (Các con trỏ bảng tên xuất): mảng này chứa địa chỉ trong bảng tên xuất. Các con trỏ liên quan tới cớ sở hình ảnh và được sắp xếp theo thứ tự từ vựng để tìm kiếm nhị phân. Export Name Table bao gồm các tên theo chuẩn ASCII của các điểm vào xuất khẩu hình ảnh.
Export Ordinal Table (Bảng thứ tự xuất): các con trỏ bảng tên xuất khẩu và bảng thứ tự xuất khẩu tạo thành hai mảng song song. Mảng bảng thứ tự xuất bao gồm thứ tự kết hợp với tên xuất được trỏ bởi các con trỏ bảng tên xuất. Thứ tự sẽ được dùng như là chỉ mục trong EAT.
Imports Section(.idata)
Section “.idata” là ngược lại với section e.data mô tả ở trên. Nó bản đồ hoá các symbol hoặc thứ tự trở lại RVAs. Phân đoạn i.data bắt đầu với một bảng thư mục nhập IMAGE_IMPORT_DIRECTORY. Bảng thư mục nhập này bao gồm một mảng cấu trúc IMAGE_IMPORT_DESCRIPTOR. Trong đó mỗi phần tử tương ứng với một thực thi. IMAGE_IMPORT_DESCRIPTOR bao gồm RVAs của:
Import Lookup Table (Bảng tra tìm nhập): đây là mảng của cấu trúc IMAGE_THUNK_DATA. Cấu trúc này bao gồm thứ tự hay hint (gợi ý) hoặc tên của mỗi hàm nhập. Bảng nhận dạng các ký tự nhập khẩu, với điểm vào trong Bảng tra tìm nhập khẩu là song song với điểm vào trong Bảng địa chỉ nhập (Import Address Table - IAT). Nếu bit cao của điểm vào được thiết lập, các bit thấp sẽ là thứ tự. Nếu không thì điểm vào là một RVA của đầu vào trong bảng hint-name.
Import Address Table (Bảng điạ chỉ nhập): đây cũng là một mảng của cấu trúc IMAGE_THUNK_DATA. Ban đầu cả Bảng tra tìm nhập khẩu và Bảng địa chỉ nhập khẩu chứa các điểm vào tương tự nhau. Bộ nạp có tác dụng điền địa chỉ cho các chu trình nhập trong bảng này, trong khi đó các mục trong Import Lookup Table giữ lại dữ liệu gốc như trước. Chúng ta sẽ xem vì sao mối liên kết lại duy trì thông tin gốc muộn hơn khi chúng ta nói đến sự liên kết.
Hint-name Table (Bảng gợi ý-tên): Bảng bao gồm một hint (gợi ý) 4 byte theo sau tên với ký tự kết thúc là null. Giá trị hint được dùng để đánh chỉ mục cho mảng Con trỏ bảng tên xuất khẩu, cho phép nhanh hơn là nhập bằng tên. Hint sẽ chính xác nếu DDL không thay đổi hay ít nhất là danh sách ký tự xuất khẩu của nó không thay đổi. Nếu hint không chính xác thì việc tìm kiếm nhị phân sẽ diễn ra trên bảng Export Name Pointer.
Cách thức hoạt động
Nạp một thực thi Windows và DDL cũng tương tự như nạp một chương trình ELF liên kết động trong Linux. Sự khác nhau là, ở đây mối liên kết là một phần của bản thân nhân kernel. Đầu tiên nhân kernel sẽ bản đồ hoá một thực thi dẫn bởi tiêu đề của PE. Bộ nạp xem xét IAT của modul và do tìm xem liệu DDL có phụ thuộc vào phần thêm DDLs hay không. Nếu có thì bộ nạp cũng bản đồ hoá chúng. Tiến trình này tiếp tục cho đến khi tất cả modul phụ thuộc đã được bản đồ hoá vào bộ nhớ.
Một hàm nhập có thể được lập danh sách theo tên hoặc theo số thứ tự. Thứ tự thể hiện vị trí của nó trong Bảng địa chỉ xuất khẩu DDL. Nếu lập danh sách bằng tên, bộ nạp thực hiện cuộc tìm kiếm nhị phân trong Bảng con trỏ tên xuất khẩu của DDL tương ứng để tra tìm chỉ mục của ký tự đã biết. Sau đó nó dùng chỉ mục này như là chỉ mục trong Bảng thứ tự xuất khẩu để lấy ra thứ tự. Sau đó thứ tự này trả ra giá trị được dùng như chỉ mục trong Bảng địa chỉ xuất khẩu. Việc thêm RVA của ký tự tìm thấy trong bảng EAT thành địa chỉ nạp của DDL tương ứng tạo ra điạ chỉ tuyệt đối mà bộ nạp ghi trong mục tương ứng của bảng IAT.
Nạp trễ trong Windows
Một DDL nạp trễ có cấu trúc ImgDelayDescr tương tự cấu trúc thư mục nhập khẩu .idata, nhưng nó không nằm trong phân đoạn .idata. ImgDelayDescr bao gồm điạ chỉ của một IAT và một INT cho DDL. Những bảng này giống hệt định dạng của các bảng nhập thông thường khác. Nhưng chúng được ghi và đọc bởi mã thư viện thời gian thực hơn là bởi hệ điều hành. Khi lần đầu tiên bạn gọi một API từ một DDL nạp trễ, thư viện thời gian thực nạp DDL (nếu cần), lấy địa chỉ và lưu trữ nó trong IAT nạp trễ để sau này gọi trực tiếp tới API.
Sơ bộ về Windows lazy linking procedure
Trong phần này chúng ta sẽ nói về mối liên kết thực hiện định nghĩa cho địa chỉ hàm trong một DDL nạp trễ như thế nào, cũng như ngữ nghĩa của việc tạo các cuộc gọi hàm, nơi hàm được định nghĩa trong DDL.
Hình 7. Mối liên kết giải quyết địa chỉ hàm trong một DDL nạp trễ.
Trong trường hợp trên fndll1() được định nghĩa bên trong d111(delay load) và fndll2 được định nghĩa bên trong d112. Nếu bạn chú ý các khai báo, fndll1() đã được khai báo rõ ràng là __declspec(dllimport). Bộ sửa đổi hàm __declspec(dllimport) nói rằng trình biên dịch mà hàm đang cư trú nằm trong một DDL khác. Trình biên dịch cần mã CALL DWORD PTR [xxxx] clue và generate, trong đó [xxxx] là một mục trong bảng IAT.
Hình 8. Trình biên dịch tạo mã CALL DWORD PTR [xxxx], trong đó xxxx là một điểm vào trong IAT.
Trong trường hợp của fndll2(), trình biên dịch đưa ra một lệnh gọi với dạng CALL xxxxx, trong đó xxxxx trỏ tới một gốc. Kêt quả là một làm mất thêm thời gian để thực thi.
Hình 9. Lệnh nhảy thêm làm mất thêm thời gian để thực thi
Như đã chỉ ra trong hình 8, fndll1() gọi một kết quả trong CALL DWORD PTR[0x412760]. Sau đó 0x412760 là điạ chỉ của điểm vào đầu tiên trong bảng địa chỉ Delayimport như được chỉ ra trong hình 10:
Hình 10. Tìm kiếm địa chỉ của đỉêm vào đầu tiên trong bảng Delayimport.
Điểm vào này trỏ tới một thường trình giúp đỡ tìm và nạp trong DDL và sau đó thay thế nội dung của bảng địa chỉ bằng địa chỉ thực.
Hình 11.
Hình 12.
Như bạn có thể thấy ở trên, địa chỉ 0x412760 được trỏ trước 0x40104b, là địa chỉ của thường trình giúp đỡ, bị bộ nạp ghi đè thành 0x351070, điạ chỉ của fndll1 như hình 13 sau:
Hình 13. Địa chỉ thường trình giúp đỡ bị ghi đè.
Bên trong trình giúp đỡ nạp trễ
Windows cho phép bạn nạp thêm thường trình giúp đỡ nạp trễ của riêng bạn. Bây giờ chúng ta sẽ tìm hiểu đặc trưng bên trong của thường trình giúp đỡ. Các bạn nên chú ý sự tương tự của thủ tục liên kết lười biếng với phần đếm của nó trong Linux.
Hãy bắt đầu bằng việc nhìn lại hình 9. Nếu bạn chú ý, bạn có thể thấy mối liên kết thêm vào hai kiểu stub (gốc). Một kiểu là __imp_load_(function name), và kiểu kia là __tailmerge_(dllname). Như đã thấy từ quy ước đặt tên, kiểu đầu tiên của stub được tạo ra trên từng API, cho DDL, và kiểu thứ hai là trên từng DDL.
Trong hình 9, câu lệnh thực hiện một lệnh nhảy tới stub__imp_load_(function name) qua Bảng địa chỉ nhập trễ. Trong stub, câu lệnh đầu tiên là:
| Mov eax,offset __imp_fndll1 |
Câu lệnh này di chuyển địa chỉ điểm vào thứ 0 của bảng IAT Delay. (Chú ý rằng đây là điạ chỉ Thường Trình Giúp Đỡ phải cập nhật địa chỉ tuyệt đối). Câu lệnh tiếp theo là lệnh nhảy tới stub cụ thể __tailmerge_(dllname). Trong __tailmerge_ stub, sau khi giữ các thanh ghi ecx và edx, nó thực hiện một lệnh push (đẩy) của thanh ghi eax. Câu lệnh tiếp theo sẽ là:
| Push offset __DELAY_IMPORT_DESCRIPTOR_Dll1 |
Câu lệnh này đẩy địa chỉ của cấu trúc ImgDelayDescr trong DDL1. Cấu trúc dữ liệu được định nghĩa trong DELAYIMP.h.
| typedef struct ImgDelayDescr { DWORD grAttrs; // attributes LPCSTR szName; // pointer to dll name HMODULE * phmod; // address of module handle PImgThunkData pIAT; // address of the IAT PCImgThunkData pINT; // address of the INT PCImgThunkData pBoundIAT; // address of the optional bound IAT PCImgThunkData pUnloadIAT; // address of optional copy of original IAT DWORD dwTimeStamp; // 0 if not bound, // O.W. date/time stamp of DLL bound to (Old BIND) } ImgDelayDescr, * PImgDelayDescr; typedef const ImgDelayDescr * PCImgDelayDescr; |
Bây giờ chương trình hàm thực hiện một lệnh nhảy tới Thường Trình Giúp Đỡ với các giá trị trong ngăn xếp là các đối số. Từ giờ trở đi chúng ta sẽ xem xét vấn đề dựa trên mã giúp đỡ được định nghĩa trong DELAYHLP.CPP:
| __delayLoadHelper(PCImgDelayDescr pidd, FARPROC * ppfnIATEntry) |
Bộ Giúp Đỡ Tải Trễ đầu tiên cố gắng lấy quyền điều khiển modul từ ImgDelayDescr.
| //Tính toán chỉ mục hàm, là một chỉ mục hàm trong IAT. iINT = IndexFromPImgThunkData(PCImgThunkData(ppfnIATEntry), pidd->pIAT); |
Như đã nói trước đây IAT và INT là hai cấu trúc song song:
| //Dùng chỉ mục hàm để trỏ tới chỉ mục tương ứng ở INT. PCImgThunkData pitd = &((pidd->pINT)[iINT]); //Lấy tên hàm hay thứ tự từ INT phụ thuộc xem liệu bit thiết lập cao hơn đã được nói chưa. if (dli.dlp.fImportByName = ((pitd->u1.Ordinal & IMAGE_ORDINAL_FLAG) == 0)) { dli.dlp.szProcName = LPCSTR(pitd->u1.AddressOfData->Name); } else { dli.dlp.dwOrdinal = IMAGE_ORDINAL(pitd->u1.Ordinal); } If (hmodule =0) //the first time { // Nạp thư viện // Sao chép quyền điều khiển biến số mở rộng (Call Free library() // Nếu mối đe doạ khác ở đó trước chúng ta) } |
Bây giờ chúng ta phải tìm địa chỉ của chương trình con thủ tục bằng cách gọi hàm GetProcAddress(), như đã đề cập ở trên trong phần giải thích “Cách thức hoạt động”.
| pfnRet = ::GetProcAddress(hmod, dli.dlp.szProcName); |
Chúng ta cập nhật điểm vào IAT với địa chỉ:
| *ppfnIATEntry = pfnRet; //Quay lại __tail_merge_dll1 |
Bây giờ thanh ghi eax chứa giá trị trả về là các địa chỉ hàm tuyệt đối, cuối cùng mã lệnh thực hiện:
| Jmp eax // nhảy tới hàm. |
Liên kết động Explicit
Cả Linux và Windows đều cung cấp các thường trình (chẳng hạn dlopen() và dlsym() trong Linux, LoadLibrary(), GetProcAddress() trong Windows) để nạp dứt khoát một thư viện và tìm địa chỉ của thường trình trong thư viện đó. Các thường trình này chỉ là các trình bao bọc, trả ra lời gọi thường trình liên kết động đã được gọi trước đó trong thời gian thực hiện liên kết ẩn qua PLT hay IAT.
Tăng tốc độ - Thư viện chia sẻ liên kết tĩnh
Thư viện chia sẻ trong thực tế có thể rất chậm. Sự giảm sút trong quá trình thực thi diễn ra chủ yếu do chế độ nạp thời gian thực và liên kết địa chỉ, không trực tiếp tham chiếu tới địa chỉ thường trình qua các bảng trực tiếp và việc dành riêng các thanh ghi máy cho các bảng này. Ngày nay, với không gian điạ chỉ lớn, có thể ghép nối một thư viện với một đoạn không gian địa chỉ tại thời gian liên kết và cũng giải quyết vấn đề tham chiếu địa chỉ. Nếu không gian địa chỉ đã sẵn sàng tại thời gian chạy, việc định vị lại địa chỉ có thể tránh khỏi. Các thư viện, nơi các địa chỉ chương trình và dữ liệu được ghép nối để thực thi trong thời gian chạy dược xem như là các thư viện liên kết tĩnh.
Prelinking trong Linux
Gilbc là một thư viện chia sẻ trong Linux có thể thực hiện liên kết tĩnh. Với các tuỳ chọn khác, Linux thay thế bằng việc dùng một khái niệm tương tự gọi là prelinking. Một prelink gán một rãnh địa chỉ ảo đơn nhất cho từng thư viện thực thi phụ thuộc và liên kết lại thư viện với địa chỉ cơ sở.
Hình 14. Danh sách thư viện
Nếu bạn kết xuất một thực thi prelink hay một thư viện chia sẻ, bạn sẽ phải chú ý tới sự thay đổi trong định dạng của relocation (xác định lại vị trí). Thông thường kiến trúc IA-32 chỉ dùng định dạng REL, trong đó phần phu chú của relocation chỉ được lưu trữ tại địa chỉ offset. Chỉ trường hợp bạn có thể thấy một phân đoạn RELA dạng IA-32 thì nó mới ở đó.
Từ khi các thư viện chia sẻ prelink được dùng, thậm chí trong những thực thi non-prelinked, thông tin phụ chú đã được lưu giữ lại. Để làm điều này, một prelink chuyển phân đoạn .rel.dyn thành dạng RELA. Prelink tránh thực hiện điều này trong trường hợp các phụ chú là 0 bằng cách thay đổi kiểu định vị lại vị trí thành R_386_GLOB_DAT.
Hình 15. Duy trì thông tin phụ chú.
Tiện ích prelink cũng tạo ra một danh sách các xung đột trong quá trình thực hiện và lưu trữ nó bên trong thực thi. Văn bản ELF mổ tả các ký tự không được định nghĩa trong thư viện chia sẻ phải được tìm kiếm đầu tiên trong chương trình thực thi chính, sau đó mới tìm kiếm trong các thư viện chia sẻ cần thiết. Không phải tất cả các ký tự đều được tìm như nhau trong pham vi tìm kiếm của một thư viện chia sẻ (chỉ thực hiện khi thư viện chia sẻ là prelink) hay trong phạm vi tìm kiếm ký tự mở rộng. Cả các ký tự cũng được gọi là các xung đột ví định vị lại vị trí các ký tự đó gây ra xung đột vị trí.
Các vị trí định vị lại bị xung đột được để vào một phân đoạn RELA riêng biệt trong một thực thi. Trong trường hợp này Sym.name + phụ chú sẽ gồm địa chỉ thực của biến xung đột (nếu không sẽ xem xét dến khía cạnh phạm vi mở rộng của thực thi).
Hình 16. Giải quyết xung đột.
Trong thời gian chạy đầu tiên liên kết động kiểm tra xem liệu tất cả các thư viện phụ thuộc đã được bản đồ hoá thành công vào các rãnh không gian địa chỉ chỉ định của chúng hay chưa. Và liệu chúng có thay đổi từ khi quá trình prelinking làm việc hay không. Nếu là có, các prelinker chỉ phải thực hiện một vài điều chỉnh được định nghĩa trong danh sách xung đột đã được tạo ra trước đó.
Rebasing (cơ sở lại) và binding (ghép nối) trong Windows
Tương quan lại các vấn đề trong Windows, Windows DLL dùng các khái niệm cơ sở lại (rebasing) và ghép nối (bounding). Mọi chương trình thực thi và modul DLL đều có một địa chỉ cơ sở ưu tiên để nhận dạng địa chỉ mà modul đã bản đồ hóa trong không gian địa chỉ tiến trình. Chẳng hạn với một chương trình thực thi, giá trị mặc định là 0x00400000 và cho một DDL là 0x10000000. Điều này có nghĩa nếu thực thi được liên kết với hai DDL, một trong số chúng sẽ phải định vị lại vị trí trong bộ nhớ. Để tránh điều này, bạn có thể cơ sở lại DDL của bạn bằng cách cho nó một địa chỉ ưu tiên tại thời gian biên dịch. Bạn có thể làm điều này bằng cách chuyển hay cơ sở lại địa chỉ sang các tuỳ chọn project.
Như chúng ta đã thấy chương trình thực thi win32 có hai bảng phân biệt bao gồm các thông tin cần thiết để tìm hàm quan trọng - bảng Import Name và bảng Import Lookup. Bộ nạp chỉ đòi hỏi thêm một bản sao chép. Nối kết dễ dàng hơn trong việc này và ghi đè điểm vào IAT với địa chỉ thực của hàm nhập tại thời gian liên kết. Việc nối kết cũng thêm các thông tin ràng buộc,chẳng hạn như timestamp để ràng buộc chương trình thực thi. Trong thời gian nạp bộ nạp sẽ kiểm chứng xem khu vực ký tự tham chiếu tới trong phân đoạn xuất của DDL có không thay đổi hay không
Để kiểm tra lại tính hợp lệ của các thông tin ràng buộc, PE dùng một cấu trúc dữ liệu IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT được trở bởi thư mục dữ liệu. Cấu trúc này là một danh sách các phần tử IMAGE_BOUND_DESCRIPTOR, tương ứng với từng DDL nhập. Cấu trúc này lưu trữ timestamp, tên của một DDL quan trọng và số tham chiếu chuyển tiếp. Khái niệm chuyển tiếp xuất khẩu là khá xa phạm vi của bài báo này. Nhưng với mục đích hoàn chỉnh thì cũng tốt để biết rằng Windows cho phép bạn tham chiếu tới một API nhập trong một DDL chuyển tiếp từ một DDL khác.
Hình 17. Cấu trúc dữ liệu IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT.
Nếu time stamp của DDL không thay đổi, nó dùng địa chỉ nối kết lưu trữ trong IAT. Nếu không thì nó dùng thông tin trong bảng hint-name để thực hiện các tra tìm thông thương.
Kết luận
Mục đích của bài này là thảo luận khái niệm thư viện chia sẻ trong cả Windows và Linux. Và lướt qua các kiểu cấu trúc dữ liệu khác nhau để giải thích liên kết động làm việc như thế nào. Trong phần một chúng ta đã được giới thiệu về Linux. Phần hai này chúng ta nghiên cứu sâu hơn về liên kết động trong Windows, bao gồm Tiến trình liên kết lười và Trình giúp đõ nạp trễ. Chúng ta cũng xem xét cách tăng tốc độ chủ yếu cho các thư viện chia sẻ, thường hay chậm trong thực tế. Và xem xét vấn đề prelinking trong Linux cũng như tương quan của nó trong windows: rebasing (cơ sở lại) và binding (nối kết).
Hi vọng là loạt hai bài này đã cung cấp cho các bạn cái nhìn sâu sắc hơn và toàn diện hơn về vấn đề liên kết động.
No comments:
Post a Comment