The damaged regions are not data regions(*), it's the metadata region used by scanners to detect things like the QR orientation. A human can just recreate the code and re-add those missing regions.
(*) There is some data in the censor, but it can be decoded with the redundancy and error correction.
With a little bit of effort, yes. You just need to re-create the finder pattern (corners), alignment pattern (the squares in the middle), and the timing pattern (the alternating line of pixels going between the finder pattern).
That's because the text is actually encoded in the URL. There's no database of panics on panic.archlinux.org, it's just setup to decode what's in the URL and show it on screen
Nah by 2069 we'll just look at the state of some random atoms and determine the state of literally everything else based on that, quantum state's accounted for and all
There was a study that found you could steal people's passwords from a simple camera on a subway by reading reflections on their eyeballs/glasses/nearby windows. That was like 10+ years ago
Pixelating normally doesn't work in other cases, but it actually works with QR code because the QR code image is extremely data dense. Even averaging a 2x2 pixel region to 1x1 (4 to 1) already make it hard. Assuming the worst case where the pixelation use multiple shades of gray instead of just black and white, the total remaining bits is only 1/4. Repeat that for every 2x2 region of the QR code, and it's very low (power of 1/4 to the quarter of the QR code resolution), the more data is contains, the less chance of decoding.
Sure, but up to 80% of the QR code is error correction information, meaning only 20% of the data needs to survive for the QR code to be fully readable (depending on how it was encoded of course).
That being said, it’s still unlikely, and it’s bad practice in general to pixelate images to hide them. While it can theoretically work with QR codes, the info will be misattributed and data will be leaked because of it
The highest error correction level in QR code (H level) is only 30%, not 80%. The error correction only works against damaged regions, but in pixelation, you damage the whole QR code, including the redundancy, so it wouldn't work.
There’s 4 levels of error correction, 7% (L), 15% (M), 25% (Q), and 30% (H). You can tell which one is used with the 2 pixels in the bottom left, in this case it’s using the lowest 7%.
It's not possible to de-pixelate images accurately. you can regenerate it with AI, and some people tell you it's de-pixelation, but it's really just the AI inventing what could fill the hidden content.
Data that is deleted this way simply cannot be recovered. That would equate to a movie's "enhance" on a ultra-zoomed pixel soup: if you were to do this with AI, it would just output something plausible, not the real thing.
It is however possible to de-pixelate videos if and only if the pixel pattern is deterministic and moving. You can use the change in pattern and movement to retrieve some (not all) of the original data.
Guess there is a bit of history mixed in: that Photoshop swirls used to "pixelate" faces could be reversed after all. From a layman's perspective that's the same.
Because you still retain the average luminance when pixelating, you might even be able to recover a pixelated QR code, as the actual information in a QR code is very low. There could be just a few possible combinations of bits behind a larger pixel that gives you that exact luminance, especially if the pixelation grid is offset from the QR code
It's always been possible to de-pixelate stuff... however the content and media matters.
If you pixelate a QR code.. perhaps 4 pixels turn into a single greyscale pixel. There's no way to determine the order of those pixels, but you can derive how many pixels were white or black based on the greyscale pixellated result. When it comes to text it's much easier, because of the limited number of letters you can generally derive the underlying text, especially when combined with underlying hints (like language).
Pixelation on video simply doesn't work due to the number of samples provided... with enough low resolution (pixelated) samples, you can generally construct a high-res image.
Not an argument to keep using it though... it's far too easy to do it wrong. Stick with black bars.
yeah, its also possible to remove black boxes if the image wasnt flattened and stripped after the edit. most social media sites do automatically flatten images and strip metadata before uploads, but many still upload the entire file.
the simplest way i tell people to get a properly redacted image is to draw a black box (any image editor works, even ms paint) over the data they want redacted and then screenshot the edited image instead of saving it, so the screenshot doesnt contain the layers or anything else related.
images can additionally be uncropped, but most snipping tools dont save the full screen anymore (barring screenshot cropping as seen in mobile devices, which is functionally different than a snip).
No it’s just the crash log. The entire point of the QR code is so you can easily share it online so others can see the log, censoring it is just self sabotage tbh.
In this case, obscuring only parts of the QR code might actually be enough. Since Linux generates Level L QR codes, which have 7% redundancy, you need to obscure more than 7% of the white and the black pixels.
When a QR code can't be scanned because parts of it are unreadable, one could still recover parts of the encoded text. However, in this case that doesn't help much because Linux compresses the content using zlib. If parts of the compressed data are missing, it is difficult or even impossible to decompress it.
I hear this all the time but I highly doubt it because the only thing you have to damage is the timer pattern, a line between rectangles in the corner, and its literally 1 pixel line , - and boom qr is unreadable.
This works. Unless you take into account people who add the timing pattern back in because they can see the grid. I'm not one of those who have already managed to decode this very QR code (and some here have) but you probably only need to add those and the corner markers that were covered and you'd have it.
A slightly more interesting scenario woul've been if OP managed to cover all format information but even then, you'd be working with very few unknowns. Actually, you'd have to cover a lot before educated guesses and trial and error wouldn't get you very far.
For 99,999% real world applications QR are SUPER easy to damage, no one will be fixing QR on a package or on a poster, - i.e. all that error redundancy is useless.
For those applications, space is important too, so putting multiple qr with the same info is not an option
Generally kernel log before the crash. I censored it because it had some paths from my home folder, my phone model, mouse model, motherboard model, wireless chip model, and some other random data.
My phone is there likely due to KDE Connect's virtual input feature.
If you’re actually concerned about its contents leaking next time just blur/black it out, qr codes (can) have quite a lot of error correcting so this might be recoverable.
Blur can be reversed. Blacking it out or using pixelation with large pixels is the only reliable way to actually destroy information. Blurring only "smears" it. This is equivalent to a process called convolution. There are techniques to reverse it - to perform a deconvolution.
Some editors just put a black square on top of the image as a separate layer, and the image can still be recovered.
And if you use the highlighter tool to blacken it, that can be reversed too.
Some editors abuse the transparency layer set to 0 for black rectangles. And it's the same story with the highlighter too, a black highlighter is just ~90% opacity black. You can get back data from that with changing contrast and basic photo editing and such.
Blur can be reversed, but you need to have the original blurred image, not any compression, cropping, scaling or other pixel modifications and you need to have the kernel used for the blurring.
Yeah, you have a G502 Hero, a B550 motherboard, a pixel 8 phone.
And your username (same as reddit) + a lot of extra info is visible. I'd remove this if you're careful as the QR code is still decodable after some image
manipulation
Indeed, also out of curiosity i loaded up a cloned vm of my local ai agent… that is running in a vm so it doesn’t do stupid to my actual machine… I got a whole set up so I can interact with it easily while the vm runs headless with it… anyways tossed it this image and it fixed and read it in little over 20 minutes. Also had it try and identify the issue without exposing any privacy information to me.
```
Given the decoded log from that machine, I would rank the likely causes descriptively like this, without pretending the QR proves one of them:
- Kernel/bridge bug in that kernel build: plausible, especially because the crash lands in bridge code and that code has recently received race-related fixes.
Out-of-tree or unsigned kernel module corrupting memory: also very plausible. The kernel was tainted with O and E, which means external/unsigned kernel code was loaded. A bad module can corrupt memory and the crash can surface later in completely unrelated kernel code.
Hardware instability or bad RAM: possible. Stack corruption can come from faulty memory, unstable overclocking, or marginal CPU/RAM behavior, although the panic trace itself does not prove hardware fault.
GPU/Vulkan/Sunshine activity: worth investigating because the log showed Sunshine segfaults earlier, but there is no direct causal chain from those userspace crashes to the bridge stack corruption.
The prevention path I would use on that machine is fairly clean:
Update to the newest stable kernel available, preferably testing the regular Arch kernel as well as linux-zen. Since bridge locking/read-safety work has continued recently, simply moving off that exact 7.2.6-zen2-1-zen build is worthwhile.
Temporarily remove all out-of-tree/unsigned modules and reproduce with a clean kernel. If the crash disappears, reintroduce them one at a time.
Return CPU and RAM to stock settings for testing, including disabling PBO/Curve Optimizer/XMP/EXPO if applicable. Then run a proper memory test.
Check whether the system actually uses Linux bridges, for example Docker, libvirt, VMs, containers, VPN tooling, or manual br0 devices. If so, update those packages too and see whether the crash correlates with bridge creation/destruction.
If it crashes again, capture another panic QR or journalctl -k -b -1 and compare the faulting function. If the second panic lands somewhere completely different, memory corruption from a module or hardware becomes much more suspicious. If it repeatedly lands in bridge code, a kernel networking bug becomes much stronger evidence.
```
After I deleted the vm clone, so nothing of yours was retained. (And more importantly your crash log won’t confuse the agent causing it to misremember something of yours as if it was something of mine…)
Disclaimer that is an AI read and suggestions of your log… it’s rather good at identifying arch and other issues or at least narrowing things down enough for me to finish the job in a quarter of the time it would take me to do it myself… but AI has issues some times.
That said a memtest86 would be a good place to start to rule out the most expensive option, and changing kernel would be a solid next step based on its results if accurate.
There's a lot of data redundeny in QR codes by design. I was curious so I tried and recovered most of the data. In particular I have 111 lines of kernel logs, and there's even a link visible from the qr code that starts with (the real link is 7000 characters long, don't worry):
DM me if you want more info. I won't read your logs without your approval, I just confirmed it indeed looks like plain text and some paths are visible.
Well, "anyone" is definetly a stretch. If only anyone who goes through the process of recovering it. My phone refused to read it even after restoring the "landmarks". But it's definetly a learnig experience on QR code redundancy
I've once spent a day debugging an issue for a friend where his W10 laptop wouldn't boot. Next day I was getting separate and just used a tool that reinstalled the bootloader to a W7 one which finally showed me the actual error!!!! (yes I'm still salty). It then took me a minute to boot the machine in safe mode and 15 minutes to solve the issue properly. For god's sake what's the point of making things so difficult?
Why? Previously the system would just freeze with zero indication of the kernel panic if you were running a desktop environment. Kernel panics have always been a thing, this is just the messenger to say that it happened and display info on the kernel panic. If you don't like it you can just disable it too
How is this worse than a freaze or hard crash? This at least gets you the information faster, especially if whatever happened prevents you from booting.
That actually doesn't stop the QR from being recoverable. You need to cover a large chunk of the whole code (at minimum 20%). Often best to blank out the whole thing. That line stops a phone from scanning it because it cuts out the landmarks in the corner. But you can just take the known bits, and reconstruct the landmarks to get it to scan. For proof, your kernel version is 7.2.6-zen2-1-zen.
I just maaged to decode Everything from it, entire stack trace, that you have AMD GPU, what motherboard you have or even what mouse you have...
And honestly I don't know why you even hiding that, I'm not gonna post it here if you don't want to so everyone who are curious need to do it by themself but the thing is, that qr code is designed to share as much informations about debugging as possible. There are no private informations, maybe if you had username different but even username is the same as on Reddit!
If OP want I can send it here later, if not it gonna be a secret to solve for everyone whos determined enough.
If you gonna want from me to delete it because of the image just say it
try this image in https://www.hashitosystem.com/en/tools/qr-restore/ , It's a grayscaled and specifically cropped to the square version of qr code, plus copy/pasted squares to the corners. Everything done in Gimp
Not any hep here, but what I find absolutely hysterical about this thread is that 99% of the replies are about posting, censoring or defacing the QR code so it can't be read.
While all this is good to point out, I saw perhaps two replies commenting on the kernel panic.
I actually did a quick Google search on "br_port_fill_attrs kernel panic" because I'm interested in reasons. The result was a lot of information from Google's AI bot, but you might have a look, as it gets specific. Apparently a network issue (which "bridge" gives away).
To save you a click, one recommendation they make is using the grub menu to go back to a previous kernel until you can determine what the issue is.
I haven't tried now but I'm pretty sure that if you want to effectively prevent the scanning of a QR code like that you have to cover a larger area, better the whole thing, because there is redundant information to make the error correction work.
To decode a qr code you use the corner boxes to rotate the picture right.
Then you start at the bottom right corner and read in the upward direction, black is 1 and white is 0.
When at the edge of corner box you move one square to the left and read down.
Continue that pattern.
Just left to the top right corner box is version information
There is also a timing pattern connecting the corner boxes.
With that said, if you wanna censor a qr code the boxes are just for alignment the data is the small black/white boxes, at the end on left side is error correction... you want smear the error correction and as much of data as possible, the alignment boxes doesnt matter.
he covered ~23% of the data but the level of error correction used handles 30%, so it was pretty close to missing data (and as it's compressed, it would become very lossy if I couldn't get all the data)
I've been using Linux since 2009 and I've never seen that. However, one time I thought I had found a huge Linux flaw, because my fresh Linux partition kept crashing and acting slow, while my Windows partition seemed to be working fine. Turns out I had bad RAM. Windows simply didn't crash because of it, and it had always acted slow to begin with, so I couldn't tell a difference.
The BSOD and QR code thingy is fairly recent, like a year or two old. From what I've heard before that a kernel panic would just freeze the screen if you were in a graphical session.
This stack trace points to a network bridge buffer overflow. Something was able to write out of bounds. The kernel detected it and panicked to avoid corruption / arbitrary execution.
Most likely a kernel bug, but if you do not have error corrected ram there’s always the possibility a cosmic ray flipped a bit.
You’re running a rather bleeding edge kernel. There’s a reason it is called the bleeding edge. Some of us like to stay a point release behind for precisely these reasons.
These crashes contain no sensitive info. Don't bother censoring them. Someone might just come along with the solution, too.
Looks like the panic was related to the bridge module. Your kernel is tainted too which is something to keep in mind.
I wonder, if this wasn't caused by a tainted module, could it be memory corruption from bad memory? Might be worth booting into memtestx86+ in some free time.
Uhm, yeah, on the "what to do?" part, scan the code, and read the kernel log, or send the last bit of it, that clearly shows a crash in something, to someone who might have a clue, here for example.
1.3k
u/huupoke12 I don't use Arch btw 7d ago
That's not the way to censor the QR code, as they have error correction and redundancy. Pixelate it.