Oke, tijd om een imgsec tool te schrijven!

Een tool die enkel de gewilde pixel-informtie kopieert naar een apart bestand.
Dan kan je ook geen last meer hebben van dit soort datalekken...

Het probleem is dat er bij het wegschrijven van het bestand na bewerken geen nieuw bestand gemaakt wordt maar het bestaande bestand wordt "overschreven" met de nieuwe inhoud. Echter men vergeet aan het eind van die schrijf actie een "truncate" systemcall te doen waardoor de size van het bestand ook echt gezet wordt op de hoeveelheid die er nu in geschreven is. Dit moet standaard gebeuren bij ieder programma wat een file "overschrijft" met nieuwe inhoud (geen los record maar een compleet nieuwe file), en wat degene die dit programma gemaakt heeft kennelijk niet gedaan heeft. Of misschien zit het probleem wel in een of andere library.

Ben soms paranoïde als ik een screenshot maak voor documentatie of iets dergelijks waar een username/password veld instaat ter verduidelijking van het een of ander. Wat ik dan doe als ik het weg knip of blur nogmaals van dat bestand en screenshot maken en die doorsturen of in het document zetten. vervolgens smijt ik die andere afbeeldingen weg (indien opgeslagen)

Maar goed dat blijkt dus maar weer dat dit terug te herleiden is. Zelf gebruik ik Greenshot.

Daarom SNAGIT, of eventuee ShareX

Geld dit ook voor de combinatie, "Shift / Windowsknop / S" ?

Wat ook werkt: opslaan in nieuw bestand ipv opslaan in hetzelfde bestand. De oude weggooien en alleen verder met het nieuwe bestand.
Of je screenshot editten, en dan pas opslaan. De data die je weggehaald hebt is dan nooit opgeslagen en kan dus ook niet teruggehaald worden.

weer een lek in Windows 10 11..?.waarom moeste we overstappen naar win 11.? het zou volgens Microsoft veel en veel veiliger
zijn dat win 11?...onze oudelaptop s konden we weg gooien .wat een milieu verspilling.......

Het is niet echt een lek, maar vooral onkunde van de gebruiker.

/Facebook aan
Nee! er is een mogelijk lek indien er bij een windows applicatie gebruik wort gemaakt van een bepaald fileformaat i.c.m een specifieke functie. Nee, nee en nee. Windows 10 wordt nog volledig ondersteund.
/facebook uit

Slordig natuurlijk. Ik zie hier andere tools genoemd worden, maar wie zegt dat deze dan wel goed hun werk doen? of geloof je in de wij van WC eend....

Welnee, het is onkunde van de programmeur! Die wist even niet dat als je een file voor write opent zonder truncate, de oude inhoud blijft staan als je nieuwe inhoud korter is.
Dat is niet iets waar de gebruiker zich mee bezig hoeft te houden.

"vergeten" :-)

Mensen die met operationele security bezig zijn en hier om geven, weten al langer dat je na een obfuscatie steeds opnieuw een screenshot/afdruk moet maken. Deze 2de kan dan nooit de niet geobfusceerde informatie bevatten.

Veronderstel je dit of weet je dit?

Mij lijkt dit heel onwaarschijnlijk. Als je de nieuwe PNG-gegevens naar het begin van het bestand schrijft overschrijf je daarmee een deel van de weggesneden data die nou juist hersteld bleken te kunnen worden en dus helemaal niet overschreven kunnen zijn. Ook is een PNG-bestand gecomprimeerd, en decompressie gaat alleen goed als de voorgaande data klopt en goed gedecomprimeerd is. Als je opeens van een afgeronde afbeelding (het deel dat overschreven is door de gecropte afbeelding) overstapt op de originele PNG dan stap je ergens middenin een stroom te decomprimeren data waarvan het voorgaande niet klopt. Dan is het uitermate onwaarschijnlijk dat dat decomprimeren lukt.

Waarschijnlijker lijkt me dat de crop-informatie op de een of andere manier als metadata aan de afbeelding wordt toegevoegd zonder dat de pixel-data wordt veranderd. Als het zo gedaan is kan door simpelweg die crop-informatie weer te verwijderen de volledige afbeelding hersteld worden.

Exif (een metadata-formaat dat aan allerlei afbeeldingsformaten kan worden toegevoegd) kent de tag DefaultUserCrop. Als die (0,0) tot (1,1) aangeeft (de default) wordt de hele afbeelding geselecteerd, met waarden tussen 0 en 1 kan een deel worden geselecteerd. Ik weet niet of dat is wat hier gebruikt is, maar wat mij waarschijnlijker lijkt lijkt inderdaad te kunnen.

Als ik het goed begrijp is dit issue min of meer het gevolg van de moderne windows file API. https://twitter.com/sjmurdoch/status/1638623990817103888?s=46&t=_jYL8DdGZRY359hkaqDU_A

Dank u, samples en voorbeeldcode kunnen een bron van ernstige codeerfouten zijn. Vaker gezien.

Het is onkunde dat de gebruiker voor overschrijven kiest, en niet voor opslaan als nieuw bestand en de oude weggooien. En zelfs dan - weggegooide bestanden zijn vaak ook niet eens echt weg. Met speciale recovery software is "weggegooide data" vaak nog wel terug te halen - dat is gewoon hoe veel computersystemen werken.

Ik weet dit, want ik heb de bron van dit topic gelezen. Daar staat duidelijk in wat er fout ging (het bovenstaande).

Ik lees in de verwijzing van Anoniem 06:55 dat ik ongelijk had. De verwijzing als klikbare URL:
https://twitter.com/sjmurdoch/status/1638623990817103888?s=46&t=_jYL8DdGZRY359hkaqDU_A

@Anoniem 06:55: dank voor de verwijzing, maar ook: sla nou niet over er even een klikbare hyperlink van te maken. Het is echt maar een kleine moeite en de essentie van het world wide web is dat je op hyperlinks kan klikken, dat is het verschil tussen een web en een verzameling losse pagina's.

Het is nooit de onkunde van een gebruiker! Het ligt altijd aan wat het OS biedt