Das deutsche QBasic- und FreeBASIC-Forum

[MaKo]

Guten Tag,

wenn ich mit allocate Speicher anfordere, ist dieser Bereich dann immer auf Null gesetzt. Dafür sollte doch callocate sein oder?
Ich nutze: FreeBASIC Compiler - Version 1.10.1 (2023-12-24), built for linux-x86_64 (64bit)

Viele Grüße

[nemored]

Ja, richtig; ALLOCATE initialisiert nicht, CALLOCATE dagegen schon. Sollte es zumindest ...

Unter Windows funktioniert ALLOCATE wie erwartet - die Werte werden nicht auf 0 gesetzt. Unter Linux Debian, fbc 1.09, habe auch ich das von dir beobachtete Verhalten. Vielleicht ein Bug im Linux-fbc? Keine Ahnung; vielleicht wissen sie im internationalen Forum mehr.

(Glücklicherweise nicht so schlimm, da der nicht initialisierte Speicher ja auch zufälligerweise nur die Werte 0 enthalten könnte )
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Berkeley]

Kann reiner Zufall sein. Beim Einschalten vom PC ist der RAM erst mal voller Nullen. Das ist ja auch das Problem: du gehst davon aus, dass ein Puffer voller Nullen ist, weils "immer" so war. Irgendwann ist er es aber nicht mehr. Es kracht, und du weißt nicht wieso, weil bei jedem neuen Test nichts mehr passiert... Erschwerend kommt hinzu, dass der Speicherinhalt aus Sicherheitsgründen gelöscht werden muss, was vielleicht nicht in jedem Fall gemacht wird.

Du solltest dich einfach nicht darauf verlassen, dass ein Puffer leer ist. Alle Variablen initialisieren bevor man sie benutzt. Punkt. Dass/wenn BASIC es anders macht ist nur für Programmieramateure bzw. schnell hingeschlampte Testprogramme und auch ein großer Sicherheitsvorteil. Aber darauf sollte man sich nicht stützen.

[nemored]

Einen Zufall würde ich ausschließen, weil ich folgenden Code versucht habe:

[Berkeley]

Genau kann man's nicht sagen und wie schon angedeutet könnte es möglicherweise eine Sicherheitsvorkehrung sein. Wenn man bedenkt dass da im RAM eventuell irgendwelche unverschlüsselten Dokumente rumliegen würden...

Wobei: wenn du den Rechner stundenlang mit irgendeinem fetten Computerspiel laufen lässt, kann man ziemlich ausschließen, dass du danach rein zufällig einen komplett genullten Speicherblock mit malloc()/ALLOCATE kriegst, der nicht extra vom Betriebssystem o.ä. überschrieben wurde.

[dreael]

Theoretisch müsste ein aktuelles Betriebssystem Speicher (Platte und RAM) beim Freigeben oder neu reservieren mit Nullen o.ä. füllen, sonst wären Dumpster Diving-Angriffe möglich, z.B. kleine Schadsoftware, die einfach nur temporär grosse Speicherblöcke reserviert und diese nach interessanten Inhalten durchscannt und passende Funde an einen C&C-Server sendet.

Von dem her wäre ein Experiment denkbar mit 2 FB-Programme. Ein erstes FB-Programm soll ein riesiger (in der Grösse frei wählbarer) Block RAM reservieren und diesen mit einem String-Muster füllen (reicht ja irgend ein "The quick brown fox jumps over the lazy dog." o.ä.) und sich dann normal beenden.

Ein zweites FB-Programm soll ebenfalls viel Speicher reservieren, dort aber nichts initialiseren, sondern nur scannen. Spätestens wenn das zweite FB-Programm unser "quick brown fox"-Muster fündig wird, dann wäre das Betriebssystem anfällig für Dumpster Diving-Angriffe.

Für beide FB-Programme sinnvollerweise 64-Bit verwenden, um auch mit heutzutage üblichen RAM-Austattungen moderner PCs und Notebooks umgehen zu können.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[MaKo]

Hallo,

danke für Eure Expertise und Eure Zeit.

Der guten Ordnung halber:

Ich habe Eure Vorschläge durchgeführt.

Ich habe die Frage im internationalen Forum eingestellt. Bisher gibt es kein Ergebnis.

Ich habe auf einem alten Turion K8 mit 1 GB (Linux 64-Bit) die beiden Programme geschrieben und laufen lassen. Das erste Programm hat 800 MB angefordert und gefüllt. Wenn schon, denn schon.

Anschließend mit dem zweiten Programm 800 MB angefordert und ausgelesen. Alles Nullen.
Scheint also wirklich alles „genullt“ zu werden

Dasselbe Verhalten habe ich übrigens auch bei z. B. „DIM AS UBYTE var = ANY“ festgestellt. Ergibt auch 0. Hierbei bin ich sicher, dass „damals“ unter windows10 (32_bit) Garbage in den Variablen war.

Viele Grüße

[nemored]

[MaKo]

Again what learned!