Forum: Win32/Win64 API (native code)
by Zacherl,
24. Sep 2015
Ja, konnte das grade bei mir auch beobachten. Da wurde wohl tatsächlich einmal mitgedacht.
Ich weiß ich weiß :P Ist hier nur nicht wirklich von Relevanz. Ging mir eher um die zwei verschiedenen Techniken Längenprefix vs. Nullterminierung.
Konnte auch mit leerem Source und Source als Funktionsargument keinen Unterschied im Assembly ausmachen, aber kann natürlich sein, dass es...
Forum: Win32/Win64 API (native code)
by Zacherl,
24. Sep 2015
Wäre mir neu :D Würde ich mich, selbst wenn es so ist, aber auf keinen Fall drauf verlassen. "Normale" Strings sind in Delphi nicht nullterminiert, sondern enthalten ein vorangestelltes Längenbyte. Unter dem Gesichtspunkt ist für den Delphi Compiler ja keine Notwendigkeit gegeben noch irgendwelche Nullen hinzuzufügen.
Edit:
Zumindest bei neueren Delphi Versionen stehen auf den ersten Blick...
Forum: Win32/Win64 API (native code)
by Zacherl,
24. Sep 2015
Habe den Code jetzt nochmal etwas genauer debuggt, weil mir dieser CopyAndSkipString einfach absolut unsinnig vorkam und habe wohl recht gehabt. Das Problem liegt an einer komplett anderen Stelle.
RtlInitUnicode String erstellt keinen neuen Buffer für den String, sondern setzt das entsprechende Feld lediglich auf die Adresse des Source Strings. PAnsiChar/PWideChar Stringkonstanten packt Delphi...
Forum: Win32/Win64 API (native code)
by Zacherl,
24. Sep 2015
Die Parameter sind nicht gleich. Bei der Decode Funktion ist der Hash ein UCHAR und kein PUCHAR :P
Bei dem ganzen CopyAndSkipString Kram hast du btw. auf jeden Fall einen Buffer Overflow eingebaut. Der Speicher, den du dir per GetMem holst ist unter 32 Bit immer 8 Byte groß. In der Funktion schreibst du aber im Falle von "TestString" 22 Bytes.
