[VC++]Memory uitlezen

[Verwijderd]

Ik vroeg me af of het mogelijk was met pointers geheugen addressen uit te lezen?

ik heb het onderstaande geschreven :

C++:

#include <iostream.h>
 
int main ()
{
  short *p1 = (short *)0xb800;
  cout << *p;
  return 0;
}

Het wordt wel gecompileerd maar bij het uitvoeren er van krijg ik een foutmelding unable to read memory. ik neem aan dat dit door de windows protection wordt afgevangen. Is het uberhaupt mogelijk om geheugen addressen uit te lezen die niet binnen de eigen geschreven applicatie zijn gealloceerd?

[Creepy]

Standaard is dat niet mogelijk nee. b800... hmm, zie ik daar een dos adres voor het benaderen van videogeheugen (of was dat nou a000)? Waarom zou je dat geheugen adres willen uitlezen?

Mocht het om I/O gaan, kijk dan eens naar DriverLinx Port I/O en andere varianten, deze geven directe toegang tot alle I/O poorten.

[Janoz]

afaik kan dat alleen waneer je het procces start als kind van het opvraag proces. Alle andere mogenlijkheden lijken me meer een exploit van 1 of andere bug.

[.oisyn]

Het is mogelijk, met ReadProcessMemory ()
Een physiek geheugen adres uitlezen is niet mogelijk, omdat er met paging wordt gewerkt. Dat wil dus zeggen dat adres 0x12345678 in het ene proces niet per se naar hetzelfde stukje fysieke geheugen wijst als 0x12345678 in het andere proces.

Wat probeer je trouwens te doen? 0xb800 is in 16 bits realmode het videosegment waar de consolechars in staan. Als je dat probeert uit te lezen dan kun je beter de win32 API functies gebruiken, ReadConsoleOutput () e.d.

Creepy schreef op 19 August 2003 @ 14:11:
Standaard is dat niet mogelijk nee. b800... hmm, zie ik daar een dos adres voor het benaderen van videogeheugen (of was dat nou a000)? Waarom zou je dat geheugen adres willen uitlezen?

0xa000 was de grafische buffer

[ Voor 25% gewijzigd door .oisyn op 19-08-2003 14:14 ]

[Soultaker]

offtopic:
0xB800 is het begin van de videobuffer in tekstmodus; 0xA000 het begin in grafische modus.

De methode die kurai beschrijft werkt uitstekend, maar (uiteraard) niet in protected mode. Als je de bovenstaande code naar een real mode (DOS) executable compileert, zou het wel gewoon moeten werken (al heb je dan waarschijnlijk later weer problemen met de real-mode emulatie van Windows). Ik weet niet welke versie van Visual C++ je hebt, maar de meer moderne versies ondersteunen geen real mode meer. Ik betwijfel ook hoe compleet de standard library voor real mode is.

Volgens mij draaien drivers onder Windows 9x (van die .vxd files) ook in real mode, dus als je daar naar zou kunnen compileren, kom je misschien al in de buurt, en dan heb je waarschijnlijk ook de Windows API ter beschikking. Ik heb echter geen idee hoe dat precies zit (en wat je nodig hebt om die drivers te compileren).

offtopic:
Het includen van standard library header files met de .h extensie wordt tegenwoordig aangeraden; gebruik dus liever #include <iostream>, desnoods gevolgd door using std.

[ Voor 3% gewijzigd door Soultaker op 19-08-2003 14:17 ]

[Verwijderd]

Ik probeer samen met nog iemand een simpele console applicatie te schrijfen die alle text op het scherm wegschrijft in bestand. En dit dan wel op een vrij windows onafhankelijke manier.

[Soultaker]

Verwijderd schreef op 19 August 2003 @ 14:20:
Ik probeer samen met nog iemand een simpele console applicatie te schrijfen die alle text op het scherm wegschrijft in bestand. En dit dan wel op een vrij windows onafhankelijke manier.

Er is geen standaard voor het werken met een console, behalve enkele simpele dingen als het lezen en schrijven van een regel. Je bent dus altijd platform-afhankelijk bezig (ongeacht op welk platform je werkt), tenzij je gebruik maakt van een bestaande library die de differentiatie naar verschillende platforms voor z'n rekening neemt.

[.oisyn]

Soultaker schreef op 19 August 2003 @ 14:17:
De methode die kurai beschrijft werkt uitstekend, maar (uiteraard) niet in protected mode. Als je de bovenstaande code naar een real mode (DOS) executable compileert, zou het wel gewoon moeten werken (al heb je dan waarschijnlijk later weer problemen met de real-mode emulatie van Windows).

behalve dan dat de realmode pointer naar het adres 0xb8000000 moet zijn. In protected mode gaat het ook wel, zie bijvoorbeeld djgpp (32bits prot.mode onder dos). En dan is het adres het fysieke adres, namelijk 0xb8000 (let op die extra 0)

[hobbit_be]

zit er geen gotoxy in de stdio?

[Verwijderd]

Wat ik wil is een console applicatie die rechtstreeks het video geheuegen uitleest. Wij hebben dit ook met debugger geprobeert. En hiermee kunnen we rechtstreeks schrijfen en lezen wat er zich op dat geheugen address bevindt (0xb800). In debugger hebben we een Hello World progie geschreven 24Byte (ja ja het kan nog echt kleine programma's en die kunnen wij uitvoeren zonder dat deze foutmeldingen binnen windows geeft
Het zelfde willen we ook kunnen binnen C++ Direct toegang tot alle geheugen segmenten van MIJN!!! pc.

als C++ compiler gebruik ik nu VC++ 6.0 (en ik wil geen windows calls gebruiken).

[pistole]

Verwijderd schreef op 19 August 2003 @ 16:08:
Wat ik wil is een console applicatie die rechtstreeks het video geheuegen uitleest. Wij hebben dit ook met debugger geprobeert. En hiermee kunnen we rechtstreeks schrijfen en lezen wat er zich op dat geheugen address bevindt (0xb800). In debugger hebben we een Hello World progie geschreven 24Byte (ja ja het kan nog echt kleine programma's en die kunnen wij uitvoeren zonder dat deze foutmeldingen binnen windows geeft
Het zelfde willen we ook kunnen binnen C++ Direct toegang tot alle geheugen segmenten van MIJN!!! pc.

als C++ compiler gebruik ik nu VC++ 6.0 (en ik wil geen windows calls gebruiken).

Dan kan je denk ik (als je vooral klein wilt blijven) beter in assembly gaan werken?

[Creepy]

Verwijderd schreef op 19 August 2003 @ 16:08:
Wat ik wil is een console applicatie die rechtstreeks het video geheuegen uitleest. Wij hebben dit ook met debugger geprobeert. En hiermee kunnen we rechtstreeks schrijfen en lezen wat er zich op dat geheugen address bevindt (0xb800).

Welke windows versie gebruik je? Want het lijkt me sterk dat dat lukt in windows NT, 2000 of XP. Windows 95, 98 en ME kan ik me nog wel voorstellen ja.

[PrisonerOfPain]

Je kan een pointer toch gewoon naar een adres laten wijzen door hem daar dat adres te laten wijzen (gewoon het sterretje weglaten).

code:

pPointer = 0xb800;
printf ("%s",*pPointer); //met sterretje :)

[Creepy]

PrisonerOfPain schreef op 19 August 2003 @ 16:35:
Je kan een pointer toch gewoon naar een adres laten wijzen door hem daar dat adres te laten wijzen (gewoon het sterretje weglaten).

code:

pPointer = 0xb800;
printf ("%s",*pPointer); //met sterretje :)

Maar dan blijft dus de vraag of Windows je wel toegang totdat stuk geheugen.

[MrBucket]

Hmm... platform-onafhankelijk programmeren is een stuk moeilijker dan je in eerste instantie zou denken... Zoals al eerder aangegeven heb je 2 mogelijkheden:

1) Ga hard-core de fysieke geheugenadressen uitlezen. Probleem hierbij is dat tegenwoordig de console-schermen onder windows niet langer 80x25 characters hoeven te zijn, en dat er meerdere console-schermen tegelijk open kunnen zijn.
Het schrijven naar realmode adres B800:0000 is een DOS-methode, en dus behoorlijk achterhaald. Bovendien vraag ik me af of 't onder een ander OS (Linux?) wel zou werken

2) Creeer meerdere libraries (voor elk platform 1, met OS-specifieke calls), maar met dezelfde interface. Link de rest van je (platform-onafhankelijke) code met de juiste library al naar gelang het platform. Zo verberg je al je platform-specifieke code achter dezelfde interface.

(..Maar zeg nou eens eerlijk: hoeveel moeite is dat 'platform-onafhankelijk' je nou echt waard?)

[curry684]

Creepy schreef op 19 August 2003 @ 16:20:
[...]
Welke windows versie gebruik je? Want het lijkt me sterk dat dat lukt in windows NT, 2000 of XP. Windows 95, 98 en ME kan ik me nog wel voorstellen ja.

Onder 95/98/ME kan het met dan aan de DOS-baselayer inderdaad, en onder een NT-core zal het extreem hard knallen met een Access Violation...

[ Voor 4% gewijzigd door curry684 op 19-08-2003 20:04 ]

[Soultaker]

Anders moet je gewoon een C++ compiler voor DOS (zoals Turbo C++ 3.x) gebruiken. Die is wel op internet te vinden (maar ik mag geen links geven, denk ik) of dus een hele oude versie van Visual C++ (geen idee hoe oud precies).

curr684 schreef:
quick scan door Google lijkt me aan te duiden dat TC2.x vrijgegeven is iig, hier te downloaden

De C++ versie is ook beschikbaar, maar dan wel versie 1.01:
http://community.borland.com/article/0,1410,21751,00.html
Geen idee hoe modern dat is, maar wellicht werkt het wel. Jammer dat ze 3.x niet vrijgeven, dat was echt een goed product voor z'n tijd...

[ Voor 60% gewijzigd door Soultaker op 20-08-2003 00:55 ]

[Verwijderd]

Ben net thuis en heb even snel die TC2.1 compiler gebruikt en die schijnt te werken thx alot zal hier morgen wat meer naar kijken.

En met de vraag tot de debuger met het poeren in het geheugen dit was op windows 2000

[MSalters]

Met "DEBUG.EXE", wat een dos applicatie is, zal het idd wel werken. Het is niet heel moeilijk om dan in de DOS box cq DOS emulator een text buffer te mappen naar 0xb8000. Voor je Windows programma's wordt zo'n text buffer helemaal niet opgezet; Windows programma's moeten Windows calls gebruiken.

PS. Het is dus niet 0xb800, maar b8000 - DOS is niet 100% 16 bits