[ALG]Random geheugen uitlezen m.b.v. pointer?

[NaliXL]

Hallo,

Omdat ik best eens nieuwsgierig ben wat er zich allemaal in het geheugen van mijn PC bevind, wilde ik een methode bedenken om zomaar random van een stuk geheugen te lezen (en ja, er zijn vast wel proggies voor die dat al kunnen, en ja, ik wil het écht zelf maken! ). Voor de duidelijkheid, ik kon in MSDN of hier geen standaard-methode vinden om zoiets te doen. Verder weet ik dat alle NT-afgeleiden het niet zullen toelaten.. Maar in ieder geval : mijn idee, en vraag :

Een pointer is een verwijzing naar een geheugenadres, toch? Nou is mijn theorie dat als ik een pointer verander, dat ik dan vanzelf het geheugen-adres waar 'ie naar verwijst kan uitlezen . Mijn vragen :

1. Is dit een goed idee? Het gaat hier voor de duidelijkheid dus om alleen lezen, er word als het goed is geen geheugen overschreven ofzo.

2. Zijn hier andere/betere methodes voor?

3. Als ik een pointer maak naar bijvoorbeeld een integer, en dan m.b.v. die pointer de integer uitlees, word alleen het aantal bytes wat een integer inneemt uitgelezen vanaf het adres waar de pointer naar wijst. Waar ik nou heen wil : hoe bepaalt Windows hoeveel geheugen er moet worden uitgelezen? Dat is dus vanaf het adres waar de pointer naar wijst, tot waar?

4. Zie ik nog wat over het hoofd?

[.oisyn]

1. nee. Bovendien mag je niet overal bij (zou wat zijn als dat wel mocht). Als je dat wel wilt moet je maar in DOS gaan coden

2. Je kunt met win 9x / ME in geheugen kloten van andere processen...[/ME] zie ReadProcessMemory () en WriteProcessMemory ()
Werkt onder NT overigens ook maar ik heb geen idee hoe het dan zit met de rechten (ik weet niet of je zomaar een process mag openen met read/write rechten)

3. Dat bepaald windows niet, maar je processor. op een x86 cpu in 32 bits zijn ints altijd 4 bytes. Er worden dan ook gewoon 4 bytes uitgelezen

4. Nee, behalve dat je niet zomaar bij al het geheugen kan

[NaliXL]

.oisyn schreef op 07 augustus 2002 @ 00:03:
1. nee. Bovendien mag je niet overal bij (zou wat zijn als dat wel mocht). Als je dat wel wilt moet je maar in DOS gaan coden

Hmm, ik dacht dat de Win9X serie helemaal niet moeilijk deed over geheugen. Waarom anders die blauwe schermen van een of ander procesje wat eens te ver in een array heeft geschreven o.i.d.?

2. Je kunt met win 9x / ME in geheugen kloten van andere processen...[/ME] zie ReadProcessMemory () en WriteProcessMemory ()
Werkt onder NT overigens ook maar ik heb geen idee hoe het dan zit met de rechten (ik weet niet of je zomaar een process mag openen met read/write rechten)

Hmm, klinkt al interessant, maar zit je dan niet weer in een afgeschermd stuk geheugen te lezen? Ik wil eigenlijk alles kunnen bekijken...

3. Dat bepaald windows niet, maar je processor. op een x86 cpu in 32 bits zijn ints altijd 4 bytes. Er worden dan ook gewoon 4 bytes uitgelezen

Ja, okee, maar hoe weet windows/de processor nou of er een integer, of een float, of een unsigned integer o.i.d. achter die pointer zit? Zit dat in de pointer zelf opgeslagen?

Verder : bedankt!

[Alarmnummer]

voor de cpu is alles een lading bytes en maakt geen onderscheid tussen types (floating point ff terzijde). Als jij dus 32 bits uit gaat lezen, moet jij weten hoe je die moet intepreteren.

[.oisyn]

NaliXL schreef op 07 augustus 2002 @ 00:19:
[...]
Hmm, ik dacht dat de Win9X serie helemaal niet moeilijk deed over geheugen. Waarom anders die blauwe schermen van een of ander procesje wat eens te ver in een array heeft geschreven o.i.d.?

zoiets geeft geen blauw scherm, maar gewoon een simpel message boxje (jeweetwel: "dit programma heeft een ongeldige bewerking uitgevoerd en zal worden afgesloten"). Wel als een device driver het probeert overigens, of iig een kernel process. Blauwe schermen in gewone programma's heb ik iig nog niet voor elkaar gekregen, maar ik moet zeggen dat ik het ook niet echt geprobeerd heb

Hmm, klinkt al interessant, maar zit je dan niet weer in een afgeschermd stuk geheugen te lezen? Ik wil eigenlijk alles kunnen bekijken...

Dat gaat dus niet
Heeft ook weinig nut, omdat het virtueel geheugen is... het is geen letterlijke afspiegeling van het echte (fysieke) geheugen. Heeft te maken met paging en al die dingen, moet je maar eens een operating systems boek/tutorial erbij pakken. Kun je trouwens ook gelijk lezen waarom het niet handig is dat je zomaar heel het geheugen kunt bekijken

[Verwijderd]

1) Neen geen goed idee, aangezien pointer 0x00123456 in process A naar 'n compleet ander stuk geheugen verwijst dan een pointer 0x00123456 in process B. de Virtual memory manager (vmm die je zo vaak in blauwe schermen ziet in 9x) zorgt dat de juiste pagina zich op dat adres bevind op het moment dat er een leeg/schrijf actie gebeurd op een adres..

2) Ja NT het wel toe om fysiek geheugen te mappen , je moet 't allen lief vragen
zie http://www.sysinternals.com/files/physmem.zip voor 'n sample

3) Je zegt het zelf al, je hebt 'n pointer naar'n bepaald data type, op het moment dat je je programma compileerd is de grote van dat data type bekend en wordt er het juiste aantal bytes gealloceerd voor jouw specifike datatype..(doet windows overigens niet)

4) Genoeg, als je meer wilt weten over de interne werking van windows (de VMM / task schedular ect) kan ik je het volgende boek aan raden : Inside Windows 2000, 3rd Ed

[Delphi32]

Heb ff een testje gedaan met Delphi:

code:

const
  BufSize = 16; //just an arbitrary size for my buffer
var
  Buffer: PByteArray; //= Pointer to Array of Bytes
  i, j: integer;
begin
  {Get a piece of memory that my Buffer variable may point to}
  GetMem(Buffer, BufSize);
  try
    for i := 1 to BufSize do begin
      {Get the integer value of the next byte in the byte array}
      j := Integer(Buffer[i]);
      {Put the hex value of this integer in a list on my screen}
      Memo1.Lines.Add( Format('%x', [j]) );
    end;
  finally
    FreeMem(Buffer);
  end;
end;

Er is ongetwijfeld het een en ander af te dingen aan bovenstaande code (zo lees ik bytes als integers in ) maar het idee mag duidelijk zijn: ik declareer een pointer naar een array of byte, die niet geïnitialiseerd wordt naar nul/nil of wat dan ook. Vervolgens lees ik alle bytes uit die binnen het bereik van mn pointer liggen. Voilà, random input en output! Niet dat ik er iets mee kan maar goed. En ik heb ook weinig invloed op de plek waar Buffer heen mag wijzen na GetMem. Maar het is wel random.

(Ik ben geen pointer guru, dus ik ben zeker benieuwd naar reacties)

[.oisyn]

Alarmnummer schreef op 07 augustus 2002 @ 00:23:
voor de cpu is alles een lading bytes en maakt geen onderscheid tussen types (floating point ff terzijde). Als jij dus 32 bits uit gaat lezen, moet jij weten hoe je die moet intepreteren.

hier wil ik even aan toevoegen dat jij dat bepaald door m in een bepaald register te laden.
Stop je m in een integer register, dan interpreteerd ie dat als int (en dan maakt ie nog niet eens onderscheid tussen signed en unsigned, dat gebeurt bij berekeningen pas). Stop je m in een floating point register dan interpreteerd ie dat als float

MMX in combinatie met amd's 3dnow! is nog leuker. Gewone MMX registers zijn in principe 64 bits integers, maar in berekeningen zijn het meestal 2x 32 bits, 4x 16 bits of 8x 8 bits integers die in 1 berekening allemaal tegelijk uitgerekend worden (vandaar de term SIMD: Single Instruction, Multiple Data). Gebruik je echter 3dnow!, dan worden diezelfde registers geinterpreteerd als 2x 32bits floating point getallen

[CyberSnooP]

0. Installeer een ander OS wat jou windows-bestandssysteem ondersteund
1. Maak een progje wat even heel je werkgeheugen opeist, zodanig dat alle interessante stuff wordt geswapt door Windows.
2. Hit the reset button
3. Start je andere OS, en lees de Virtueel geheugen file op je HD (ik kan me niet voorstellen dat die dusdanig beschermt is dat dat onmogelijk is.

Nadeel: Je kunt niet zien hoe de programma's draaien en het geheugen aanpassen. Wil je echt iets interessants ontdekken is dat wel een erg grote pre.

Misschien kun je met VMWare (of andere virtuele-machine software) ook nog het e.e.a. bereiken.
_{Nostaligie: Ik heb uren naar een gridje met hexadecimale getallen zitten kijken met PCTools onder Dos 3.21}

[Jelmer]

CyberSnooP schreef op 07 augustus 2002 @ 00:43:

Misschien kun je met VMWare (of andere virtuele-machine software) ook nog het e.e.a. bereiken.

VMWare zal ook lastig worden vrees ik... Denk dat je bijv eens moet kijken naar Numega SoftICE (het enige is dat somige apps hier beveiling voor hebben; 't wordt nl veel gebruikt als serial 'debugger')

[.oisyn]

CyberSnooP schreef op 07 augustus 2002 @ 00:43:

_{Nostaligie: Ik heb uren naar een gridje met hexadecimale getallen zitten kijken met PCTools onder Dos 3.21}

PC-Tools heerste!

[CyberSnooP]

.oisyn schreef op 07 augustus 2002 @ 00:52:
PC-Tools heerste!

Ben er alleen nog niet uit waarom de hele wereld vond dat je een schijf kon "format"-en terwijl PC-Tools het "initialize"-en noem[t|de].

_{ja, dit is een kick, ik ben benieuwd of er andere methodeen zijn}

[MPAnnihilator]

ik zie niet in door gewoon geheugen van begin tot einde uit lezen dat je problemen krijgt met read rechten op bepaalde processen of zo, in der tijd in school bij mijn lessen c, hebben we dat toen geschreven en dat gaf in win95 toch geen probs...

Maar ja, onder nt of zo weet ik niet of dat nu fundamenteel anders zou liggen... ' t is ook al 6 jaar geleden dat ik c gebruikte maw weet er bijna geen reet meer van...

[.oisyn]

-GF-Annihilator: Waarschijnlijk programmeerde jullie met Turbo C, en maakte jullie dus gewoon 16 bits DOS apps. Ja dan kun je gewoon de hele onderste 640k mem uitlezen zonder problemen (behalve dan dat het waarschijnlijk niet eens de onderste 640k was... dat dacht je alleen maar omdat je in virtual x86 mode draaide)

Die 640k is ook gewoon een afgeschermt stukje geheugen waar je niet buiten kan (kun je sowieso niet buiten met normale segment:offset pairs)

[reddog33hummer]

In NT of 2000 moet je eerst system worden (kan je alleen als je administrator bent)
met die token kan je dan met de debug reader het geheugen leeghalen.
Het leuke is als je gewoon met een pointer gaat klooien dat je virtueel geheugen gaat lezen (geheugenspace die voor het programma is weggesteld) i.p.v. het werkelijke geheugen.

[Verwijderd]

Misschien een stomme vraag, maar wat wil je met dat geheugen doen? Echt veel kan je er toch niet mee, tenzij je weet hoe de kernel geheugen alloceert (pre/post data van userspace geheugen), welk programma welk geheugen gebruikt en wat het doel van die geheugen is (en dus hoe je het moet interpreteren)....

Want geheugen is vast heel interessant, maar ik zie persoonlijk het nu van oninterpreteerbare raw bytes niet zo in. Of ben ik nou zo vreemd?

Overigens, onder unix kun je ook zo'n soort appje maken, maar dan moet je de SIGSEGV afvangen met signal(). Zal onder winNT&co ook wel een afvangmethode voor zijn. (bv. in VB, ik herinner me iets van 'on return continue next'?)

[Korben]

Verwijderd schreef op 08 augustus 2002 @ 09:02:
Overigens, onder unix kun je ook zo'n soort appje maken, maar dan moet je de SIGSEGV afvangen met signal(). Zal onder winNT&co ook wel een afvangmethode voor zijn. (bv. in VB, ik herinner me iets van 'on return continue next'?)

SIGSEGV kun je met VB niet afvangen, met On Error Continue Next (dat was het namelijk) vang je excepties af.

[Sponge]

.oisyn schreef op 07 augustus 2002 @ 00:37:
[...]

MMX in combinatie met amd's 3dnow! is nog leuker. Gewone MMX registers zijn in principe 64 bits integers, maar in berekeningen zijn het meestal 2x 32 bits, 4x 16 bits of 8x 8 bits integers die in 1 berekening allemaal tegelijk uitgerekend worden (vandaar de term SIMD: Single Instruction, Multiple Data). Gebruik je echter 3dnow!, dan worden diezelfde registers geinterpreteerd als 2x 32bits floating point getallen

offtopic:
MMX registers zitten toch 'boven' de normale registers (eax,edx, etc)? Dan zou het logisch zijn dat MMX in theorie een 32bit register voor een soort "high word" en een 32bit register voor een soort "low word"? Toch maar weer eens tijd dat ik met ASM ga klooien, nog niet eerder met MMX/3D Now! gewerkt..

[odysseus]

Je zou er onder GNU/Linux vrij eenvoudig achter kunnen komen door de inhoud van /dev/mem te bekijken. Veel zegt het niet, aangezien het helemaal niet gezegd is dat een aaneengesloten stuk geheugen ook van één programma afkomstig is. Geheugen dat met malloc() en consorten wordt aangevraagd, wordt door de kernel in pages van 4k toegewezen. Die kunnen dus best over de hele memory-module verspreid liggen. Interessanter wordt het als je al het geheugen dat door een bepaald programma gebruikt wordt gaat bekijken. Dat krijg je naar ik verwacht alleen voor elkaar door ofwel verschrikkelijk in de kernel te knoeien (zodat die voor jouw de geheugenadressen die een programma vraagt gaat bijhouden en dat naar userspace stuurt) of door het programma onder een debugger of soortgelijk programma te laten draaien. Als je het echt stapje voor stapje wilt bekijken dan is iets als valgrind misschien een leuk programma.

_{Bovenstaande vereist dus wel het gebruik van GNU/Linux, hoe je iets dergelijks onder Windows moet regelen weet ik niet.}

[.oisyn]

41.6C.6D.61.72 schreef op 08 augustus 2002 @ 16:17:
[...]

offtopic:
MMX registers zitten toch 'boven' de normale registers (eax,edx, etc)? Dan zou het logisch zijn dat MMX in theorie een 32bit register voor een soort "high word" en een 32bit register voor een soort "low word"? Toch maar weer eens tijd dat ik met ASM ga klooien, nog niet eerder met MMX/3D Now! gewerkt..

nee, mmx registers worden behandeld als 8 hele aparte registers, en hebben dan ook niets met de normale registers (eax, ebx, ...) van doen

Eigenlijk zijn ze trouwens niet eens apart, ze maken gebruik van de 8 floatingpoint registers (80 bits per stuk), vandaar dat je floating point code en mmx/3dnow! code niet (zomaar) kunt combineren

[.oisyn]

Xenophage schreef op 08 augustus 2002 @ 16:08:
[...]

SIGSEGV kun je met VB niet afvangen, met On Error Continue Next (dat was het namelijk) vang je excepties af.

het lijkt me ook een beetje moeilijk om met VB een segmentation fault, page fault of GPF te genereren aangezien je geen pointers hebt in VB, dus je kunt ook niet zomaar random geheugenadressen uitlezen. (Of je moet gebruik maken van een in een andere taal geschreven library, maar dan speel je vals )

[Gerco]

Ach, met CopyMemory() (RtlMoveMemory) en ObjPtr of VarPtr kun je leuke dingen doen, maar zoals je zegt, dat is valsspelen...

[NaliXL]

Heel errug hartelijk bedankt voor al die replies. Heb ik weer wat geleerd. Wat ik nou wel weet is dat het niet zomaar iets is zoals bijvoorbeeld het uitlezen van een file op een harddisk. Ik zit overigens te denken : kon Windows NT niet geheugendumps maken?

Aan degenen die echt willen weten waar dit voor is : Ik wilde dit eerst niet zeggen, omdat ik nogal een fantast ben, en mijn projecten eigenlijk nooit afkomen , en zeker dit soort niet . Maar in ieder geval, ik had het volgende idee : (laaaang stuk text )

Een poosje terug kwam ik in het nieuws op www.gamedev.net een verwijzing naar dit artikel tegen. Het opmerkelijke hieraan vond ik dat er gezegd werd dat er gebruik werd gemaakt van een simulatie van een menselijk brein, dat het geheel werkte, en dat de makers niet wisten hoe dat kon. Van wat ik uit dit artikel weet, kan ik dus conluderen dat hier echt een vorm van intelligentie is ontstaan. Dus ik dacht : wat zou er gebeuren als ik ook zo'n model van een menselijk brein maak, de basisfunctionaliteit dan, want ik ben geen expert op dat gebied. Het lijkt me logisch dat een brein op gang gebracht word door input. Neem een mens : Stel nou dat een mens met een leeg brein geboren word. Op het moment dat 'ie geboren is gaan z'n ogen dingen waarnemen. Dit brengt een reeks reacties (veranderingen in hersencellen) op gang, waardoor bijvoorbeeld armbewegingen ontstaan. Die armbewegingen worden dan weer via oog en zenuwen naar de hersenen gestuurd. Wat er kennelijk gebeurt is is dat de cellen zich zo vormen, dat events die tegelijkertijd plaatsvinden naar elkaar groeien ofzo, en op die manier onstaat er waarschijnlijk controle en intelligentie (ja idd, mijn kennis is zeer oppervlakkig). Tot zover mijn stukje theorie, nou mijn programma. Stel, ik heb zo'n brein-sim geprogrammeerd. Dan heb ik dus input nodig. Dus ik dacht : wat kan ik nou beter als input geven dan allerlei soorten data op een computer. En dan met name het werkgeheugen, aangezien dat constant in beweging is. Als output zou dan wijziging van het geheugen mogelijk moeten zijn. Het leek mij leuk om zoiets te proberen op een testPC o.i.d.

Tot zover mijn fantasiën. Nou snappen jullie dus waarvoor ik dat wou weten. Bovendien lijkt het me sowieso zoals ik zei wel interessant om eens te kijken wat er allemaal in je geheugen te klooien valt

[Macros]

Dat gaat niet werken. Heel groot gedeelte van het brein is al 'geprogrammeerd' voordat het kind geboren wordt. Anders zou het al helemaal niks kunnen interpreteren om te leren. Dus zou jij je brein ook al voor een groot gedeelte moeten voorprogrammeren zodat het kan leren, en dat is juist het probleem

[.oisyn]

Als je het brein wilt simuleren moet je je gaan verdiepen in neurale netwerken. En alleen invoer van random data heb je niets Een neuraal netwerk 'leert' door input om te zetten in output en daarbij signalen krijgt of die output goed of fout is

op www.flipcode.com stond een keer een artikeltje over iemand die een neuraal netwerk had gebruikt voor de pathfinding van z'n quake2 bot. De input bestond uit 8 ingangen, waarin de afstand tot de muren werd aangegeven (2 verticaal, 2 horizontaal en 4 diagonaal). Als ie tegen muren aan liep of in lava of slijm viel dan was dat fout, en als ie powerups oppakte dan was dat goed. Na m lang in de wereld te hebben laten lopen kon ie ook gewoon op zichzelf door de hele map lopen op zoek naar wapens en powerups, zonder dat ie daarbij van riggeltjes afviel enzo. Erg mooi gedaan

[Sponge]

Een kind heeft weliswaar wel al instincten om te overleven, maar het kind leert natuurlijk ook door de "prikkels" vande omgeving.

Als je VB6 code wilt zien van face recognition bijvoorbeeld, dan zou je deze site kunnen bekijken, due toch wel interessant is, als je niet in VB6 bekend bent:
http://www.fuzzgun.btinternet.co.uk/

Als je een AI only site wilt zien, die ook zeer interessant is, kun je naar:
http://www.generation5.org/

gaan

NaliXL: Je hebt zeker nooit het spel/boek gezien "I have no mouth and I must scream?", aanrader als je met zelflerende dingen bezig wilt