The J-57 afterburner engine appeared in many airplanes of notable make, including the F-101, -102, and -103. This USAF training film shows the parts of the J-57, explains the complex process by which the engine produces thrust, and describes some maintenance and troubleshooting procedures.
The name of this game is high performance. Precision thrust requires careful rigging of the engine’s fuel control linkage through a process called trimming. Here, the engine fuel control is adjusted with regard to several different RPM readings as prescribed in the manual.
One of the worst things that can happen to a J-57 is known as overtemping. This refers to high EGT, or exhaust gas temperature. If EGT is too high, the air-fuel ratio is not ideal. Troubleshooting a case of high EGT should begin with a check of the lines and the anti-icing valve. If the lines are good and the valve is closed, the instruments should be checked for accuracy. If they’re okay, then it’s time for a pre-trimming inspection.
In addition to EGT, engine performance is judged by RPM and PP7, the turbine discharge pressure. If RPM and PP7 are within spec and the EGT is still high, the engine must be pulled. It should be inspected for leaks and hot spots, and the seals should be examined thoroughly for cracks and burns. The cause for high EGT may be just one thing, or it could be several small problems. This film encourages the user to RTFM, which we think is great advice in general.
We covered [wk057] and his Tesla Model S battery teardown back in September. Since then we had some time to catch up with him, and ask a few questions.
You’ve mentioned that you have a (non hacked) Tesla Model S. What do you think of the car?
It’s the best car I’ve ever driven or owned, period. Not to get too into it, but, I love it. I’ve put almost 20,000 miles on it already in under a year and I have no real complaints. Software feature requests… but no complaints. After almost a year, multiple 1700-miles-in-a-weekend trips, and an overall great experience… I can never go back to a gas vehicle after this. It would be like going back to horses and buggies.
A salvage Tesla Lithium battery had to be expensive compared to a Lead Acid setup. What made you go with the Tesla?
Actually, if you consider that the Model S battery is already pre-setup as a high-capacity pack, contains the wiring to do so, and the modules are much more energy and power dense than any lead acid battery bank, it’s actually almost cheaper than a comparable lead acid bank and all the trimmings.
I haven’t officially weighed them, but the modules from the Model S battery are roughly 80 lbs. 80 lbs for a 5.3 kWh battery is around 15 lbs per kWh, which is impressive. For comparison, a decent lead acid battery will have a little over 1 kWh (of low-rate discharge capacity) and weigh almost the same.
Also, the Tesla pack is much more powerful than a lead acid bank of the same capacity.
Generally a lead acid battery bank would have a capacity that would only be realized with slow discharges, so, 1/20C. Much over that and you sacrifice capacity for power. 1/20C for an 85kWh pack is only 4.25kW, barely enough for a central air unit and some lights without losing capacity.
Now the Tesla pack can be discharged (based on how it does so in the vehicle) at up to 3.75C for short periods, and at 1/2C continuously without really affecting the overall capacity of the pack. That means I can run 10x more power than lead acid without a loss in overall charge capacity. Leads to a much more flexible battery solution since the loads will, in reality, always be so low that this will not even come into play with the Tesla pack, but would almost always be a factor with lead acid.
Charging is also somewhat better with the Tesla battery. Charge a lead acid battery at a 1/2C and it will boil. Charge the Tesla pack at 1/2C (42kW) and it might warm up a few degrees. Oh, and the charging losses at high rates are much less than lead acid also.
Overall, without continuing to yack about the technical aspects, it’s just a much better battery, takes up less space, weighs less, and has more power available.
There are likely decent arguments for other solutions, but the rest aside, this one won out because it was definitely more interesting.
Click past the break to read the rest of our interview with [wk057]!
[Ryan] a.k.a. [1o57] comes from an age before anyone could ask a question, pull out their smartphone, and instantly receive an answer from the great Google mind. He thinks there’s something we have lost with our new portable cybernetic brains – the opportunity to ask a question, think about it, review what we already know, and reason out a solution. There’s a lot to be said about solving a problem all by yourself, and there’s nothing to compare to the ‘ah-ha’ moment that comes with it.
[1o57] started his Mystery Challenges at DEFCON purely by accident; he had won the TCP/IP embedded device competition one year, and the next year was looking to claim his title again. The head of the TCP/IP embedded competition had resigned from his role, and through a few emails, [1o57] took on the role himself. There was a miscommunication, though, and [1o57] was scheduled to run the TCP/IP drinking competition. This eventually morphed into a not-totally-official ‘Mystery Challenge’ that caught fire in email threads and IRC channels. Everyone wanted to beat the mystery challenge, and it was up to [1o57] to pull something out of his bag of tricks.
The first Mystery Challenge was a mechanical device with three locks ready to be picked (one was already unlocked), magnets to grab ferrous picks, and only slightly bomb-like in appearance. The next few years featured similar devices with more locks, better puzzles, and were heavy enough to make a few security officials believe [1o57] was going to blow up the Hoover dam.
With a few years of practice, [1o57] is turning crypto puzzles into an art. His DEFCON 22 badge had different lanyards that needed to be arranged to spell out a code. To solve the puzzle, you’ll need to talk to other people, a great way to meet one of [1o57]’s goals of getting all the natural introverts working together.
Oh. This talk has its own crypto challenge, something [1o57] just can’t get out of his blood:
So far nobody has solved the @hackaday 10 year anniversary in-talk-mini-crypto-puzzle-of-doom…("it's only a model")
Sometimes a project has more sensors, buttons, or LEDs than your microcontroller has pins. The PCF8574 is an easy way to add 8 low-speed input or output pins to a microcontroller. A configurable address lets multiple PCF8574s exist on the same bus, so two microcontroller pins can control dozens of IO pins. We’ll show you how to use this chip below.
There’s a train vulnerability making the rounds this week. The research comes from [midwestneil], who first discovered an issue way back in 2012, and tried to raise the alarm.
Turns out you can just hack any train in the USA and take control over the brakes. This is CVE-2025-1727 and it took me 12 years to get this published. This vulnerability is still not patched. Here's the story: https://t.co/MKRFSOa3XY
To understand the problem, we have to first talk about the caboose. The caboose was the last car in the train, served as an office for the conductor, and station for train workers to work out of while tending to the train and watching for problems. Two more important details about the caboose, is that it carried the lighted markers to indicate the end of the train, and was part of the train’s breaking system. In the US, in the 1980s, the caboose was phased out, and replaced with automated End Of Train (EOT) devices.
These devices were used to wirelessly monitor the train’s air brake system, control the Flashing Rear End Device (FRED), and even trigger the brakes in an emergency. Now here’s the security element. How did the cryptography on that wireless signal work in the 1980s? And has it been updated since then?
The only “cryptography” at play in the FRED system is a BCH checksum, which is not an encryption or authentication tool, but an error correction algorithm. And even though another researcher discovered this issue and reported it as far back as 2005, the systems are still using 1980s era wireless systems. Now that CISA and various news outlets have picked on the vulnerability, the Association of American Railroads are finally acknowledging it and beginning to work on upgrading.
Laravel provides the encrypt() and decrypt() functions to make that process easy. The decrypt() function even does the deserialization automatically. … You may be able to see where this is going. If an attacker has the APP_KEY, and can convince a Laravel site to decrypt arbitrary data, there is likely a way to trigger remote code execution through a deserialization attack, particularly if the backend isn’t fully up to date.
So how bad is the issue? By pulling from their records of GitHub, GitGuardian found 10,000 APP_KEYs. 1,300 of which also included URLs, and 400 of those could actually be validated as still in use. The lesson here is once again, when you accidentally push a secret to Github (or anywhere on the public Internet), you must rotate that secret. Just force pushing over your mistake is not enough.
Fake Homebrew
There’s a case to be made that browsers should be blocking advertisements simply for mitigating the security risk that comes along with ads on the web. Case in point is the fake Homebrew install malware. This write-up comes from the security team at Deriv, where a MacOS device triggered the security alarms. The investigation revealed that an employee was trying to install Homebrew, searched for the instructions, and clicked on a sponsored result in the search engine. This led to a legitimate looking GitHub project containing only a readme with a single command to automatically install Homebrew.
The command downloads and runs a script that does indeed install Homebrew. It also prompts for and saves the user’s password, and drops a malware loader. This story has a happy ending, with the company’s security software catching the malware right away. This is yet another example of why it’s foolhardy to run commands from the Internet without knowing exactly what they do. Not to mention, this is exactly the scenario that led to the creation of Workbrew.
SQL Injection
Yes, it’s 2025, and we’re still covering SQL injections. This vulnerability in Fortinet’s Fortiweb Fabric Connector was discovered independently by [0x_shaq] and the folks at WatchTowr. The flaw here is the get_fabric_user_by_token() function, which regrettably appends the given token directly to a SQL query. Hence the Proof of Concept:
GET /api/fabric/device/status HTTP/1.1
Host: 192.168.10.144
Authorization: Bearer 123'//or//'x'='x
And if the simple injection wasn’t enough, the watchTowr write-up manages a direct Remote Code Execution (RCE) from an unauthenticated user, via a SQL query containing an os.system() call. And since MySQL runs as root on these systems, that’s pretty much everything one could ask for.
AI guided AI attacks
The most intriguing story from this week is from [Golan Yosef], describing a vibe-researching session with the Claude LLM. The setup is a Gmail account and the Gmail MCP server to feed spammy emails into Claude desktop, and the Shell MCP server installed on that machine. The goal is to convince Claude to take some malicious action in response to an incoming, unsolicited email. The first attempt failed, and in fact the local Claude install warned [Golan] that the email may be a phishing attack. Where this mildly interesting research takes a really interesting turn, is when he asked Claude if such an attack could ever work.
Claude gave some scenarios where such an attack might succeed, and [Golan] pointed out that each new conversation with Claude is a blank slate. This led to a bizarre exchange where the running instance of Claude would play security researcher, and write emails intended to trick another instance of Claude into doing something it shouldn’t. [Golan] would send the emails to himself, collect the result, and then come back and tell Researcher Claude what happened. It’s quite the bizarre scenario. And it did eventually work. After multiple tries, Claude did write an email that was able to coerce the fresh instance of Claude to manipulate the file system and run calc.exe. This is almost the AI-guided fuzzing that is inevitably going to change security research. It would be interesting to automate the process, so [Golan] didn’t have to do the busywork of shuffling the messages between the two iterations of Claude. I’m confident we’ll cover many more stories in this vein in the future.
Cryptojacking is the technique where a malicious website embeds a crypto miner in the site. And while it was particularly popular in 2017-2019, browser safeguards against blatant cryptojacking put an end to the practice. What c/side researchers discovered is that cryptojacking is still happening, just very quietly.
ZDI has the story of Firefox and a JavaScript Math confusion attack. By manipulating the indexes of arrays and abusing the behavior when integer values wrap-around their max value, malicious code could read and write to memory outside of the allocated array. This was used at Pwn2Own Berlin earlier in the year, and Firefox patched the bug on the very next day. Enjoy!
Homebrew bills itself as the package manager MacOS never had (conveniently ignoring MacPorts) but they leave the PPC crowd criminally under-served, to say nothing of the 68k gang. Enter [that-ben] with MR Browser, a simple utility to fetch software from Macintosh Repository for computers too old to hit up the website.
If you’re not familiar with Macintosh Repository, it is what it says on the tin: a repository of vintage Macintosh software, like Macintosh Garden but apparently less accessible to vintage machines.
MRBrowser sys6 runs nicely on the Macintosh Plus, as you can see.
There are two versions available, depending on the age of your machine. For machines running System 6, the appropriately-named MR Browser sys6 will run on any 68000 Mac in only 157 KB of and MacTCP networking. (So the 128K obviously isn’t going to cut it, but a Plus from ’86 would be fine.)
The other version, called MR Browser 68K, ironically won’t run on the 68000. It needs a newer processor (68020 or newer, up-to and including PPC) and TCP/IP networking. Anything starting from the Macintosh II or newer should be game; it’s looking for System 7.x upto the final release of Mac OS 9, 9.2.2. You’ll want to give it at least 3 MB of RAM, but can squeak by on 1.6 MB if you aren’t using pictures in the chat.
Chat? Yes, perhaps uniquely for a software store, there’s a chat function. That’s not so weird when you consider that this program is meant to be a stand-alone interface for the Macintosh Repository website, which does, indeed, have a chat feature. It beats an uncaring algorithm for software recommendations, that’s for sure. Check it out in action in the demo video below.
Do you feel nostalgia for a childhood novelty toy that had potential but ultimately fell short of its promise? Do you now have the skills to go make a better version of that toy to satisfy your long-held craving? [ExpensivePlasticCrap] does and has set off on a mission to make a better jumping bean.
Jumping beans, the phenomenon on which the novelty of [ExpensivePlasticCrap]’s childhood is based, are technically not beans, and their movement is arguably not a jump — a small hop at best. The trick is that the each not-a-bean has become the home to moth larvae that twitches and rolls on the ground as the larvae thrash about, trying to move their protective shells out of the hot sun.
The novelty bean was a small plastic pill-like capsule with a ball bearing inside what would cause the “bean” to move in unexpected ways as it rolled around. [ExpensivePlasticCrap]’s goal is to make a jumping bean that lives up to its name.
Various solenoids and motors were considered for the motion component of this new and improved bean. Ultimately, it was a small sealed vibrating motor that would be selected to move the bean without getting tangled in what was to become a compact bundle of components.
An ATtiny microcontroller won out over discrete components for the job of switching the motor on and off (once per second), for ease of implementation. Add this along with a MOSFET, battery and charging board for power into a plastic capsule, and the 1 Hz jumping bean was complete.
[ExpensivePlasticCrap] offers some thoughts on how to get more jump out of the design by reducing the weight of the build and giving it a more powerful source of motion.
