10 interesting stories served every morning and every evening.
September 2024
At a YC event last week Brian Chesky gave a talk that everyone who
was there will remember. Most founders I talked to afterward said
it was the best they’d ever heard. Ron Conway, for the first time
in his life, forgot to take notes. I’m not going to try to reproduce
it here. Instead I want to talk about a question it raised.
The theme of Brian’s talk was that the conventional wisdom about
how to run larger companies is mistaken. As Airbnb grew, well-meaning
people advised him that he had to run the company in a certain way
for it to scale. Their advice could be optimistically summarized
as “hire good people and give them room to do their jobs.” He
followed this advice and the results were disastrous. So he had to
figure out a better way on his own, which he did partly by studying
how Steve Jobs ran Apple. So far it seems to be working. Airbnb’s
free cash flow margin is now among the best in Silicon Valley.
The audience at this event included a lot of the most successful
founders we’ve funded, and one after another said that the same
thing had happened to them. They’d been given the same advice about
how to run their companies as they grew, but instead of helping
their companies, it had damaged them.
Why was everyone telling these founders the wrong thing? That was
the big mystery to me. And after mulling it over for a bit I figured
out the answer: what they were being told was how to run a company
you hadn’t founded — how to run a company if you’re merely a
professional manager. But this m.o. is so much less effective that
to founders it feels broken. There are things founders can do that
managers can’t, and not doing them feels wrong to founders, because
it is.
In effect there are two different ways to run a company: founder
mode and manager mode. Till now most people even in Silicon Valley
have implicitly assumed that scaling a startup meant switching to
manager mode. But we can infer the existence of another mode from
the dismay of founders who’ve tried it, and the success of their
attempts to escape from it.
There are as far as I know no books specifically about founder mode.
Business schools don’t know it exists. All we have so far are the
experiments of individual founders who’ve been figuring it out for
themselves. But now that we know what we’re looking for, we can
search for it. I hope in a few years founder mode will be as well
understood as manager mode. We can already guess at some of the
ways it will differ.
The way managers are taught to run companies seems to be like modular
design in the sense that you treat subtrees of the org chart as
black boxes. You tell your direct reports what to do, and it’s up
to them to figure out how. But you don’t get involved in the details
of what they do. That would be micromanaging them, which is bad.
Hire good people and give them room to do their jobs. Sounds great
when it’s described that way, doesn’t it? Except in practice, judging
from the report of founder after founder, what this often turns out
to mean is: hire professional fakers and let them drive the company
into the ground.
One theme I noticed both in Brian’s talk and when talking to founders
afterward was the idea of being gaslit. Founders feel like they’re
being gaslit from both sides — by the people telling them they
have to run their companies like managers, and by the people working
for them when they do. Usually when everyone around you disagrees
with you, your default assumption should be that you’re mistaken.
But this is one of the rare exceptions. VCs who haven’t been founders
themselves don’t know how founders should run companies, and C-level
execs, as a class, include some of the most skillful liars in the
world.
Whatever founder mode consists of, it’s pretty clear that it’s going
to break the principle that the CEO should engage with the company
only via his or her direct reports. “Skip-level” meetings will
become the norm instead of a practice so unusual that there’s a
name for it. And once you abandon that constraint there are a huge
number of permutations to choose from.
For example, Steve Jobs used to run an annual retreat for what he
considered the 100 most important people at Apple, and these were
not the 100 people highest on the org chart. Can you imagine the
force of will it would take to do this at the average company? And
yet imagine how useful such a thing could be. It could make a big
company feel like a startup. Steve presumably wouldn’t have kept
having these retreats if they didn’t work. But I’ve never heard of
another company doing this. So is it a good idea, or a bad one? We
still don’t know. That’s how little we know about founder mode.
Obviously founders can’t keep running a 2000 person company the way
they ran it when it had 20. There’s going to have to be some amount
of delegation. Where the borders of autonomy end up, and how sharp
they are, will probably vary from company to company. They’ll even
vary from time to time within the same company, as managers earn
trust. So founder mode will be more complicated than manager mode.
But it will also work better. We already know that from the examples
of individual founders groping their way toward it.
Indeed, another prediction I’ll make about founder mode is that
once we figure out what it is, we’ll find that a number of individual
founders were already most of the way there — except that in doing
what they did they were regarded by many as eccentric or worse.
Curiously enough it’s an encouraging thought that we still know so
little about founder mode. Look at what founders have achieved
already, and yet they’ve achieved this against a headwind of bad
advice. Imagine what they’ll do once we can tell them how to run
their companies like Steve Jobs instead of John Sculley.
Notes
The more diplomatic way of phrasing this statement would be
to say that experienced C-level execs are often very skilled at
managing up. And I don’t think anyone with knowledge of this world
would dispute that.
If the practice of having such retreats became so widespread
that even mature companies dominated by politics started to do it,
...
Read the original on paulgraham.com »
When I’m working on maintaining an unfamiliar codebase, I will spend a lot of time grepping the code base for strings. Even in projects exclusively written by myself, I have to search a lot: function names, error messages, class names, that kind of thing. If I can’t find what I’m looking for, it’ll be frustrating in the best case, or in the worst case lead to dangerous situations where I’ll assume a thing is not needed anymore, since I can’t find any references to it in the code base. From these situations, I’ve derived some rules you can apply to keep your code base greppable:
It turns out that splitting up, or dynamically constructing identifiers is a bad idea.
Suppose you have two database tables shipping_addresses, billing_addresses, it might seem like a perfectly good solution to construct the table name dynamically from the order type.
const getTableName = (addressType: ‘shipping’ | ‘billing’) => {
return `${addressType}_addresses`
Though it looks nice and DRY, it’s not great for maintainenance: someone will inevitably search the code base for the table name shipping_addresses and miss this occurence.
const getTableName = (addressType: ‘shipping’ | ‘billing’) => {
if (addressType === ‘shipping’) {
return ‘shipping_addresses’
if (addressType === ‘billing’) {
return ‘billing_addresses’
throw new TypeError(‘addressType must be billing or shipping’)
The same goes for column names, object fields, and, god forbid, method/function names (it’s easily possible to dynamically construct method names with javascript).
Don’t rename fields at application boundaries to match naming schemes. An obvious example is then importing postgres-style snake_case identifiers into javascript, then converting them to camelCase. This makes it harder to find—you now have to grep for two strings instead of one in order to find all occurences!
const getAddress = async (id: string) => {
const address = await getAddressById(id)
return {
streetName: address.street_name,
zipCode: address.zip_code,
You’re better off biting the bullet and returning the object directly:
const getAddress = async (id: string) => {
return await getAddressById(id)
Taking inspiration from the Zen of Python, when dealing with namespaces, flattening your folders/object structures is mostly better than nesting.
For example if you have two choices to set up your translation files:
“auth”: {
“login”: {
“title”: “Login”,
“emailLabel”: “Email”,
“passwordLabel”: “Password”,
“register”:
“title”: “Register”,
“emailLabel”: “Email”,
“passwordLabel”: “Password”,
“auth.login.title”: “Login”,
“auth.login.emailLabel”: “Email”,
“auth.login.passwordLabel”: “Password”,
“auth.register.title”: “Login”,
“auth.register.emailLabel”: “Email”,
“auth.register.passwordLabel”: “Password”,
take the second option! You will be able to easily find your keys now, which you are probably referring to as something like t(‘auth.login.title’).
Or consider React component structure: a component stucture like
./components/AttributeFilterCombobox.tsx
./components/AttributeFilterDialog.tsx
./components/AttributeFilterRating.tsx
./components/AttributeFilterSelect.tsx
./components/attribute/filter/Combobox.tsx
./components/attribute/filter/Dialog.tsx
./components/attribute/filter/Rating.tsx
./components/attribute/filter/Select.tsx
from a greppability perspective, since you’ll be able to grep for the whole namespaced component AttributeFilterCombobox just from the usage, as opposed to just Dialog, which you might have multiple of accross your application.
...
Read the original on morizbuesing.com »
Beautiful, and Boring Investment Tracker, with Local Data Storage. No Subscriptions, No Cloud. Wealthfolio is a simple, desktop-based investment tracker. Your financial data is stored safely on your own computer Ditch the spreadsheets, forget about those pesky subscription fees, and no more worries about SaaS services playing around with your data.The Essentials You Need to Track Your WealthForget juggling spreadsheets or compromising privacy with online apps. Choose Wealthfolio’s simple, secure approach to manage your finances.Gather all your investment and savings accounts in one place. See everything at a glance, from stocks to savings! Import your statements from your broker or bank.Track your accounts’ holdings and performance over time. See how a particular account is performing, and how it’s changing over time.Get a clear picture of what’s in your portfolio. Stocks, bonds, or mutual funds - know what you have and how it’s performing.Monitor dividends and interest income across your entire portfolio. Get a clear view of your passive income streams, helping you make informed decisions about your investments.Set your savings targets clearly. Distribute your funds across these objectives, assigning a specific percentage to each. Keep an eye on your progress.
...
Read the original on wealthfolio.app »
Hello everyone - it’s been a while!
I was super busy with university and my mandatory internship in a software company for the past 6 months, so I haven’t posted in a while. But that doesn’t mean that I was inactive - I spent nearly every evening and every weekend working on SpaceHey. I didn’t develop any new ground-breaking features, but instead I focused on improving the overall SpaceHey experience - making it smoother, more stable, easier to use and safer.
But before I get into the details, let’s have a look at a huge milestone first: SpaceHey hit 1 Million registered users!! That’s crazy!!
I launched SpaceHey at the end of 2020 - I had just graduated high-school, and the world was on Covid lockdown. I made SpaceHey, so my generation could experience the early days of social media - without a feed, likes and whatnot - but instead with colorful, customizable profiles, bulletins and forums. I didn’t plan to create anything big - I just had some fun creating this site and improving my coding skills at the same time.
Still, three and a half years later - SpaceHey has indeed become big. One million people is an incredibly huge number of people - it’s simply crazy! If someone would’ve told my 18-year-old self in 2020, I would’ve never believed them. And yet - here we are. I am so incredibly thankful for all the support over the past three and a half years - the friends I made along the way and the lessons I’ve learned - both in running a community as big as this one as well as the technical challenges that came along.
One million people from all over the world have used SpaceHey so far - an independently run platform that does not track you and does not show you personalized feeds nor ads. My mission is not to become another big social network like Facebook or Twitter (I don’t think I’ll ever call it “X”) - but rather trying to be different. More personal, more fun to use, and more humane. And I’m proud to say that this mission is still very much alive - no matter if there were 500 users or 1,000,000.
If you like SpaceHey and want to support the platform, you can support me here, and there is also a special #1 Million Merch drop available here
to support SpaceHey. Your support - no matter if it’s a donation or a Merch order - is what keeps SpaceHey running: thank you!!
I’ve stopped myself from working on any new features in the past months, but rather improve the existing ones and make SpaceHey overall a bit smoother. It wasn’t easy - but I think it was worth it. You may have already noticed less downtime and less App crashes in the past weeks - and there are some more improvements coming soon.
I’m now also starting to work on some new features again - which is super fun - and I can’t wait to share more with you soon (T8 👀) - so stay tuned!
Another big topic I worked on in the past months is safety. As more and more people joined SpaceHey, the bots and spammers also increased. Spam, hate speech, and other kinds of harmful content has no place on SpaceHey - that’s why a solution was needed, and eventually found.
The solution isn’t actually one solution - but a combination of multiple. On the one hand, I’ve implemented more ways to prevent spam in the first place - and on the other hand, I’ve developed more ways to combat existing spam. I’ve expanded the volunteer moderation team and improved the ways the team can discover spam, react to reports
and keep track of rule violations. I am immensely thankful to the volunteers helping me, and I think we are on a great path to keep SpaceHey safe.
If you come across harmful content on SpaceHey, please click the “Report” icon next to it, and we’ll check it. Thank you for doing your part!
I am super thrilled to keep working on SpaceHey - there are so many awesome, talented and fun people here. I can’t wait to keep improving the site and the App and keep working on some great new features in the near future. I am super happy to have you all here, and I hope you are enjoying this journey as much as I do!
Last but not least, a huge thank you to every single one of you - you are the people who make SpaceHey what it is - you make it awesome. Thank you so, so much!
Have an awesome day & thank you for using SpaceHey!
An
...
Read the original on blog.spacehey.com »
Secure elements are small microcontrollers whose main purpose is to generate/store secrets and then execute cryptographic operations. They undergo the highest level of security evaluations that exists (Common Criteria) and are often considered inviolable, even in the worst-case attack scenarios. Hence, complex secure systems build their security upon them.
FIDO hardware tokens are strong authentication factors to sign in to applications (any web service supporting FIDO); they often embed a secure element and the FIDO protocol uses Elliptic Curve Digital Signature Algorithm (ECDSA for short) as its core cryptographic primitive. are certainly the most widespread FIDO hardware tokens, their secure element is an Infineon .
This document shows how — finding a JavaCard open platform (the ) based on a similar Infineon — we understood the Infineon ECDSA implementation, found a side-channel vulnerability and designed a practical side-channel attack. The attack is then demonstrated on a . Finally, we show that the vulnerability extends to the more recent Infineon and Infineon security microcontrollers.
Our work unearths a side-channel vulnerability in the cryptographic library of Infineon Technologies, one of the biggest secure element manufacturers. This vulnerability — that went unnoticed for 14 years and about 80 highest-level Common Criteria certification evaluations — is due to a non constant-time modular inversion.
The attack requires physical access to the secure element (few local electromagnetic side-channel acquisitions, i.e. few minutes, are enough) in order to extract the ECDSA secret key. In the case of the FIDO protocol, this allows to create a clone of the FIDO device.
All YubiKey 5 Series (with firmware version below 5.7) are impacted by the attack and in fact all Infineon security microcontrollers (including TPMs) that run the Infineon cryptographic library (as far as we know, any existing version) are vulnerable to the attack. These security microcontrollers are present in a vast variety of secure systems — often relying on ECDSA — like electronic passports and crypto-currency hardware wallets but also smart cars or homes. However, we did not check (yet) that the EUCLEAK attack applies to any of these products.
Authentication tokens (like FIDO hardware devices) primary goal is to fight the scourge of phishing attacks. The EUCLEAK attack requires physical access to the device, expensive equipment, custom software and technical skills. Thus, as far as the work presented here goes, it is still safer to use your YubiKey or other impacted products as FIDO hardware authentication token to sign in to applications rather than not using one.
* All Infineon security microcontrollers embedding Infineon cryptographic library (any existing version). For instance, all existing versions of Infineon TPMs are affected.
* All (with firmware version below 5.7)
1. The impacted Feitian A22 Javacard used in this work is an old product no more available for sale. All Feitian products currently available on their webstore (and based on an Infineon security microcontroller) use Feitian own cryptographic library, and are not impacted by our work to our knowledge.
2. The new YubiKey firmware 5.7 update (May 6th, 2024) switches the YubiKeys from Infineon cryptographic library to Yubico new cryptographic library. To our knowledge, this new cryptographic library is not impacted by our work.
3. Infineon has already a patch for their cryptographic library, to our knowledge it did not yet pass a Common Criteria certification evaluation.
We are still waiting for a CVE ID.
...
Read the original on ninjalab.io »
It’s a quiet Saturday afternoon. I’ve carved out a few precious hours for coding, armed with a steaming cup of coffee and the familiar urge to dive into a project. As I settle into my chair and open my terminal, I’m confronted with a challenge that’s become all too familiar: deciding which of my many unfinished projects to tackle.
I navigate to my project directory, greeted by a graveyard of half-implemented ideas and stalled works-in-progress. Each one represents a different problem I’ve tried to solve, a different technology I’ve attempted to master. They’re all interesting, each with its own purpose and potential. But as I scan through them, I can already feel my enthusiasm waning. I know that whichever one I choose, I’ll be facing not just the original problem, but a hydra of new challenges that have sprouted since I last looked at the code.
After some deliberation, I make my choice and fire up my IDE. As I pull the latest changes and begin the archaeological dig through my commit history, I brace myself for what I know I’ll find. Sure enough, there it is: an unfinished frontend task, more wireframe than polished UI. Or perhaps it’s a library integration that’s hitting limitations I hadn’t anticipated. Or, in classic over-engineering fashion, I’ve built a complex architecture for a problem that could have been solved with a simple script.
I roll up my sleeves and dive in, determined to make progress. The next couple of hours fly by in a flurry of activity — refactoring code, debugging integration issues, or wrestling with CSS to get that one component to align just right. Before I know it, my allocated time is up.
As I prepare to step away from my desk, I can’t shake a feeling of frustration. I started the session full of optimism, ready to make significant headway. Now, I’m left with a nagging sense of inadequacy. Despite my efforts, it feels like I’ve barely moved the needle. The codebase is still a maze of TODO comments and half-implemented features. The Hydra of software development has grown two new heads for every one I managed to address.
This cycle of enthusiasm, struggle, and disappointment has become all too familiar. It’s the Hydra Project Effect: no matter how much progress I make, new challenges always seem to sprout in their place. But while this pattern may seem unbreakable, I’m determined to find a way to tame this beast. In this post, I’ll explore strategies for breaking out of this cycle of endless beginnings and unsatisfying middles. It’s time to learn the art of finishing, to slay this Hydra once and for all, and to finally experience the satisfaction of a completed project.
There’s a certain comfort in the realm of infinite possibility. When a project is ongoing, it can be anything. It’s Schrödinger’s1 project — simultaneously perfect and flawed until you actually finish it and put it out into the world. The moment you declare a project “done,” you open it up to criticism, both external and internal. What if it’s not good enough? What if I missed something crucial?
This fear of finality, combined with the excitement of new ideas, creates an ideal environment for project procrastination. It’s always easier to start something new than to push through the final, often tedious stages of completion of a project. But there’s more to it than just fear.
An unfinished project is full of intoxicating potential. It could be the next big thing, a revolutionary idea, or your magnum opus. This potential often feels more exciting than the reality of a finished product. There’s also comfort in the familiar territory of an ongoing project. You know the codebase, you understand the problems, and you’re in your element. Starting something new means facing the unknown, which can be daunting.
The illusion of productivity plays a significant role too. As long as you’re working on something, you feel productive. Jumping from project to project gives you a constant stream of “new project energy,” which can feel more invigorating than the grind of finishing a single project. It’s a way of avoiding difficult decisions that come with completion. Do you cut that feature you spent weeks on but isn’t quite right? Do you release now or spend another month polishing? By keeping projects ongoing, you can sidestep these challenging choices.
The absence of deadlines in personal projects adds another layer to this complexity2. Without the external pressure of a due date, it’s all too easy to fall into the trap of perfectionism. We find ourselves endlessly tweaking and refining, always chasing that elusive “perfect” solution. The irony is that this pursuit of perfection often leads to imperfect results — or no results at all. In our professional lives, deadlines force us to prioritize and make pragmatic decisions. But in personal projects, the luxury of unlimited time can become a curse, allowing us to justify spending hours, days, or even weeks on minor details that, in reality, make little difference to the project’s overall success or usefulness. It’s a stark reminder that sometimes, “good enough” truly is perfect, especially when the alternative is never finishing at all.
Paradoxically, sometimes we fear success as much as failure. A successful project might lead to increased expectations, more responsibility, or a change in identity that we’re not quite ready for. The unfinished project becomes a safety net, protecting us from the unknown consequences of success.
But this cycle of endless beginnings comes at a steep price. There’s a unique satisfaction in seeing a project through to completion that no amount of starting can match. Moreover, unfinished projects carry a mental weight. They linger in the back of your mind, quietly draining your mental energy and enthusiasm.
Perhaps most importantly, we learn different lessons from finishing projects than we do from starting them. Starting teaches us about ideation and initial implementation. Finishing, on the other hand, teaches us about perseverance, attention to detail, and the art of knowing when to let go. These are invaluable skills that can only be honed through the act of completion.
The costs of never finishing extend far beyond just missed opportunities. While starting projects might expose you to new technologies or concepts, it’s in the act of finishing — of solving those last, trickiest problems — where real skill growth often occurs. Each unfinished project can chip away at your confidence. Over time, you might start to doubt your ability to complete anything substantial, creating a self-fulfilling prophecy of incompletion.
The end stages of a project often involve optimization, refactoring, and really understanding the intricacies of your code. By not finishing, you miss out on these valuable learning experiences. In professional settings, being known as someone who starts things but doesn’t finish them can be detrimental to your career. Employers and clients value those who can deliver completed projects, making the ability to finish a crucial professional skill.
Every unfinished project takes up mental space. It’s like having dozens of browser tabs open — each one uses a little bit of your mental RAM, leaving you with less capacity for new ideas and focused work. This mental clutter can be a significant drain on your creativity and productivity.
Perhaps most importantly, you deny yourself the incomparable feeling of satisfaction when you release a finished project into the world. There’s a joy in shipping that can’t be replicated by starting something new. Finished projects also invite feedback, and without shipping, you miss out on valuable insights from users or peers that could significantly improve your skills and future projects.
Understanding both the allure of endless projects and the cost of never finishing is crucial. It’s not about dismissing the excitement of new beginnings, but rather about finding a balance — learning to channel that initial enthusiasm into the equally important (if sometimes less glamorous) work of seeing things through to completion. By recognizing these patterns in ourselves, we can start to develop strategies to overcome them and finally slay the Project Hydra.
So, how do I break this cycle? How do I learn to finish what I start? Here are some strategies I’m implementing to tame my own Project Hydra:
✅ Define “Done” from the Start: Before diving into a project, I’ll clearly define what “finished” looks like. What are the core features that constitute a complete project? I’ll write them down and resist the urge to expand this list as I go. This clarity helps prevent scope creep and gives me a clear target to aim for.
🚀 Embrace MVP: Instead of aiming for perfection, I’ll aim for “good enough.” I’ll get a basic version working and out into the world. I can always iterate and improve later. This approach helps maintain momentum and provides early feedback opportunities.
⏳ Time-Box My Projects: I’ll give myself a deadline. It doesn’t have to be short, but it should be finite. Having an end date creates urgency and helps me prevent endless feature creep. I find that breaking larger projects into smaller, time-boxed phases helps maintain a sense of progress.
🧩 Practice Finishing Small Things: I’ll build my “finishing muscle” by completing small projects or tasks regularly. I recognize that the skill of finishing is like any other — it improves with practice. This could be as simple as finishing a blog post or completing a small coding challenge each week.
💡 Separate Ideation from Implementation: I’ll keep a separate idea log. When new features or project ideas pop up during implementation, I’ll jot them down for future consideration instead of immediately acting on them. This helps maintain focus on the current project while still capturing potentially valuable ideas.
🎉 Celebrate Completions: I’ll make finishing a big deal. I’ll celebrate when I complete a project, no matter how small. This positive reinforcement can help shift my mindset towards completion. Whether it’s treating myself to a nice dinner or simply sharing my accomplishment with friends, acknowledging these wins boosts motivation for future projects.
👥 Embrace Accountability: I’ll find ways to make myself accountable for finishing projects. This could involve finding an accountability partner, making public commitments about project milestones, or joining a group of fellow developers. External accountability adds motivation and support to the often solitary journey of personal projects.3
These strategies provide my personal roadmap for overcoming the challenges of the Project Hydra. By implementing them consistently, I hope to develop better habits and increase my chances of seeing projects through to completion. It’s about creating a supportive structure around my work, balancing internal motivation with external accountability, and gradually building the skill of finishing.
Of course, strategies are just the beginning. The real challenge lies in consistently applying these approaches to my work. It’s a process of trial and error, of learning what works best for my personal style and the specific demands of each project. But with each small win, with each project pushed a little closer to completion, I’m building the habits and mindset needed to finally tame the Project Hydra.
The path ahead will be challenging. I know that changing ingrained habits and thought patterns will take time and consistent effort. There will likely be setbacks along the way — moments when the allure of a new project tempts me away from finishing the current one, or when the fear of imperfection makes me hesitate to declare something “done”. But I’m committed to pushing through these obstacles and building my “finishing muscle”.
This journey isn’t just about completing code; it’s about growing as a developer and creator. Each finished project, no matter how small, is a step towards becoming someone who not only starts with enthusiasm but finishes with satisfaction.
The Project Hydra has loomed over my work for too long. Armed with new strategies and determination, I’m ready to face this beast head-on. It’s time to stop planning and start doing.
Now, if you’ll excuse me, I have a project to finish — and this time, I intend to see it through.4
...
Read the original on www.bytedrum.com »
I happened to look at a slide deck from Sandia National Laboratories from 2007 that someone had posted on Reddit late last night (you know, as one does, instead of sleeping), and one particular slide jumped out at me:
It’s a little graphic advertising the different kinds of modeling software that are part of something called the SIERRA framework, as part of a pretty standard “overview” presentation on computer modeling at Sandia that was given at a meeting in Luxembourg.
Did you catch the part that made me stop and audibly say, “uhhhhh“? Look at the lower right:
So, that looks an awful lot like the cutaway of a compact thermonuclear weapon design. I immediately wondered if I couldn’t find a better resolution version of the same graphic, so I went onto OSTI.gov and starting plugging in terms that seemed relevant. Searching for “Sierra” and “Salinas” and restricting to “Conference presentations” turned up a bunch of other instances of it from the 2007-2011 or so timeframe. The one with the highest resolution came from another presentation, from 2008:
So this is awfully strange. We’ve got something here that looks like a plausible reentry vehicle for a nuclear warhead. The bits in red, yellow, perhaps fuscia at the “tip” are in the position (and about the right size) to be the arming, fuzing, and firing system. The bits below that — the green, the blue, etc. — look like a thermonuclear warhead. The green part looks like it is meant to represent the location of the “primary,” while the the cylinders-within-cylinders are a classic representation of a thermonuclear “secondary.” One could debate about the exact identity of each color, but it looks a lot like it is meant to represent a radiation case, an interstage medium, a tamper, fusion fuel, and a “sparkplug.” You’ve even got an interesting little “dip” into the central cylinder which looks like a channel to get neutrons into the “sparkplug.”
By comparison, this image from later in the presentation looks a lot more like what one would expect them to release about a reentry vehicle in a public document — just the arming, fuzing, and firing system (the top part, with the detail at right), and then the “warhead” section depicted as a featureless blank:
Even that is a little more revealing than usual, as it gives pretty precise dimensions. So seeing something that looks like it is meant to represent the warhead itself is… pretty surprising!
This isn’t some one-off slip up kind of thing. This particular graphic is present in at least half-a-dozen conference presentations on OSTI.gov, and even some on a few other government websites (like this presentation given to NASA). It’s literally the logo they use for this particular software package. And it’s not some kind of redaction error, like the ones I wrote about previously, in which things not dissimilar from the above were very clearly intended to be redacted, but were done so poorly that you could in fact see some aspects of them. This is literally the logo for this particular software framework, and it has been used in lots of presentations (including those done overseas), and is posted all over unclassified, public-facing databases hosted by the federal government.
It took me a little more searching, but I eventually tracked down an isolated version of the image from yet another Sandia presentation:
The slide doesn’t give any clarification as to what we’re looking at, here, other than indicating that it part of modeling work for the purposes of structural dynamics, and is clearly part of a nuclear weapons context.
The SIERRA software framework, I gather, is a simulation/modeling toolkit that allowed scientists to basically simulate a relatively “full spectrum” of weapons safety issues. This is Sandia’s bread and butter: making sure that your weapon won’t go off if, say, you drop it, or set it on fire, or let it get hit by lightning. Things which have happened a number of times over the years. The “Salinas” package in particular seems to be about modeling mechanical aspects of materials. Which is to say, this demonstration of its “capabilities” is not about showing you that it is modeling how a nuclear weapon would detonate. It is showing you, “look, we can model a lot of different materials — steel, uranium, lithium, etc. — and could probably tell you whether they would crack or strain or shatter or whatever if you, say, dropped this weapon.” That’s my quick gloss on the various presentations, anyway.
To give a sense of how strange this is, here is the only “officially sanctioned” way to represent a multistage thermonuclear weapon, according to US Department of Energy guidance since the 1990s:
Two circles in a box, maybe inside of a reentry vehicle. That’s it. Nothing that gives any actual sense of size, location, materials, physicality. One can compare this with the images of more speculative thermonuclear weapon designs in the public domain for a sense of how limited the official release is compared with what is “believed to be known” about such things:
Incidentally, I submitted a FOIA request on that particular guidance document (TCG-NAS-2) some time back, and the document that I got back was hilariously redacted to the point that even terms like “gun-type” and “implosion” were redacted, much less any and all images, despite that document apparently containing examples of what actually could be said publicly about these things. Which is just to emphasize, it’s not like the DOE is particularly loose about even as vaguely representational an image as is that one — if anything, the err in the other direction.
Why are they so uptight about thermonuclear weapon design “shapes”? The official reason, of course, is because of proliferation concerns. But there’s another reason: even the appearance of giving away “secrets” can generate unwanted publicity and political scandal.
In 1999, the Cox Committee’s report on Chinese nuclear espionage made some hay out of publicly-available depictions of H-bombs, and featured an entire spread dedicated to the fact that “visitors to Los Alamos National Laboratory are provided a 72-page publication that provides, among other things, a primer on the design of thermonuclear weapons.” It sensationalized that very two-circles-in-a-box image that I showed above, and weaponized it. How dare Los Alamos give that away! Despite it being unclassified. But that’s what I mean by unwanted political scandal — lots of scandals about the release of “secrets” involve non-secrets. (There’s a lot on this sort of thing in my book, of course.)
Which leads us to an interesting puzzle: why would the censors repeatedly allow Sandia to use what appears to be a thermonuclear weapon cutaway as part of a promotional diagram for a software package? There are a few possibilities that come to my mind.
One is the idea that this is an accident, a leak, an oopsie. I find this unlikely to the point of near impossibility. Not because the classification officers are perfect. But this is so obviously not something you would authorize for release if you thought it was representing something classified. To have approved many presentations with this graphic in it to go out into the world, to be posted on the websites of multiple government agencies… they’re not perfect, but they’re not fools. Again, if anything, they tend to err on the side not releasing enough. So I find it hard to believe that they’d have messed this up, again and again, when it is the most blatant thing in the world. This isn’t some subtle technical thing. Anyone who thinks about weapons information and secrecy is going to know what a cylindrical secondary looks like. I mean, this thing jumps off the page if you are that kind of person. Which I am, of course, but so are redactors. If this were the case, it would be an incredible and repeat failure of the classification system at many points, in the same way, over several years. One can’t say such a thing is impossible but I find that extremely unlikely.
Another easily dismissible possibility is that this is some kind of deliberate release of classified information. Again, there is an entire infrastructure devoted to not letting this happen. With peoples’ jobs, security clearances, and personal freedoms on the line. Plus the fact that the people who tend to work in these jobs take for granted that secrecy translates to security. Even actual spies wouldn’t do it this way — they’re not about releasing secrets to the public, they’re about channeling them to the people they are spying to, quiet-like.
So we’re left with much more plausible conclusion that they consider this to be unclassifiable and benign. But why would they think that, given what we know about how sensitive they are to anything that comes even remotely close to representing internal weapon components?
The “obvious” answer, if my above assertions are true, is that it must not actually represent a thermonuclear secondary. What else could it be? It could be some kind of pre-approved “unclassified shape” which is used for diagnostics and model verification, for example. There are other examples of this kind of thing that the labs have used over time. That is entirely a possibility. What would be bizarre about this being the answer is that a) “unclassified shapes” generally don’t look like actual, plausible weapon designs, and this thing looks “close-enough”; b) it still gives off the appearance of a classified shape, which as noted, is dangerous in and of itself from a political standpoint; and c) if the goal is just to show off modeling capabilities in a very superficial way (this is essentially an advertising logo) they surely could have picked a million less provocative (from a classification standpoint) examples.
It’s also possible that it isn’t even meant to be a nuclear weapon at all. Sure, it looks like a reentry vehicle. Yeah… it seems awfully nuke-shaped. But there are other things that can look like nukes but at really meant to be something else. Maybe I’m seeing a “secondary” because I’m primed to see one, by the context? It’s… possible. Neither spheres-within-sphere nor cylinders-within-cylinders are inherently related to nuclear weapons components. But when you place them like that, in a reentry vehicle, in that order… it looks very much like a fusing system, a primary, a secondary… It would be quite surprising to me if it was not meant to be representative of those things, but something totally different. And, again, the original context of that model appears to be very firmly rooted in nuclear weapons development.
Another possibility is that it is some kind of “deliberate disinformation” or “misinformation.” This is the kind of thing that I think people assume the government labs might do, but in my experience, is pretty unusual and pretty unlikely. In general, you have to remember that the national laboratories are pretty, well, boring, when it comes to classified information. They want to be boring in this respect. They are not doing cloak-and-dagger stuff on the regular. They’re scientists and engineers for the most part. These are not James Bond-wannabes. They don’t parachute behind enemy lines to set up palace coups. They are extremely rule-abiding for the most part. There are lots of social and historical reasons for this (again, my book goes into the historical ones — the anxiety about “nuclear secrets” always made the Atomic Energy Commission and its successor organizations very anxious about being accused of being lax about them).
And beyond the institutional culture aspects, the idea that a bunch of engineers at Sandia are going to be using a software package logo to deliberate leak out misinformation, just waiting for someone to notice it, seems a little unlikely to me on the face of it. I mean, really. What is the “operation” here? Who is meant to be “fooled”? Me? You? The North Koreans? It doesn’t feel very realistic.
And one can add to the above the fact that, at least historically, the Atomic Energy Commission and its successor organizations have frowned on disinformation and misinformation for other very practical reasons. If you release a lie, you run the risk of someone noticing it is a lie, which can draw more attention to the reality. And even misinformation/inaccuracy can put “brackets” around the possibilities of truth. The goal of these organizations is to leave a total blank in the areas that they don’t want people to know about, and misinformation/disinformation/inaccuracy is something other than a total blank.
That’s where I’ve ended up, in thinking about what this “means” and what possibly accounts for it. But it’s still bizarre that anyone would allow something that looks so suggestive, even if it is not accurate, to be released as an official product of a national laboratory. It seems like a bad idea, anyway. And yet — I can’t come up with an explanation for this that isn’t one kind of bad idea or another. But I think this is the “most plausible bad idea” of the set.
One last thing. In more recent presentations on the SIERRA Mechanics framework, they changed the diagram somewhat:
The resolution isn’t great, but you can see that the potentially problematic part is much more obscured. But it’s still there, so I don’t think that is really an attempt to draw attention from it, so much as it is an artifact of somewhat careless graphic design. In general, it’s not a great logo by any means — too busy, too complicated, too much information, does not reproduce well at small sizes or low resolutions, etc. — but, as discussed, that is not even close to the most potentially problematic aspect of it!
I saw this and couldn’t resist quickly writing something up about it. That’s all I’ve got. If you’ve got thoughts on it, let me know. And if you haven’t already signed up for it, I am much more active on my other blog, Doomsday Machines, as of late!
I’ve updated this post a few times since I first put it up this afternoon, but just stumbled across something even more helpful. Here’s an image from a 2014 article about computational science at Sandia that looks awfully similar to the one above:
Unlike the others, it comes with a caption: “The multiple components of a nuclear weapon body are highlighted in this intentionally simplified mesh. Each part is comprised of numerous subcomponents, fastened together with screws, nuts, bolts, jar-lid-like fittings and more.” Which is just to say, it is pretty clearly saying that this “thing” is meant to be some kind of representation of a nuclear weapon, albeit “intentionally simplified.” Which doesn’t really solve the mystery — if anything, it just highlights why I still find it so odd that this thing got approved for released at all! Not in the sense that it contains “secrets” — but in the sense that it is just not the kind of image the national labs tend to release.
Someone reminded me of something I had seen years ago: the British nuclear program at Aldermaston, when it has published on its own computer modeling in the past, used a sort of “bomb mockup” that looks far more deliberately “fake” than this Sandia one. I offer this up as what I would think is a more “safe” approach than something that looks, even superficially, like a “real” secondary design:
This is called the MACE (Modal Analysis Correlation Exercise) assembly, and was created by the UK Atomic Weapons Research Establishment in the 1990s to serve as a sort of a Utah Teapot of weapons structural modeling: a benign shape that could be used to test aspects of the code that would nonetheless tell you if the code would work for real weapons assemblies.
Anyway, I’m just surprised the DOE would release any image that gave really any implied graphical structure of a thermonuclear secondary, even if it is clearly schematic and meant to be only somewhat representative. It’s more than they usually allow!
This entry was posted
on Wednesday, September 4th, 2024 at 1:21 pm and is filed under Redactions.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Citation: Alex Wellerstein, “Did Sandia use a thermonuclear secondary in a product logo?,” Restricted Data: A Nuclear History Blog, September 4, 2024, accessed September 8, 2024, https://blog.nuclearsecrecy.com/2024/09/04/did-sandia-use-a-thermonuclear-secondary-in-a-product-logo/.
...
Read the original on blog.nuclearsecrecy.com »
2M users but no money in the bank. Tough times 😔
Find the post interesting or useful?
Share it around and have others benefit too!
Update: This post went somewhat viral beyond the Exercism community. Thanks to everyone who’s offered wishes of support and to the hundreds who have donated in response. I added a little more context and clarified a few things in a Hacker News comment.
Last week we hit the huge milestone of two million users. Within a few hours, we also hit 45 million exercise submissions.
A day later, I paid the final payroll for me, Erik and Aron, and our bank account reduced down to the point we can’t afford to pay another.
I think this sums up Exercism’s story pretty well. Over 1,200 people per day sign up to Exercism. Tens of thousands solve exercises each day. But we don’t have enough money to continue to work on the platform.
We’ve tried a lot of things to change that. We’ve spoken to hundreds of funders and companies, but Exercism isn’t the right fit for their support. It doesn’t fit a niche that makes sense for them. By serving people everywhere, it seems we don’t serve a narrow enough demographic that we align to funders’ often narrow missions!
The one area we have had some promising success is in advertising on the site. But the effort it takes to find advertisers and manage them, and my general desire not to flood Exercism with adverts, has meant that I feel this isn’t a very sustainable strategy.
I think it’s fair to say that at this stage I’ve lost faith in the nonprofit business model working in a way that allows Exercism to reach any of its potential. Keeping something free for everyone relies on either the user being the product, or on significant donations, and without either, it’s very hard to grow.
Probably the hardest thing about the situation right now, is that we can no longer afford to pay Erik, so he’s leaving as an employee at the end of this week.
Erik has been an absolute critical part of Exercism’s growth and success over the last few years. He’s also been a wonderful colleague and friend, and I’ll really miss working alongside him. It goes without saying that I’m incredibly grateful to Erik for all his hard work and support. And I know many of you will feel the same (if so, please reach out and tell him!)
Erik’s a die-hard Exercism fan, and he’s going to continue as a senior maintainer of a few tracks, and he’ll hold onto his super-admin privileges, but the plethora of hidden (and often a bit boring) things that he does day-to-day need to get spread across the organisation.
The one key thing we’re enforcing is that every PR in a live Exercism repository should get a review before it can be merged (with only one exception outlined below). This has generally been the case anyway for a long time, but there are places where it’s fallen through the cracks, so we’ve now scripted things to ensure this is always the case.
To do this, we’ve come up with a new classification system for repos, and specific rules for each type:
maintained: A repo that has multiple maintainers. All PRs require reviews from a track maintainer.
maintained-solitary: A repo that has one maintainer. A new cross-track-maintainers team will get pinged to review all PRs.
unmaintained: A repo that has no maintainers. The cross-track-maintainers team will get pinged here too.
maintained-autonomous: A repo where all maintainers are also in the cross-track-maintainer team. This is the exception, where they can merge their own PRs.
wip-track: An unlaunched track. As it’s not “live” yet, it doesn’t have restrictions.
We’ve created two new GitHub teams that enforce this.
@exercism/guardians: A team to check the safety of PRs to tooling repositories (test runners, analyzers, etc). Made up of a few longstanding polyglots.
@exercism/cross-track-maintainers: A new team made up of longstanding polyglots who are active on the site on a day-to-day basis, and who have the same level of reviewing-pedanticism that I do (ie they’re not more strict or more flexible than me). This is important, as I want a consistent, responsive experience from this team.
Both teams are invite-only. I’ll review them sporadically.
We’ve also invited new maintainers and “pruned” a lot of inactive maintainers as part of this. To those people who have been removed - thank you for all you’ve done, and please know you’re very welcome back if you find the time/desire to contribute in earnest to Exercism again!
So this has all been a bit gloom and doom so far. Things don’t always go as you hope in life, but you have to make lemonade from the lemons!
Right now, we have about 800 monthly donors and about $7,500 in monthly donations. That covers our server costs pretty much exactly. So if you’re donating right now, thank you. You are literally keeping our servers on. Our donor base is generally quite stable, so I’m not too worried about Exercism’s existential prospects.
We also have an amazing community, maintainer team, and group of mentors who keep adding new exercises (and tracks!), helping students, and numerous other things. Exercism has probably never been healthier as an organisation. It’s growing faster than ever, more people are using it than ever, and I think the product and educational experience is better than ever. So I’m still deeply dedicated to growing and nurturing Exercism.
For the last few months, I’ve been working on a new educational product teaching coding fundamentals that I’m going to launch in 2025. 96% of people who try to learn coding give up - which I find unacceptable, so I’m aiming to change that. My plan is to give beginners a rock-solid base, then funnel them into Exercism. I’m creating a new for-profit company for the new company, and going to use proceeds from that to keep Exercism growing. I’ve raised a little investment for this, which means I can continue to pay Aron’s salary, so he’ll be staying around, working on that with me, and tweaking Exercism as needed.
I’m also planning (probably 90% certain) of running a dedicated learn-to-code course from Jan-March 2025, where I can test out some of what we’ve been building, and I can get my hands dirty working with the students who existing platforms don’t serve. So keep out for an announcement about this soon.
I’m exploring launching a basic version of Exercism Teams, as a way of making some extra revenue. There’s a forum post here where you can leave thoughts. I’d really appreciate any you have!
But first, I need a breather!
I’ll be taking the next two weeks off, unplugging and recovering a little.
Thanks for all your support - emotional and financial. Exercism’s community is phenomenal and I’m deeply grateful to everyone involved in the project.
More from our blog
Thank you everyone!
A reflection on #12in23 from someone who completed it
...
Read the original on exercism.org »
By WitherOrNot
Edited by May, Lyssa, & echnobas
In our ongoing work to bypass Windows licensing checks, we occasionally stumble upon bugs that we choose to keep secret. This decision allows us to preserve potential future activation methods by avoiding bug fixes, while also giving us valuable tools for testing or developing new methods.
One such discovery, which we’ve named “Keyhole”, turned out to be a highly effective DRM bypass. It gave users the ability to license any Microsoft Store app or any modern Windows edition with ease.
Following the disclosure of CVE-2024-38184 by Cisco TALOS, we have decided to share our findings on Keyhole, which we independently uncovered around the same time it was reported to Microsoft.
To understand this exploit, we must first understand CLiP, the Client Licensing Platform. This system was introduced with Windows 10, primarily as a way to implement DRM for Microsoft Store apps, and integrated with Windows activation, allowing users to buy digital licenses for Windows on the Microsoft Store.
CLiP is comprised of a few different main binaries within Windows:
* clipc.dll - API used by applications to interact with CLiP
* clipwinrt.dll - Similar to clipc.dll but for UWP applications utilizing Windows Runtime.
Whenever a CLiP-licensed app is installed, a signed XML file containing the license information is sent to clipsvc.dll; once the XML signature is verified, the XML data is stored in ClipSVC’s “token store” at %PROGRAMDATA%\Microsoft\Windows\ClipSVC\tokens.dat.
The signed license block is then extracted from the SPLicenseBlock tag and sent to clipsp.sys for verification. After verification, the license block is deposited in the CLiP license store at HKLM\SYSTEM\CurrentControlSet\Control\{7746D80F-97E0-4E26-9543-26B41FC22F79}. From there, clipsp.sys can then re-validate the license in the future if an app requests it using the CLiP API.
As designed, this system forms a rather strong chain-of-trust that transmits only signed data from usermode applications all the way to the kernel, making it seemingly difficult to tamper with. As we will see soon, however, this is not at all the case.
So far, one binary failed to receive any mention: clipup.exe. This is because it isn’t notable when talking about Keyhole itself. However, it holds the key to messing with CLiP:
Yes, literally. A valid ECDSA key to sign XML licenses is stored in unobfuscated form, allowing anyone to very easily sign or resign XML licenses. This key is normally meant to sign temporary licenses sent to the Microsoft store to get digital licenses, but ClipSvc will happily accept it for app licenses as well.
This allows us to bypass ClipSvc’s gatekeeping and effectively send any license blocks we want straight to ClipSp. With this, we entirely bypass the usermode level of the chain-of-trust, and now all that’s left is to try and trick ClipSp.
ClipSp, from our analysis, is not a very well-written driver. It’s full of copy-pasted code (from where will be shown soon), and seems to be rife with odd choices and compromises. In other words, it’s a perfect environment for someone looking for a bypass. There’s only one big issue: most of the interesting driver code is hidden using Microsoft’s proprietary obfuscator, known as Warbird. In order to find and understand it, we need to “unpack” it, a.k.a. undoing the obfuscation. Luckily, this is rather straightforward thanks to some symbols for clipsp.sys that were available on Microsoft’s servers.
Similar to how Warbird works in user-mode programs, ClipSp wraps any calls to obfuscated code with an decryption and encryption function, as shown below:
So, if we can manually run these decryption functions, we could access all of the hidden code. Luckily, this is quite simple to do based on a method by KiFilterFiberContext, and with it, we are now able to finally find some bugs.
License blocks, mentioned previously, are what actually hold the important license information in CLiP. Their format is well-documented and can store many kinds of data, so we figured they were a good place to start looking for bugs.
License blocks hold their data in a tag-length-value (TLV) format, where several smaller blocks are stored together with each holding values for their data type, the length of their data, and the data itself. For example, the TLV block highlighted below has a type of 0xC9 (License Information), a length of 0xA (10 bytes), and 10 bytes of data.
At the very end of a license block, there will always be a signature block, with a type of 0xCC. This block holds the signature of all the data before it, as well as indicating which key it was signed with. And of course, since it sits after all the data being signed, there’s no way to alter any of it… right?
In the middle of experimenting with this data format, one of our members, May, had a very simple question. If the signature block signs all the data before it, what happens to the data put after it?
Above, you can see a license block for Minecraft Bedrock edition with some new data placed after it (highlighted), containing blocks copied from a Windows license. What happens if we try to install such a license?
As it turns out, data after the signature block isnt checked at all… and it can even override data that came before it. Whenever two blocks of the same type are stored together, the last one overrides all the others before it. So, if we want to change any license data, we can just make a block for it and put it after the signature block!
This method lets us make licenses for anything sold on the Microsoft Store, including Windows, from any other Microsoft Store license. And since there are so many free apps with licenses, we now had the ability to make as many as we wanted for whatever we wanted. This bug essentially punched a hole straight through CLiP’s DRM, so we decided to name it “Keyhole”.
There is only one catch: licenses that are bound to a specific device, known as “device-locked” licenses, cannot be made from device-unlocked licenses. Since Windows digital licenses are device-locked, this meant that we needed to make them from device-locked app licenses. Luckily, many apps, including games like Roblox fit this criteria.
The steps to make any Windows license you want were now dead simple. First, install an app with a device-locked license, like Roblox.
Then, using a HTTPS traffic capture tool like Fiddler, intercept the license that comes from https://licensing.mp.microsoft.com/v7.0/licenses/content.
Decode the license, then extract its license block.
Now, add whatever new data you need to make a new license.
Then, we just package our license block into a new XML file, sign the XML, and copy it into the folder C:\ProgramData\Microsoft\Windows\ClipSVC\Install\Migration.
Finally, we get ClipSvc to install our license, either by restarting it, or with the command clipup -p.
When we check our activation status, Windows is now permanently activated.
With this, we were able to do things that were previously impossible, like activating Enterprise LTSC with a digital license, or even activating a legitimate KMS server with a generic key:
From here, it’s pretty easy to see that this simple bug completely annihilates CLiP’s DRM system.
Having found this bug, we were quite happy that CLiP was now effectively dead. This happiness didn’t last very long, though, as we recently found a vulnerability report from Cisco TALOS that reported this exact bug. It was reported to Microsoft on April 8, right around when we first found it.
This raises a question though: why was a DRM bug reported as a security vulnerability? At first, CLiP licenses don’t seem to have anything to do with exploitation, which caused us to think the bug had been reported for no reason other than to fix Microsoft’s DRM. However, Keyhole can be used as an entry point for more serious bugs in ClipSp, which prompted TALOS to make it part of their disclosure.
As for the fix itself, it’s rather straightforward. As shown below, the current license block parser code immediately exits after encountering a signature block. This prevents it from processing blocks after the signature, completely patching Keyhole.
After mourning the loss of our beloved exploit, we decided that it would only be fair to publicize our own discoveries on CLiP. So, we’ve released the code to generate Keyhole licenses and our collection of CLiP binaries with symbols for easier analysis. We invite you to go forth and discover more funny things in CLiP! (and report them to us instead of MS)
I mentioned that ClipSp’s buggy code was copy-pasted, but from where? Well, the “SP” part just happens to reference a certain Microsoft game console: the Xbox One!
The Xbox One contains a chip known as the SP, or “secure processor”, based on the TPMs in modern PCs. The main job of the SP is to enforce code signing, but it also handles license verification. During our research on Keyhole, we found many associations between CLiP and the Xbox One, and began wondering how they were actually related. While looking through some leaked source code, we stumbled upon this:
Well, this looks oddly familiar…
And there’s the same bug that’s in CLiP, but in Xbox code. In fact, we weren’t too surprised to find this, as we found that almost all of CLiP, from the XML format of the licenses to the TLV-based license blocks, is mostly copy-pasted straight from the Xbox One’s DRM system.
So, to those with a console that’s been collaterally damaged, I wonder what happens if you mess with those funny-looking XML files in S:\clip ;)
The research covered in this blogpost was made possible by the following people/groups:
...
Read the original on massgrave.dev »
To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".
10HN is also available as an iOS App
If you visit 10HN only rarely, check out the the best articles from the past week.
If you like 10HN please leave feedback and share
Visit pancik.com for more.