Steven Murdoch on Twitter: “However, the new “more secure” Universal Windows Platform (UWP) sandboxes the file picker in a separate process, allowing neat features like capability-based access control. It returns a file handle which, if the selected file exists, will not overwrite the existing content! 3/9”
Posted by jpluimers on 2026/04/07
Windows had its own aCropalypse in the Snipping tool, but other UWP based applications are vulnerable of that too because of this:
[Wayback/Archive] Steven Murdoch on Twitter: “However, the new “more secure” Universal Windows Platform (UWP) sandboxes the file picker in a separate process, allowing neat features like capability-based access control. It returns a file handle which, if the selected file exists, will not overwrite the existing content! 3/9”
It is part of this interesting [Wayback/Archive] Thread by @sjmurdoch on Thread Reader App with these two parts just after the above Tweet:
The old Win32 API for saving a file was (roughly) to show a file picker, get the filename the user selected, and then open the file. To open a file, the programmer must specify whether to overwrite the file or not, and example code usually does overwrite the file.
However, the new “more secure” Universal Windows Platform (UWP) sandboxes the file picker in a separate process, allowing neat features like capability-based access control. It returns a file handle which, if the selected file exists, will not overwrite the existing content!
The tread continued supporting this statement, that in the new situation you need to manually truncated the file, and referenced these links:
- [Wayback/Archive] C# – How can I overwrite a file in UWP? – Stack Overflow (thanks [Wayback/Archive] huangbiubiu for asking) where a few answers supply solutions for truncating an existing file before writing content to it.
- [Wayback/Archive]
FileSavePickerClass (Windows.Storage.Pickers) – Windows UWP applications | Microsoft Learn containing an example that underneath does truncating but only because it is writingTextdata:
…
StorageFile file = await savePicker.PickSaveFileAsync(); if (file != null) { // Prevent updates to the remote version of the file until we finish making changes and call CompleteUpdatesAsync. CachedFileManager.DeferUpdates(file); // write to file await FileIO.WriteTextAsync(file, file.Name);…
Writing Lines does the same, but writing
BytesorBufferwill *not* truncate the file despite none of these documentation links mentioning or explaining this:- [Wayback/Archive] Create, write, and read a file – UWP applications | Microsoft Learn
- [Wayback/Archive]
FileIO.WriteBufferAsync(IStorageFile, IBuffer)Method (Windows.Storage) – Windows UWP applications | Microsoft Learn - [Wayback/Archive]
FileIO.WriteBytesAsync(IStorageFile, Byte[])Method (Windows.Storage) – Windows UWP applications | Microsoft Learn - [Wayback/Archive]
FileIO.WriteLinesAsyncMethod (Windows.Storage) – Windows UWP applications | Microsoft Learn - [Wayback/Archive]
FileIO.WriteTextAsyncMethod (Windows.Storage) – Windows UWP applications | Microsoft Learn
The only way to find out is to look at the underlying C# source code for the underlying private methods that are ultimately called:
WriteTextTaskAsyncandWriteBytesTaskAsyncin the Uno source code [Wayback/Archive] uno/FileIO.cs at master · unoplatform/uno (since UWP source code is not on GitHub but Uno very closely follows what UWP does).Not everyone knows that the historic reason of why text and binary behave differently so it is important for APIs to protect users from accidentally doing the wrong thing (if you are curious, this is why: historically, text data is accessed sequentially, and binary data often is accessed randomly).
- [Wayback/Archive] Simon Aarons on Twitter: “Introducing acropalypse: a serious privacy vulnerability in the Google Pixel’s inbuilt screenshot editing tool, Markup, enabling partial recovery of the original, unedited image data of a cropped and/or redacted screenshot. Huge thanks to @David3141593 for his help throughout!”
A three-panel diagram.
The first panel is titled “Discord message” and depicts a Discord message sent by SimonTime to Retr0id, with an attached cropped photo of a credit card, its number redacted by black pen. The message says “hey check out the new card I got”, with Retr0id replying “sick!”.
The second panel is titled “Downloaded image” and depicts the image downloaded from Discord.
The third panel is titled “Recovered image” and depicts a fake bank website. The top 20% of the image is corrupted, but the remainder of the image – including a photo of the credit card with its number visible – is fully recovered.
This in itself is part of the [Wayback/Archive] Thread by @ItsSimonTime on Thread Reader App which in turn references
It also taught me that
https://twitter.com/i/web/status/1636942122325778433andhttps://twitter.com/ItsSimonTime/status/1636942122325778433are equivalent. - [Wayback/Archive] David Buchanan on Twitter: “holy FUCK. Windows Snipping Tool is vulnerable to Acropalypse too. An entirely unrelated codebase. The same exploit script works with minor changes (the pixel format is RGBA not RGB) Tested myself on Windows 11”
[Wayback/Archive] Chris Blume on Twitter: “@ItsSimonTime @David3141593 I’ve got a fun one for you all to look at. I opened a 198 byte PNG with Microsoft’s Snipping Tool, chose “Save As” to overwrite a different PNG file (no editing), and saves a 4,762 byte file with all that extra after the PNG IEND chunk. Sounds similar :D”
and had these images:
and my question [Wayback/Archive] Jeroen Wiert Pluimers @wiert@mastodon.social on Twitter: “@sjmurdoch Are you sure, as a quick look at (WriteBytesTaskAsync) (WriteTextTaskAsync) reveals the latter truncates but the former doesn’t. WriteText*/WriteLines* calls the latter. WriteBuffer*/WriteBytes* the former. Need to test this.”.
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment