Apple verklaart waarom verwijderde foto's weer terugkwamen op iPhones
Apple heeft een verklaring gegeven waarom verwijderde foto's op iPhones weer terugkwamen in de fotobibliotheek van gebruikers. Recentelijk bracht Apple iOS 17.5 uit. Na de installatie lieten verschillende gebruikers weten dat foto's die ze lange tijd geleden hadden verwijderd weer te zien waren. Daardoor dachten sommige mensen dat Apple foto's in iCloud, die gebruikers hadden verwijderd, eigenlijk niet verwijdert.
In een verklaring tegenover 9to5Mac stelt Apple dat het niets met iCloud te maken heeft, maar een 'corrupt database entry' op de iPhone zelf. Het gaat om foto's die niet volledig van het bestandssysteem waren verwijderd en niet gesynchroniseerd waren met iCloud Photos. Met iOS 17.5 werden deze foto's weer gevonden en aan de fotobibliotheek toegevoegd. De uitleg wordt in een analyse door onderzoekers van securitybedrijf Synacktiv bevestigd.
De onderzoekers stellen dat iOS 17.5 een functie introduceert die het filesystem scant op foto's die aan de fotobibliotheek kunnen worden toegevoegd. Daarbij werden ook foto's gevonden die gebruikers eerder hadden verwijderd, maar nog op het filesysteem stonden. Waarom de foto's op het bestandssysteem achterbleven kunnen de onderzoekers niet zeggen. Op Reddit suggereert iemand dat het gaat om foto's die alleen in de Photos-app door gebruikers waren verwijderd, maar niet in de Files-app. Met iOS 17.5.1 is het scannen van het filesystem verwijderd. De toegevoegde foto's worden door de update niet verwijderd. Gebruikers moeten dit handmatig doen.
Sommige IDE's hebben hier ook een handje van: pas je iets aan buiten de IDE om, weigert die de verandering op te pakken.
Heb nou niet het idee dat wanneer je een stuk aangevreten fruit koopt, je ergens iets over te zeggen hebt. Je mag het gebruiken zolang de maker dat goed vindt. En de data? Ohja... die gebruiker moet er ook nog wat aan hebben, anders geeft-ie het niet meer...
Wat een paranoia.
En wat een bullshit, die 'negen van de tien keer' .
Waarom verzin je die leugens ?
Laat me 's lachen - kom maar met je 9 voorbeelden die een 'delete vlag' zetten.
Ik denk dat je zelf geen telefoons gebruikt - of gewoon niet nadenkt bij wat je kunt zien.
Wat zou je merken in jouw theorie - dat er geen ruimte vrijkomt als je foto's en video's weggooit.
Doen mensen dat - ja natuurlijk. Als de telefoon vol zit en je moet ruimte vrijmaken is het weggooien (van de telefoon) van een zwik oude foto's en video's de manier .
Als je wat meer van IT zou snappen , begrijp je precies hoe de omschreven bug kan gebeuren.
(*) - delete als in : filesystem laat niks meer zien, vrije diskspace is groter geworden.
Een foto opgeslagen als .txt zal niet getoond worden maar door een recover functie wel omdat deze de structuur van een (b.v. JPG) bestand herkend.
@ Vandaag, 16:13 door Anoniem
Ja, een delete functie heeft in sommige OS alleen maar tot gevolg dat er in de inxex (b.v. File allocation Table) alleen een marker gezet wordt "ik ben er niet meer" maar de pointer naar de file en de file zelf zijn er nog steeds en dus ook te recoveren.
Een foto opgeslagen als .txt zal niet getoond worden maar door een recover functie wel omdat deze de structuur van een (b.v. JPG) bestand herkend.
@ Vandaag, 16:13 door Anoniem
Ja, een delete functie heeft in sommige OS alleen maar tot gevolg dat er in de inxex (b.v. File allocation Table) alleen een marker gezet wordt "ik ben er niet meer" maar de pointer naar de file en de file zelf zijn er nog steeds en dus ook te recoveren.
En vrijgegeven voor hergebruik dus te recoveren tot de ruimte voor andere doeleinden wordt ingezet (wat met de groottes van opslagruimte in tegenwoordige devices soms lang kan duren)
Een foto opgeslagen als .txt zal niet getoond worden maar door een recover functie wel omdat deze de structuur van een (b.v. JPG) bestand herkend.
@ Vandaag, 16:13 door Anoniem
Ja, een delete functie heeft in sommige OS alleen maar tot gevolg dat er in de inxex (b.v. File allocation Table) alleen een marker gezet wordt "ik ben er niet meer" maar de pointer naar de file en de file zelf zijn er nog steeds en dus ook te recoveren.
Ik zette niet voor niks mijn voetnoot omtrent (OS) delete.
Echter - hier kon de photo app 'gewoon' de foto (her) ontdekken bij het indexeren van het leesbare filesystem.
De photo app is geen low level data recovery tool . De file was dus op het filesysteem niet weggegooid, de ruimte was niet vrijgegeven, en de photo app bij de FW update had 'm gewoon weer toegevoegd bij het scannen van het filesysteem naar images.
Vandaar dat die security firma de boel kon terugvinden op een telefoon-backup - die bevat "leesbare" files van het filesysteem, het is geen block level dump.
Ik denk dat er niet eens sprake was van een rename naar .txt ofzo, maar doodgewoon (alleen) weggehaald uit de photo-app image db , en die 'verwijder' actie daarin was niet gesynchroniseerd naar het (ook) verwijderen van de image op het filesystem.
Vergelijk het maar met de playlist van AIMP of VLC , en dingen daaruit halen zonder de bijbehorende files ook weg te gooien, en later 'm weer laten zoeken naar playable data.
Een file die voor het filesysteem deleted is , claimt geen ruimte meer, de ruimte kan overschreven worden, kan niet door een reguliere app die gewoon het filesysteem scant gezien worden , en komt niet meer terecht in backups .
Op IOS is het filesystem standaard encrypted - wat het 'off line' recoveren van "deleted" (of niet-deleted) files ook erg veel moeilijker maakt, als het niet lukt om eerst de key te vinden.
Jemig wat een wappie verhaal.
Als je een i.e. "Word bestand" weggooit is het ook niet "weg" het wordt alleen van de index verwijderd en de ruimte kan overschreven worden. Hetzelfde heeft betrekking op foto's. Als het zoals in jouw theorie zou werken dan zou de beschikbare geheugenruimte ook niet vrijkomen.
Jemig wat een wappie verhaal.
Als je een i.e. "Word bestand" weggooit is het ook niet "weg" het wordt alleen van de index verwijderd en de ruimte kan overschreven worden. Hetzelfde heeft betrekking op foto's. Als het zoals in jouw theorie zou werken dan zou de beschikbare geheugenruimte ook niet vrijkomen.
Tenzij er een 2de kopie gemaakt wordt die naast iCloud in een datacentrum terechtkomt. Dan krijg je de ruimte terug terwijl die 2de kopie ergens opgeslagen en uit je handen is.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
