IDA śledzi wartość wskaźnika stosu (ESP) podczas statycznej analizy całej funkcji. Największa ujemna wartość ESP (w stosunku do początku funkcji) jest używana do określenia rozmiaru ramki stosu.

Jeśli chodzi o to, dlaczego wysłane przez Ciebie ramki stosu mają „niezdefiniowane” bajty na górze, dzieje się tak dlatego, że IDA nie mogła automatycznie określić, czy i jak te przesunięcia stosu były używane.

Dziękuję bardzo za odpowiedzi i komentarze. Czytając Wasze komentarze i przygotowując się do aktualizacji pytania, znalazłem odpowiedź.

Muszę przyznać uznanie Igorowi Skochinskiemu, który poprosił mnie o dostarczenie instrukcji dotyczących prologu funkcji. Obie funkcje używają konwencji wywoływania cdecl. Jednak konwencja wywoływania nie ma nic wspólnego z tym buforem. Oto jak wygląda prolog:

  push ebpmov ebp, espsub esp, <size of local vars>push ebxpush esipush edi  

Ten bufor odzwierciedla trzy instrukcje push dla rejestrów EBX, ESI, EDI. Rejestry te są klasyfikowane jako Callee Saved Registers , a ten „bufor” nosi nazwę Non-Volatile Register Save Area .

Zgodnie z konwencją x86 (ma to również zastosowanie do x64), rejestry są podzielone na Zapisane rejestry dzwoniących i Zapisane rejestry Callee .

Rejestry zapisane dzwoniącego są również znane jako rejestry ulotne. Są to główne rejestry procesora, takie jak EAX, EDX i ECX. Funkcja wywołująca (Caller) jest odpowiedzialna za zapisywanie ulotnych rejestrów na zwykle stosie czasu wykonywania przed wykonaniem wywołania.

Zapisane rejestry wywoływane są znane jako rejestry nieulotne. Są to główne rejestry procesora, takie jak EBX, ESI, EDI, ESP i EBP. Konwencja zakłada, że ​​wartości w tych rejestrach zostaną zachowane przez funkcję wywoływaną. W przypadku, gdy którykolwiek z rejestrów nieulotnych ma być używany wewnątrz wywoływanego, odbiorca jest odpowiedzialny za zapisanie rejestrów na stosie wykonawczym. Ponadto odbiorca jest odpowiedzialny za przywrócenie tych rejestrów przed powrotem do funkcji wywołującej.

Sposób, w jaki używane są rejestry ulotne i nieulotne, jest raczej sterowany przez kompilator. Poniższy dokument x86 Assembly Guide bardziej szczegółowo opisuje zasady dzwoniącego i wywoływanego.

Zrzuty ekranu pokazują, że badasz szczegółowy widok stosu IDA.

IDA nadaje nazwę każdemu bajtowi, do którego dostęp jest bezpośrednio w funkcji, pozostałe bajty pozostają niezdefiniowane.

Konwencja telefoniczna? Podaj nam prolog i epilog tego podprogramu, abyśmy mogli zobaczyć, jak stos jest przydzielany i czyszczony.

Więc jeśli jest to ramka stosu normalnej aplikacji napisanej w języku wysokiego poziomu (nie jest to złośliwe oprogramowanie ani napisane w asemblerze ręcznym) i nie wywołując konkretnej konwencji, myślę, że możemy się zgodzić, że kompilator z jakiegoś powodu przydzielił więcej miejsca na stosie, niż potrzebuje ta funkcja.

Nie sądzę, aby wiedzieć dlaczego kompilator to zrobił, ale to twój wybór.