Blackmoore napisał(a)
Tutaj twierdzą, że ostatnia pozycja w section table wcale nie musi być ostatnią sekcją
http://amdfanatyk.w.interia.pl/download/virii/virii.pdf
"Zwróć uwagę na to, że wpis dotyczący ostatniej sekcji pliku
PE nie musi być ostatnim wpisem w Section header."
Po części mają rację, ale nie istnieje normalne narzędzie generujące binarki z niewłaściwą kolejnością danych w pliku, ułożenie w pamięci i tak musi być sensowne. Także akurat to możesz sobie darować, jeżeli coś ma nienormalną konstrukcję to albo już coś je zainfekowało albo to jakieś cholerstwo, którego i tak lepiej nie ruszać (np. dziwny packer, który może się nieźle wkurzyć na modyfikację pliku i puścić formata w tle).
Sekcje muszą tworzyć względnie ciągły obszar w pamięci (po uwzględnieniu wyrównania, do tego raczej kolejno), fizycznie już nie do końca. Jeżeli chciałbyś tak dokładnie wszystko obsługiwać to się nieźle pobawisz - rozmiar fizyczny sekcji nie przekłada się na rozmiar wirtualny. Za fizycznie ostatnią sekcją mogą leżeć w pamięci kolejne sekcje czysto wirtualne, uniemożliwiając wygodne powiększenie. Takich binarek jeszcze nie widziałem, ale wcale bym się nie zdziwił gdyby istniały.
Ostatnia fizycznie jest ta z największą sumą PointerToRawData i RawSize. Co, jak sam przytoczyłeś, nie musi oznaczać, że masz miejsce coby się tam dopisać - rozmiar wirtualny i wirtualny adres kolejnej (wirtualnie) sekcji. Najwięcej pewności dałoby stworzenie własnej sekcji, tutaj masz gwarancję, że zawsze będzie mieć odpowiednie położenie.
