Liên kết động trong Linux và Windows (phần II) doc

Liên kết động trong Linux và Windows (phần II)

Xem lại Phần I
Phần II
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:
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.