I'm more partial to PCFkb2N0eXBlIGh0bWw+
Spotting base64 encoded JSON, certificates, and private keys
81–90 of 135 posts
Re: Spotting base64 encoded JSON, certificates, and private keys
#82Not directly correlated but I know a old guy that can decrypt EBCDIC and credit card positional data format on the fly. And sometimes it was a "feeling" he couldn't explain it properlly but knew exactly the value, name and other data. It was amazing to see him decode VISA and MASTER transactions on the fly in logs and other places.
That's got to be the most niche party trick I've ever heard of.
Re: Spotting base64 encoded JSON, certificates, and private keys
#83Not directly correlated but I know a old guy that can decrypt EBCDIC and credit card positional data format on the fly. And sometimes it was a "feeling" he couldn't explain it properlly but knew exactly the value, name and other data. It was amazing to see him decode VISA and MASTER transactions on the fly in logs and other places.
I would hope that these logs don't include the full details of the credit card (such as number/cvv).. if it does, the company that is logging this info could end up having some issues with Visa/MC
Edit: Now that I looked at it a little deeper, i'm assuming they are talking about these[0] sort of files?
Re: Spotting base64 encoded JSON, certificates, and private keys
#84I built a JWT support library at work ( https://github.com/geldata/gel-rust/tree/master/gel-jwt ) and I can confirm that JWTs all sound like "eyyyyyy" in my head.
Ey, I'm JSON!
Re: Spotting base64 encoded JSON, certificates, and private keys
#85Earlier quoted context omitted.
And there goes my limit of curiosity now regarding this. I'm interested in what you have to say, but not 25 page mini-novel PDF from someone else interested. I'm glad you enjoyed that piece, but I have no interest in reading it, nor do I think it's reasonable for you to expect me to be interested. Much like with the author and the specifics of this encoding.
[flagged]
I guess I fully deserve this as some sort of karmic retribution, because I'm usually the person in the room who's frustrated about people poking things they don't fully understand, about folks continuing to spitball rather than looking a layer deeper, and the one who over-obsesses over details. It took me a very long time to accept that sometimes ignorance is not only acceptable, but optimal, and it continues to challenge me to this day.
You mention "being hackerly". Imagine you were reverse engineering some gnarly 100 MB obfuscated x86 binary. Surely you can appreciate that especially if you have a specific goal, it is overwhelmingly preferable to guess, experiment, and poke than to kick off some heroic RE effort that will take tens of people years, just so that you can supposedly "fully understand" what's happening. Attention is precious - not everything is worth equal attention. And it is absolutely possible to correctly guess things from limited information, and is even essential to be able to.
You find base64 encoding interesting enough that you were able to either recall detailed facts about its operation from memory here, or looked it up quickly to break it down. How is the author, or me, not doing so is any evidence for you we're:
- ignorant about how base64 works and always have been
- don't care about (CS) things at depth in general
These are such immensely strong claims to make. Surely you can appreciate that some people just have different interests sometimes? That they might focus on different things? That they can learn things and then forget about them? That to some level everything is connected, so appealing to that is not exactly some grand revelation of missing a "key piece"?
Few years, or I guess more than just a few years ago, in college, I met up with a former classmate from primary school. He was studying history and shared some great (historical) stories that I really enjoyed. But then another thought formulated in my mind: if I had to actively study this, rather than just catch a story or two, I'd definitely be dropping out. And that's when I realized that there can be value to things, they can be interesting, yet at the same time it's OK for me not to be interested by them or pursue them deeper. Just like how I think it is perfectly OK to be interested in this pattern, but not care for the underlying mapping mechanism, as it is essentially irrelevant. The fun was in the fact, not in the mechanism (in my view for the author anyways).
Re: Spotting base64 encoded JSON, certificates, and private keys
#86Not directly correlated but I know a old guy that can decrypt EBCDIC and credit card positional data format on the fly. And sometimes it was a "feeling" he couldn't explain it properlly but knew exactly the value, name and other data. It was amazing to see him decode VISA and MASTER transactions on the fly in logs and other places.
I would hope that these logs don't include the full details of the credit card (such as number/cvv).. if it does, the company that is logging this info could end up having some issues with Visa/MC Edit: Now that I looked at it a little deeper, i'm assuming they are talking about these[0] sort of files? [0]: https://docs.helix.q2.com/docs/card-transaction-file
PCI DSS is a relatively new thing. Before it card data flew in the open
Re: Spotting base64 encoded JSON, certificates, and private keys
#87Good knowledge, now explain why it's like that. {" is ASCII 01111011, 00100010 Base64 takes 3 bytes x 8 bits = 24 bits, groups that 24 bit-sequence into four parts of 6 bits each, and then converts each to a number between 0-63. If there aren't enough bits (we only have 2 bytes = 16 bits, we need 18 bits), pad them with 0. Of course in reality the last 2 bits would be taken from the 3rd character of the JSON string,…
The author also doesn't explain what JSON is. Because it's obvious to the target audience. There's simply no explanation necessary
Re: Spotting base64 encoded JSON, certificates, and private keys
#88Not directly correlated but I know a old guy that can decrypt EBCDIC and credit card positional data format on the fly. And sometimes it was a "feeling" he couldn't explain it properlly but knew exactly the value, name and other data. It was amazing to see him decode VISA and MASTER transactions on the fly in logs and other places.
I've seen that done live, during audits, on live logs on the screen. Needles to say, audit didn't fly first time round (those logs should have been redacted).
Re: Spotting base64 encoded JSON, certificates, and private keys
#89Earlier quoted context omitted.
I'd be very hesitant to consider this as some runaway symbol of "CS people being incurious now" over the author simply not being this deeply invested in this at the time of writing in the context of their discovery, especially since it almost certainly doesn't actually matter for them beyond the pattern existing, if even that does.
> it almost certainly doesn't actually matter for them beyond the pattern existing, if even that does. https://web.cs.ucdavis.edu/~rogaway/classes/188/materials/th...
Wow, that's an amazing story. I'd never read anything by E. M. Forster before, and I certainly wasn't expecting 1920s sci-fi like that.
Re: Spotting base64 encoded JSON, certificates, and private keys
#90Earlier quoted context omitted.
Years ago I was part of a group of people I knew who could read and edit large parts of sendmail.cf by hand without using m4. Other people who had to deal with mail servers at the time certainly treated it like a superpower.
In some ways, I miss those days. Spending hours wrangling sendmail.cf, and finally succeeding, felt like a genuine accomplishment. Nowadays, things just work, mostly. How boring.
I feel that nowadays, it's a combination of "things just work" and "if they don't, good luck figuring out why".
I recently installed Tru64 UNIX on a DEC Alpha I got off eBay. I felt like it was more sluggish than it should be, so I looked around at man-Pages about the VM (virtual memory, not virtual machine) subsystem, and was amazed how cleanly and detailed it was described, and what insights I could get about its state. The sys_attrs_vm man-page alone, which just describes every VM-layer tunable, gave a pretty good description of what the VM subsystem does, how each of those tunables affects it, and why you might want to change it.
Nowadays, things are massively complex, underdocumented (or just undocumented), constantly changing, and often inconsistent between sub-parts. Despite thinking that I have both wide and deep knowledge (I'm a low-level code kernel dev), it often takes me ages to figure out the root cause of sometimes even simple problems.