_memoryread mit 64bit programmen geht nicht! - winapi - profi - frage

Page 2 of 2 1 2
07/24/2011 12:42 Frennzy#16
@all
erstmal herzlichsten dank für den hilfseinsatz und die bemühungen die ihr hier ohne gegenleistung aufbringt! tolle community! vielen vielen dank!

@u-coRe
natürlich ist das teil in 64bit kompiliert (sieht man überigens auch am source)
natürlich wende ich es auf eine native 64 bit applikation an (minsweeper unter 64bit ist nämlich eine)
und natürlich spreche ich von win7 64bit und nicht 32bit. :)

@all
leider funktioniert es bei mir mit dem auslesen nicht, ohne das ich die gründe kenne.
ob wohl ich permanent adminrechte habe, meine UAC ausgestellt ist, ich keine sicherheits-software drauf habe ...etc liefert KillerDeluxe sein script bei mir auch
nicht das was in cheat engine angezeigt wird sondern nur nullen.
ich habe keine ahnung warum.
evtl weiss noch jemand woran es liegen könnte, das es bei mir nicht rennt !?

weiterhin würde mich die frage interessieren (da ich meine scripte nicht jedes mal umschreiben möchte für 64 und 32 bit kompilierung) ob "int_prt" nicht doch das richtige ist... denn so wie ich die info verstehe soll dieser datentyp je nach kompilierung 32bit = int und 64bit = prt einsetzten... kann das jemand bestätigen ?
07/24/2011 12:56 buFFy!#17
int_ptr klingt für mich wie int pointer, also wie int*. sprich ein zeiger auf nen integer.. keine ahnung als was zanden das definiert ;>
07/24/2011 13:42 lolkop#18
ptr steht für pointer....

unter 64bit systemen wird ptr automatisch als 8byte pointer genutzt.
selbiges gilt auch für handles, welche man als hwnd definieren kann.

deshalb sollte man handles immer als hwnd, und adressen (pointer) immer als ptr definieren, für die restlichen werte hingegen, nimmt man im normalfall immer die üblichen typen-deklarationen (int, long, float, double)
07/27/2011 11:25 Frennzy#19
so, nach einigem hin und herprobieren melde ich mich mal zurück, um zumindest diejenigen die hier nochmal lesen, da sie ein ähnliches problem habe, etwas aufzuklären. als erstes:... ich kann in keinster weise nachvollziehen das killerdeluxe die bytes an der adresse auslesen konnte. denn wie es scheint, handelt es sich bei meinem "fehler" um ein zugriffsproblem... die ursache liegt wohl darin, dass ich zwar die rechte für den prozessraum zu scheinen habe. aber die von mir hier im beispiel angegebene adresse liegt wohl außerhalb des geöffneten prozesses (minesweeper.exe) .... <vermutung> in meinem beispiel war es eine adresse, die ich beim scannen mit cheat engine fand... und cheat engine scannt wohl den gesammten speicher, (wohl auch wenn man nur einen prozess geöffnet hat!?). der wert gehörte dann wohl zu irgendwas anderem....</vermutung> das ist zumindest meine erklärung, warum es bei mir nicht klappt... (kann aber auch falsch sein :D ) denn im speicherbereich des ausführbaren codes kann ich problemlos schreiben/lesen. na ja, ich habe zwar jetzt alles umgeschrieben, denn auch das rechnen mir großen adressen/hexwerten ist in autoit ein problem, zumindest wenn die größe 32bit übersteigt...
07/27/2011 17:36 lolkop#20
willst du mit hexwerten größer als 32bit rechnen, kannst du sie entweder vorher umrechnen in long zahlen, oder du definierst dir selbst operationen über hex zahlen.

Edit:
hier ein beispiel wie man sich addition über hexzahlen definieren könnte:
Code:
$hex1 = "0x1234567890"
$hex2 = "0xFFFFFFFFFF"

ConsoleWrite(HexAddition($hex1, $hex2)&@CRLF)

Func HexAddition($hex1, $hex2, $ergebnis='', $uebertrag='0')
	$hex1 = StringReplace($hex1, '0x', '')
	$hex2 = StringReplace($hex2, '0x', '')
	If $hex1='' And $hex2='' Then Return '0x'&$uebertrag&$ergebnis
	Local $current = Hex(('0x'&StringRight($hex1,1))+('0x'&StringRight($hex2,1))+('0x'&$uebertrag),2)
	Return HexAddition(StringTrimRight($hex1,1), StringTrimRight($hex2,1), StringRight($current,1)&$ergebnis, StringLeft($current,1))
EndFunc
07/28/2011 01:14 Frennzy#21
oh, das geht ja einfach .... :) ich hatte in dezimal gewandelt, dann gerechnet und im anschluß wieder zurück.
07/28/2011 03:20 lolkop#22
der vorteil an dieser art definition, über stringfunktionen ist, das du beliebig große werte zur rechnung nutzen kannst =)

selbst wenn deine hex strings jeweils 100 zeichen lang sind, gibt es hier keine probleme. beim rechnen hingegehn stößt man irgendwann immer auf ein limit =)

diese art von definition (einfache mathematik) könnte man sich auch problemlos für dezimalzahlen oder binärzahlen aufbauen =)
Page 2 of 2 1 2