Suse 9.0 + Speicherreservierung für char(stack)

[RedWing]

Hallo,

also unter Windows ist die Differenz bei mir für einen 18 Byte großen Puffer
44 Byte Ich weiß nicht wieso:

stack address of b  =0x22eedc
stack address of test   =0x22eee0
stack address of a  =0x22ef0c

gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht f"ur VERKAUFBARKEIT oder F"UR SPEZIELLE ZWECKE.

CYGWIN_NT-5.1 euklid 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin

Weiterhin hab ich mal folgendes Programm unter Linux gedebugt:

#include <stdio.h>
#include <string.h>

int foo(){
    char test[18];
    strcpy(test, "aaaaaaaaaaaaaaaaaaaaaaaaaa");
    return 0;

}
int main(){
    foo();
    return 0;
}

Also das sollten 26 a's sein. Sprich 18 a's für den Puffer. 4 a's für den
Framepointer, und mit den letzten 4a's wird der eip überschrieben.

Folgendes kam dabei dann raus:

(gdb) r
Starting program: /home/redwing/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x61616161 in  ()
(gdb) info frame 
Stack level 0, frame at 0xbfad770c:
 eip = 0x61616161; saved eip 0x61616161
 called by frame at 0xbfad7710
 Arglist at 0xbfad7704, args: 
 Locals at 0xbfad7704, Previous frame's sp is 0xbfad770c
 Saved registers:
  eip at 0xbfad7708
(gdb) q
The program is running.  Exit anyway? (y or n) y

Eventuell versuchst du das auch mal bei dir, würd mich intressieren was bei rumkommt.

Das mit diesen 44 Bytes unter Windows hab ich keine Erklärung dafür

Gruß,
RedWing

 

[RedWing]

Das müsst eigentlich stimmen was du sagst.
Wenn du ein C Programm oder was auch immer disassemblierst schaut das so aus:
mov esp, ebp (glaub intel syntax - von rechts nach links)

push ebp
mov ebp,esp (intel syntax glaub ich ... von rechts nach links)
...

pop ebp
mov esp,ebp

ja ich denk auch.
Unter dem M68K gabs dafür die Instruktion "link A6, n" (wobei n = Anzahl der Bytes,
welche die funktionslokalen Parameter belegen, ist) beim Eintritt in ein
Unterprogramm.
Sprich so werden die Register dann gesichert:

SP <- SP - 4 (um den Stackpointer eins weiterzusetzen)
(SP) <- A6 (A6 wird in den Inhalt von SP(StackPointer) gerettet)
A6 <- SP (In A6 wird der aktuelle Stackframe gemerkt)
SP <- SP + n (Der StackPointer wird um die Anzahl der Bytes der funktionslokalen 
Variablen nach oben gesetzt)

und immer wenn in einer Hochsprache, wie C ein
return kommt wird das dann durch ein

unlnk A6
rts

ersetzt, wobei unlnk genau die oben beschriebenen Schritte wieder "rückgängig"
macht.

Gruß,
RedWing

 

[RedWing]

Wie genau komm ich da ran? Kann mir valgrind vielleicht dabei helfen? Oder cachegrind?

Also valgrind nicht aber du kannst dir den Frame im gdb anschauen, siehe
vorvorletzer Post...

Gruß,
RedWing

 

[Nebuchadnezar]

@Redwing
Danke, du hast endlich in Linux das probiert was ich die ganze Zeit wissen wollt.
Komisch dass bei dir ned auf 20 erweitert wird. Zumindest reserviert dir das prog bei 18 wenigstens ned 40 (18 -> 0x12 -> 0x20 ->0x28) = 40 byte, was mir völlig unerklärlich ist.
Das bei dir 44 reserviert werden ist komisch aber das liegt vielleicht an der windows version vom gcc die ich übrigens nirgends gefunden hab oder hast cygwin verwendet?.
...ups das is mingw
naja wie ma sieht schaut die theorie anders als die Praxis aus..
gut zugegeben es steht auch in manchen quellen bei shellcode sollte man vorher ein paar nops einschläußen dann hat ma ned so das problem den puffer zu erwischen. Aber dass in Linux nirgends so wie es logisch ist auf 20 erweitert wird wundert mich(naja ist anscheinend compilersache und jeder compiler optimiert anders bezüglich adressierung)
Für den Fall dass du Visual Studio/Borland CBuilder/borland c++ installiert/griffbereit hast,
könntest es damit testen.

 

[RedWing]

Das bei dir 44 reserviert werden ist komisch aber das liegt vielleicht an der windows version vom gcc die ich übrigens nirgends gefunden hab oder hast cygwin verwendet?.
...ups das is mingw

Naja ich hab bei mir cygwin installiert und AFAIK hat cygwin den mingw
Compiler mit an Board...

naja wie ma sieht schaut die theorie anders als die Praxis aus..

Traurig aber wahr

Für den Fall dass du Visual Studio/Borland CBuilder/borland c++ installiert/griffbereit hast,könntest es damit testen.

Da muss ich leider passen...

Gruß,
RedWing