Deine Baseadresse ist auf dem Bild angezeigt, sie lautet "LCore.exe"+0x0100D9C8
"LCore.exe" ist in deinem Fall die ImageBase des Programms, die Adresse im Speicher an dem dein Programm mehr oder weniger "anfängt".
Du kriegst diese mit _WinAPI_GetModuleInformation, darauf addierst du dann den statischen Offset 0x0100D0C8.
Die Info die du suchst ist "ptr EntryPoint", das ist deine ImageBase.
Dann sollte das auch auf unterschiedlichen Betriebssystemen funktionieren.
Du könntest ja mal einen Pattern Search probieren.
Schau dir die Umgebung um die Prozentanzeige im RAM mit dem Memory Viewer in CE an und such nach Strukturen die dort sind.
Wenn du z.B. vor dem Prozentwert eine Sequenz an speziellen Bytes findest, dann kannst du nach der suchen statt über Pointerarithmetik dorthin zu gelangen.
Du kannst z.B. immer 1024 Bytes in das DllStruct lesen und dann gucken ob du dort deine Sequenz findest (achte dann aber darauf ob es nicht zufällig am Rand liegt) und dann hast du es auch schon.
Ansonsten kannst du schauen ob einfach ein Offset von 0x72DE0000 (Differenz der beiden Werte) reicht wenn du ihn einfach auf die Baseadresse draufaddierst.
Die OS-Verison kannst du ja mit den Makros rausbekommen.
Das hast du richtig erkannt.
Hardlinks/Softlinks sind nur Verweise auf die Dateien, ansonsten müsste dein Betriebssystem bei jedem Bootvorgang den Platteninhalt erstmal cachen um zu wissen welche Dateien existieren.
Stattdessen werden verweise auf Dateien abgelegt, vergleichbar mit Pointern in anderen Programmiersprachen.
Das Windows Dateisystem ist aber sowieso eine Sache für sich. Ordnernamen werden ohne zu fragen einfach der Sprache angepasst und man wundert sich (besonders als Programmieranfänger) warum "C:\Benutzer" oder "C:\Programme (x86)" nicht ansprechbar sind.
Achso, das ist mir gar nicht bisher bekannt gewesen.
Im Moment rufst Du es als 32-Bit-Version auf. Auf einem 64-Bit-System musst Du es aber als 64-Bit-Version aufrufen, damit Du alles zu sehen bekommst.
Wieso? Dateilistungen sollten doch überhaupt keine Rolle für 32-Bit/64-Bit Systeme spielen.
Verwendest du dort auch die 64-Bit Variante von der Software? Wie schaut denn der Pointer dort aus?
Grundsätzlich kann es sein, dass der Basepointer nicht mehr gültig ist. Betriebssysteme verändern über mit Jahren an Entwicklung ihren Kernel und da kann es sein, dass das Memory Mapping dort etwas anders ist.
Ansonsten kannst du ja mal Win7-Kompatibilitätsmodus testen, vielleicht hilfts ja.
eine permanent sichtbare Akkuanzeige halte ich für suboptimal. Die braucht doch ehrlich gesagt kein Mensch. Letztendlich "rechnet" das Gehirn die Anzeige aus dem Bild heraus und stellt nur die "wichtigen" Anzeigen dar.
Ja, wenn man noch weitere Widgets bastelt ist der Desktop dann irgendwann voll wie bei Windows Vista und der Sidebar.
Was ich von meiner Seite empfehlen kann ist, die Maustasten abzufragen.
Bevor ich auf meinem Tisch eine Uhr stehen hatte, musste ich entweder immer das Steam-Overlay anschalten (das buggt manchmal rum und öffnet sich gar nicht), Telefon suchen oder Spiel minimieren (und das kostet bei echten Vollbildmodus schon mal seine Zeit).
Da habe ich mir eine kleine Uhr mit Datum zusammengebastelt die ich mit dem Drücken der linken Maustaste + Extramaustaste (zum Seitenwechseln in Browsern zurück) anzeigen konnte und dann verschwand sobald ich eine der Tasten losgelassen habe.
So sah das ganze aus und ich fand es ziemlich praktisch. Immer wenn ich wissen wollte wie spät es war (im Spiel, im Desktop konnte ich ja die Uhr sehen) einfach zwei Maustasten gedrückt und fertig. Das ganze war in der linken unteren Ecke meines 2. Bildschirms positioniert.
[Blockierte Grafik: https://i.imgur.com/JFsZP9V.png]
Freut mich, dass am Ende doch alles funktioniert hat 
Vielleicht möchtest du das ganze ja noch ein bisschen aufhüpschen (Akkustand auf Desktop zeichnen mit Gdi+) oder ähnliches?
Mit Datentypen meinte ich das rechnen und dem hinzufügen von dem "0x" etc.
Da AutoIt nur Variant als Datentyp hat verrechnet er einige Sachen als String und dann scheitert das ganze auch direkt.
Aber warum versuchst du denn den Wert aus dem DllStruct in "0x" & Hex($ergebnis + $aiOffsets[$i]) umzuwandeln?
AutoIt ist es egal ob in einem DllStruct der Wert als Hex oder Integer eingetragen wird.
Also nimm als $iBase lieber DllStructGetData($tNewStruct, 1) + $aOffset[$i], das müsste eigentlich auch funktionieren.
Ich weiß nicht ob AutoIt die Datentypen richtig handlet aber das schaut richtig aus
Das ist auch der Grund warum die Memory-UDFs immer als 1. Index im PointerOffset-Array eine 0 haben wollen.
Es wird eine einfache For-Schleife verwendet und es wird an baseaddress + offset[0] (dieser ist ja 0) gelesen und dann wird das Ergebnis genommen
und im nächsten Schleifendurchlauf wird an der stelle ergebnis + offset[1] gelesen und immer so weiter.
Nein, du hast mich falsch verstanden!
Du addierst auf das Ergebnis des Auslesens den Offset und dann liest du an der Stelle.
Bisschen einfacher:
$ergebnis1 = Basepointer lesen
$adresse2 = $ergebnis1 + 0x18
$ergebnis2 = $adresse2 lesen
$adresse3 = $ergebnis2 + 0x20
Das Ergebnis der Addition ist schon richtig, du musst nur an der Stelle lesen um dann 0x59F85EFCA0 zu kriegen
Du kannst die Zahlen auch hexadezimal draufaddieren, AutoIt macht keinen Unterschied zwischen 0x10 + 0x10 und 16 + 16.
Die Offsets in CE sind unter Garantie in hexadezimal, also verwende 0x.
Das ist doch schön zu hören
Kannst du das Script mal compilen und so ausführen? Ich weiß nicht ob der Präprozessor reicht um SciTE zu sagen, dass AutoIT die 64-Bit Variante nehmen soll.
Ansonsten probier mal statt int als Parameter PTR, INT_PTR oder LONG_PTR (respektive UINT_PTR, ULONG_PTR).
Int ist in AutoIt nämlich 32-Bit groß und du liest ja in einer 64-Bit Anwendung.
Aber wieso zeigt dir CE nicht mehr den Prozentwert am Ende an? Sicher, dass du den Basepointer erwischt hast? War er in der Liste denn grün?
Ich hätte noch einen Vorschlag. Eine Möglichkeit über einen Klick im Menü an die Stelle wo der Mauszeiger ist diesen Funktionskopf einzufügen:
Die Funktion gibts doch bereits? Zumindest für bereits existente Funktionen wir dann der Header erzeugt.
Ich hab dir mal ein kleines Beispiel zusammengeschrieben.
Starte die tgt.exe und dann trag die Adresse in dem anderen Script ein, das beschreibt die Variable und liest sie anschließend aus.
Mit ein wenig googlen konnte ich das hier finden:
https://www.autoitscript.com/forum/topic/18…memory-reading/
https://www.autoitscript.com/forum/topic/147423-krymemory-udf/
Dein Buffer ist auch nicht richtig. Da musst du den Pointer zu einem DllStruct übergeben.
Der Versuch mit Nomad scheint soweit richtig zu sein, aber die UDF ist leider nicht 64-bit kompatibel.
Es gibt bestimmt andere Memory-UDFs die 64-Bit kompatibel sind.
Denk daran, dass die Offsets Hexadezimalzahlen sind und dementsprechend ist 20h = 32d. Verwende in AutoIt lieber 0x20, 0x10, 0x28, ... als Offsets.
Probier erstmal obs doch mit der Nomad klappt, 1. Index muss 0 sein und dann fehlen noch die 0x vor den Offsets.
