🏡

July 17, 2026
1. 🔗 @binaryninja@infosec.exchange Our Firmware Reverse Engineering class is just over a week away! Join us to mastodon
  
  Our Firmware Reverse Engineering class is just over a week away! Join us to learn what's involved in analyzing bare-metal software and how to overcome those challenges! https://shop.binary.ninja/products/fre- july-26
  
  https://youtube.com/shorts/486zHriqGMA
2. 🔗 r/reverseengineering Maintaining the old code of the man who wrote "How To Write Unmaintainable Code" rss
  
  submitted by /u/Odd-Flamingo-6211
  [link] [comments]
3. 🔗 New Music Releases Haken - in a fever dream rss
  Haken - a new release is available:
  - 2026-07-17: in a fever dream (EP)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
4. 🔗 Ampcode News From Agent to Agent rss
  You can now ask your agents in Amp to spawn other agents. In orbs, your local machine [^1], or on any other machine.
  
  They can send messages and files to each other, too.
  
  You can have agents in orbs work on side quests while you continue your work:
```
Spin up an orb thread with what you know about this unrelated bug,
ask it to fix it, then keep working here.
```
  Or fan out work:
```
Run four low-mode threads in parallel to test this flow in Chrome
at four screen sizes and report back with screenshots.
```
  Find and continue old work by pulling in the important files:
```
Pull the files from my abandoned prototype thread into this workspace
and integrate the useful parts into our current approach.
```
  Offload work to another machine:
```
Start a new thread on cloud-dev-box and upload this test matrix
we created. Ask it to run through each row at least 10 times.
```
  Coordinate cross-project work:
```
Spawn an agent in the docs project, send it what it needs to
document this API change, and ask it to report back.
```
  Agents running locally, or in orbs, or anywhere else, and sending messages and files to each other? It's a whole new world.
July 16, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-16 rss
  IDA Plugin Updates on 2026-07-16
  
  New Releases:
  - binsync v5.13.3
  - ida-llm-explainer LLM Explainer v1.7.3
  Activity:
  - binsync
    
    ab66e63b: bump
    
    c56f035c: Fix force-push and sync dispatch, harden decompiler UI lifecycles (#531)
  - capa
    
    0ac88c56: build(deps): bump humanize from 4.15.0 to 4.16.0 (#3123)
    
    684cfc03: build(deps): bump setuptools from 82.0.1 to 83.0.0 (#3122)
    
    1b3d88de: build(deps): bump ida-settings from 3.4.1 to 3.5.1 (#3119)
    
    3718a14a: build(deps): bump pip from 26.1 to 26.1.2 (#3124)
  - ffxiv_bossmod
    
    ed167baf: some delay fixes
    
    33e0c25f: better pyretic support
    
    b4da7764: mnk pyretic handling
    
    7b87bc50: more p1 movement
  - ida-ios-helper
    
    3cca707d: Merge pull request #23 from FloofyPlasma/feat/objc_fast_enum
  - ida-llm-explainer
    
    4ca175e0: v1.7.3: inside-out recursive explain, caller call-site snippets, call…
  - Luc-Nhan
    
    bf1faa64: chore(release): bump version to 1.11.1
    
    4c65cf84: Merge branch 'feat/remove-rikugan-md-legacy'
    
    56ef1e85: docs(memory): refine spec — binding-state guard retention, test_manag…
    
    1e6b5c2f: docs(memory): document central MEMORY.md cutover, remove RIKUGAN.md refs
    
    9e757889: test(memory): remove obsolete legacy and activation-gate tests
    
    981eb4aa: refactor(memory): remove legacy importer and clean docstrings
    
    74da5983: docs(memory): update research mode prompt to reference MEMORY.md
    
    3f33ef89: refactor(memory): persist plans via central memory service
    
    99bb383d: refactor(memory): remove legacy RIKUGAN.md save/read paths
    
    0390cd9f: refactor(memory): remove legacy RIKUGAN.md loading from system prompt
    
    37f4b27b: refactor(memory): always wire central memory in controller
    
    eb85eedb: test(memory): remove dark-mode tests and flag references
    
    2cde3190: refactor(memory): remove dark-mode branches from MemoryWorkspaceManager
    
    bd3f9f27: refactor(memory): remove dark-scaffolding config flags
    
    ca3ae64e: docs(memory): implementation plan for RIKUGAN.md legacy removal
    
    0158edb8: docs(memory): expand spec after self-review (tests, identity-failure,…
2. 🔗 r/Harrogate Places to stay in November? rss
  
  Hi Harrowgate.
  
  I'm going to be travelling to your town for three nights in November to attend my first Thought Bubble comics festival. I'm very excited but have ended up getting accommodation far too late. Does anyone have any recommendations of cheap-reasonably priced places from the 13-16th? Not looking for much just a place to sleep (Hopefully shower)
  
  submitted by /u/ComprehensiveLaw2117
  [link] [comments]
3. 🔗 earendil-works/pi v0.80.10 release
  New Features
  - Kimi Coding thinking compatibility — Kimi Coding models now use adaptive thinking correctly; K3 exposes its supported max level and supports replaying empty-signature thinking blocks. See Kimi For Coding setup and Model Options.
  Fixed
  - Fixed inherited Kimi Coding requests to use Anthropic adaptive thinking effort without token budgets, and enabled empty thinking signatures for K3 and kimi-for-coding.
  - Fixed inherited Kimi K3 pricing metadata for Moonshot AI and Moonshot AI China.
  - Fixed inherited Kimi Coding K3 thinking-level metadata to expose only the supported max level (#6737).
  - Fixed inherited catalog generation restoring xAI models removed in 0.80.9 (#6736).
4. 🔗 MetaBrainz Picard 3 beta 7 released rss
  Today, we have released MusicBrainz Picard 3 beta 7. This new versions brings several fixes over the last beta 5 (yes, we have skipped a beta number again), but also improvements and some new features. Among the highlights are:
  - Option profiles can now be exported and imported as TOML files. This makes sharing options much easier. We are excited to see how this will be used by you all.
  - Artist name standardization can now be set to one of three values: no standardization, standardizing only variations of the artist name ("Beatles" vs. "The Beatles") or standardizing also actual artist name changes ("Diddy", who previously performed under the names “P. Diddy” and “Puff Daddy”). Standardizing name variations is the new default setting. See also the documentation.
  - Plugins can now implement custom CD ripper log file support, and there is built-in support for Cyanrip log files.
  - Picard can now much better handles wrongly or differently encoded filenames when loading files.
  - The setup wizard got some improvements, allowing users to configure their update notification settings for the app and plugins. Also the setup wizard can now be started again from the help menu. This is not yet the final version of the wizard, but it's getting closer.
  - The User Guide was updated to document the latest changes.
  Download links and a detailed list of changes since Picard 3 beta 5 are available below. For a more detailed overview of what is new in Picard 3 please see the previous blog post Picard 3 Alpha Release.
  
  While we have all the major features implemented and with the latest bug fixes we are confident in the current code, this is still a pre-release and there might be bugs. If you use this, do so with care, backup your files and please report any issues you encounter.
  
  Some of the changes are also backward incompatible, hence we recommend you make a backup of your Picard.ini config file before trying the beta version. You can do so in Picard’s Options under Advanced > Maintenance.
  
  What’s new?
  
  Bugfixes
  - PICARD-3330 - Config upgrade hooks do not update profile overrides for value transforms
  - PICARD-3331 - Encoding error when saving file metadata
  - PICARD-3332 - Enums are not stored as values in option profiles
  - PICARD-3333 - Cover art provider plugin option pages cannot have profile highlights
  - PICARD-3334 - Enabling track title translation always uses the recording title
  - PICARD-3336 - Can not go back to main app window after viewing Picard > About Picard
  - PICARD-3338 - PICARD_PLUGIN_REGISTRY_URL env var ignored when official registry cache exists
  - PICARD-3339 - Plugin boolean options show up in quick settings, but are not usable as such
  - PICARD-3342 - Profile highlights broken if same option name is used by different plugins
  - PICARD-3344 - Crash when refreshing collections list
  - PICARD-3345 - Exception when reading SYLT tag with newline
  New Features
  - PICARD-30 - Add _artistcomment and _albumartistcomment variables
  - PICARD-3328 - Support TOML-based exportable/importable profiles
  - PICARD-3346 - Cyanrip log support
  Improvements
  - PICARD-2673 - Standardize artist name variations by default
  - PICARD-2845 - Add wizard illustration to first run information dialog and setup wizard
  - PICARD-2999 - Automatic update check should be opt-in
  - PICARD-3335 - Replace picard-plugins with picard-cli subcommand architecture
  - PICARD-3337 - Add a picard-cli plugins compile-ui command
  - PICARD-3343 - Allow starting the setup wizard again from the help menu
  - PICARD-3347 - Add a plugin v3 extension point to register a custom CD ripping log parser
  Download
  
  We appreciate your interest in trying this new version. Use with care, backup your files and please use theMetaBrainz community forums and the ticket system to give feedback and report bugs.
  
  For Windows and macOS you can download the beta version from the Picard download page. Linux users can run from source or try the beta channel of the Picard snap package.
  
  Picard is free software and the source code is available on GitHub.
  
  Acknowledgements
  
  Code contributions by Laurent Monin and Philipp Wolfer.
  Translations were updated by Marc Riera (Catalan), rez00 (French) and zatto13 (Japanese). Documentation updates by Bob Swift, Laurent Monin and Philipp Wolfer.
5. 🔗 Simon Willison Kimi K3, and what we can still learn from the pelican benchmark rss
  Chinese AI lab Moonshot AI announced Kimi K3 this morning, describing it as their "most capable model to date, with 2.8 trillion parameters". It's currently available via their website and API, but an open weight release is promised "by July 27, 2026".
  
  Moonshot are calling this the first "open 3T-class model" (I guess they're rounding 2.8 trillion up to 3 trillion), taking the crown from DeepSeek's 1.6T v4 Pro. Their self-reported benchmarks have K3 mostly beating Claude Opus 4.8 max and GPT-5.5 high, while losing out to Claude Fable 5 and GPT-5.6 Sol.
  
  A few highlights from the Artificial Analysis report on the model:
  - "On our private long-horizon knowledge work evaluation, Kimi K3 reaches an overall Elo of 1547, +732 points from Kimi K2.6 and behind only Claude Fable 5."
  - "Cost per task ($0.94) is similar to GPT-5.6 Sol ($1.04), ~1/2 the price of Opus 4.8 ($1.80) and higher than open weights peers"
  - "Kimi K3’s token usage on the Artificial Analysis Intelligence Index decreased significantly, using 21% fewer output tokens than K2.6."
  The model is also now the leading model on Arena.ai's Frontend Code arena, surpassing even Claude Fable 5.
  
  The new model is notable for the pricing: $3/million input tokens and $15/million output tokens, putting it at the same level as Anthropic's Claude Sonnet series and making it the most expensive model released by a Chinese AI lab to date. This is a significant increase on their earlier models such as Kimi K2.6 at $0.95/$4. 2.8 trillion parameters is also more than twice the size of that 1T model.
  
  But how does it pelican?
  
  I used OpenRouter (to avoid signing up for a Moonshot API key) with the llm-openrouter plugin to generate an SVG of a pelican riding a bicycle:
```
llm -m openrouter/moonshotai/kimi-k3 'Generate an SVG of a pelican riding a bicycle'
```
  Here's the transcript. It looks like this:
  
  That pelican took 95 input tokens and 16,658 output tokens (13,241 were reasoning tokens), for a total cost of 25 cents!
  
  Since K3 accepts image input I ran it against that rendered SVG above (with my alt text prompt) and got back (for 0.6 cents):
  
  Cartoon illustration of a white pelican wearing a red scarf, riding a red bicycle along a gray road with white dashed lines; the pelican has a large orange beak and webbed orange feet pedaling, with white motion lines behind it; the background shows a light blue sky with white clouds, a yellow sun, two small black birds in flight, and green grass with tiny white flowers in the foreground
  
  What can we learn from the pelican?
  
  My Generate an SVG of a pelican riding a bicycle test is 21 months old now. It was never a particularly great benchmark. It started out as a joke on how absurdly difficult it is to compare these models, but then for the first year it turned out to have a surprising correlation to how good the models actually were.
  
  That connection has been mostly severed now. The GPT-5.6 and Claude Fable 5 pelicans are outclassed by GLM-5.2, and much as I love GLM I don't think that's a Fable-class model.
  
  (I'm still not convinced that labs are training for the benchmark - if they were, I'd expect much better results. There's a chance that Gemini has optimized for any combination of an animal on a vehicle though!)
  
  The biggest limitation of the pelican is that it doesn't touch at all on the thing that matters most for today's model: agentic tool calling and the ability to operate tools reliably as conversations grow in length.
  
  So don't go using pelicans to compare models!
  
  All of that said, I still get a decent amount of value out of running the benchmark myself.
  
  Firstly, it's a forcing function for actually trying the model. If I show you a pelican, that means I've managed to run a prompt through it. If the model has an official API I'll use that, if it's open weight (and small enough to fit a 128GB M5 MacBook Pro) I'll try running it on my own machine, usually via llama.cpp or LM Studio or Ollama. I'll frequently use OpenRouter since that usually provides a proxy to an official API without me needing a new API key.
  
  Most of my pelicans are generated using my LLM CLI tool, which helps encourage me to ensure the latest models are supported by that (via one of its plugins).
  
  More importantly though, even the act of a single prompt to "Generate an SVG of a pelican riding a bicycle" can reveal interesting model characteristics.
  
  Consider the result for Kimi K3 today. Running those simple prompts helped emphasize several points about the model.
  1. It only has one reasoning effort right now, "max" - and it shows. The model consumed 13,241 reasoning tokens to output 3,417 tokens of response. This is expensive - the pelican cost 25 cents!
  2. How does the prompt "Generate an SVG of a pelican riding a bicycle" add up to 95 input tokens? OpenAI's tokenizer counts 10, Anthropic's counts 10 for Opus 4.6, 30 for Opus 4.7 and 25 for Sonnet 5/Fable 5. Prompting "hi" to Kimi K3 counted 86 tokens, suggesting there may be an 85 token hidden system prompt. It refused to leak it though.
  3. Vision works well: the alt text it generated is very good.
  K3 currently only has one thinking effort level, but I've been deriving quite a bit of value recently from running the same pelican prompt through different effort levels to get a quick idea for what impact those have. Here's my matrix for the GPT-5.6 model family, for example.
  
  Really though the main things I gain from the pelican test are:
  1. It's a "hello world" exercise for prompting a model
  2. A rough cost and reasoning estimate for a simple task
  3. Confirmation that the model can output valid SVG and has a basic idea of geometry and spatial awareness. This is a much bigger deal for the smaller models that run on my laptop.
  4. It's still interesting to compare pelicans between releases in the same model family. K3's pelican is a notable improvement from Kimi 2.5.
  5. It's something I can share that demonstrates I've tried it. Plus a comment with a pelican in it is kind of a tradition on Hacker News at this point, any time I'm late I get comments asking where it is!
  You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.
6. 🔗 earendil-works/pi v0.80.9 release
  New Features
  - Kimi K3 and deferred tool loading — Use Kimi K3 across built-in providers, including progressive extension tool activation through Kimi’s native protocol. See Dynamic Tool Loading, OpenAI Compatibility, and the kimi-deferred-tools.ts example.
  Added
  - Added inherited Kimi K3 support for Kimi Coding, Moonshot AI, Moonshot AI China, OpenRouter, and Vercel AI Gateway.
  - Added Kimi deferred tool loading for extension-driven tool activation. See Dynamic Tool Loading, OpenAI Compatibility, and the kimi-deferred-tools.ts example.
  Changed
  - Changed xAI login to use a prefilled device-authorization link labeled “Sign in with SuperGrok or X Premium,” and changed the default xAI model to Grok 4.5 (#6734 by @Jaaneek).
  Fixed
  - Fixed inherited Kimi K3 output limits for Vercel AI Gateway and OpenRouter models.
  - Fixed cloning or forking a session before its first assistant response to explain that the session must be saved first.
  Removed
  - Removed Grok 3, Grok 3 Fast, Grok 4.20 variants, and Grok Code Fast 1 from the built-in xAI model catalog (#6734 by @Jaaneek).
7. 🔗 The Pragmatic Engineer The Pulse: What can we learn from Bun’s rapid Rust rewrite with AI? rss
  Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics of last week 's The Pulse issue . Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .
  
  Last week in San Francisco, I met Jarred Sumner, creator of JavaScript runtime, Bun, and was keen to learn more about the rewrite of Bun from Zig to Rust. But at the time, Jarred didn't want to say too much, as the tool used for the migration, Fable, was out of action due to the US government imposing export controls.
  
  Jarred and I at Anthropic 's HQ, last week
  
  Fortunately, the situation is now resolved and Fable is available globally, and Jarred has published a detailed post about the project. Before we get into the migration, some context:
  
  Bun is a complex project, with lots of production software depending on it. Bun itself does many things:
  - JavaScript, TypeScript and CSS transpiling, minifying and bundling
  - A test runner
  - A package manager (npm-compatible)
  - Other things: module resolution, a WebSocket client, Node.js implementations and many modules
  Today, Bun has 22 million monthly downloads, and software like Claude Code and OpenCode depend on it, while hosting providers like Vercel, Railway and DigitalOcean do first-party support for Bun.
  
  Why a rewrite?
  
  Zig is not a memory safe language, and memory-related bugs occurred continuously.**** Jarred lists memory-related bugs in the latest version of Bun: memory leaks, crashes due to memory issues, heap-out-of-bounds writes, and so on. This was after the Bun team patched the Zig compiler to reduce memory-related issues, and put end-to-end memory leak tests in place. As Jarred says:
  
  "Our bugfix list felt bad and I was tired of going to sleep worrying about crashes in Bun. I don't blame Zig for that - other users of Zig don't have the bugs we had, and mixing GC with manually-managed memory is an uncommon enough thing for software to need that no language really designs for it. (...)
  
  For Bun, correctly handling the lifetimes of garbage-collected values and manually-managed values has been a major source of stability issues - most often small memory leaks and occasionally crashes. Every memory allocation has to be meticulously reviewed. Where do these bytes get freed? How do we ensure it only gets freed once? Did we check for JavaScript exceptions properly? Is this garbage-collected pointer visible to the conservative stack scanner? Is this garbage collected memory or manually managed memory?"
  
  Moving to a memory-safe, yet performant language could eliminate such errors, and Rust is one such language that fitted the bill. Jarred:
  
  "A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide."
  
  However, doing a full rewrite on Rust has always been a terrible idea. Or at least, it used to be, because of how unbearably long it would have taken:
  
  There are two problems with rewrites: they take too long, and they take waaaay too long. A dev who has done rewrites probably knows how things tend to go:
  1. Make an educated guess about how long it will take; say, nine months.
  2. Nine months later, there's still another ~6 months to go because new functionality is added to the original codebase, and now that new functionality needs to be added in!
  3. By 15 months in, there's still months left to go for the same reason!
  4. In the end, you manage to mandate a "feature freeze" for two months and finish the rewrite in ~18 months, if lucky. The original nine-month estimate can end up taking 2+ years.
  Jarred likened rewriting Bun in Zig to this:
  
  "Historically, rewrites are a terrible idea. Excluding comments, Bun is 535,496 lines of Zig.
  
  A rewrite in another language would take a small team of engineers a full year.
  
  A year of zero user-facing impact is not a realistic option we could consider. So, enforcement through code-style to fix stability issues was our best bet, and was our plan when we added Rust-inspired smart pointers to Bun's codebase.
  
  But honestly, I didn't want to do it. Homegrown smart pointers offer worse ergonomics than Rust, with none of the guarantees.
  
  What if, instead, I spend a week testing if Anthropic's new model [Fable] can rewrite Bun in Rust?"
  
  Rewriting Bun with Fable
  
  Unsurprisingly, the rewrite was not as simple as typing a prompt like: "Claude, rewrite Bun in Rust. Make zero mistakes." Instead, this is how Jarred did it:
  
  Step #1: Prep work. Three hours of intense prep work with Claude, explained**** Jarred:
  
  "Before writing any code, I spent about 3 hours talking to Claude about how to map patterns from our Zig codebase closely to Rust. Claude serialized this discussion into a PORTING.md document, which ended up on Hacker News [as the Zig -> Rust porting guide]"
  
  This guide is a 600-line file with instructions like:
  
  Ground rules:
  - No tokio , rayon , hyper , async-trait , futures. No std::fs, std::net, std::process. Bun owns its event loop and syscalls. (Rust core/std slice, iter, mem, fmt, and core::ffi are fine -- only the I/O-touching modules are banned.)
  - No async fn. Everything is callbacks + state machines, same as the Zig.
  - Borrow-checker reshaping is allowed. When matching Zig flow yields overlapping &mut, capture the needed scalar (.len(), index) into a local, drop the borrow, then re-borrow. Do NOT reach for raw pointers just to silence borrowck; leave // PORT NOTE: reshaped for borrowck so Phase B diff readers aren't confused.
  It's a series of instructions that makes sense to someone who's expert in Rust.If you want to learn more, we cover Rust basics and why Rust is different, with Alice Ryhl.
  
  Step #2: Trial run + adversarial review. Asking Claude to rewrite three files out of 1,448 total number of files. After the rewrite, Jarred ran two separate adversarial reviews with Claude to critique the result, in separate sessions than the one that Claude made the changes in.
  
  Step #3: split up the work across 64 AI agents. Jarred split up the job so that agents worked on files independent from one another, in parallel.
  
  Step #4: iron out issues with the run (~1 day). When Jarred attempted to run all this, agents kept getting in each other's way:
  
  "I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other! And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.
  
  So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.
  
  Then, Claude resumed the workflows. And it was working! Too slowly, so I split it into just 4 workflow shards each with their own worktree (4 worktrees total), each running 16 Claudes committing and pushing files."
  
  Step #5: have it run and wait ~2 days. The parallel agents went to work, and completed the rewrite of 535,496 lines of Zig code over the course of two days. Each commit was checked by two adversarial reviews, before being committed.
  
  Step #7: fix ~1,600 compiler errors (~12 hours). The rewrite was completed, but nothing compiled. Going crate-by-crate ('crate' is Rust's concept of a top-level compilation unit), Jarred had Claude fix compiler errors. This alone would be a herculean task for an engineer, but not for Claude :
  
  "Fixing the cyclical dependencies revealed about 16,000 compiler errors. A massive number for 1 human, but not a crazy number for 64 Claude's at once.
  
  To maximize parallelism, the workflow looped over each crate.
  - For each crate, run cargo check, group the output by file and save the errors to a file
  - Fix all the compiler errors within that crate
  - 2 adversarial reviewers for the crate's changes
  - 1 fixer applies the fixes"
  Visualizing fixing of errors, one by one, done by the agents. Source:Anthropic
  
  The enjoyable thing about this phase of the migration was that the agents ran from midnight until 11:30am, fixing compiler bugs on their own - when Jarred and the team were getting some sleep.
  
  Step #8: run tests locally (~2 days). Bun has a large test suite. The next step was to get these tests to run without compilation errors.
  
  Step #9: get the test suite to pass CI (~3 days). Once the tests were running (and failing), the next step was to fix the code, so that the tests could pass. This took two days.
  
  Step #10: Done in 11 days! After all the tests passed and Jarred verified that everything worked as expected, he merged the changes. The whole process took 11 days, from planning to the finish.
  
  The rewrite: porting ~550K lines of code, in 6,500 commits, over 11 days, with 64 agents
  
  How repeatable is this process?
  
  The rewrite cost a whopping $165,000 with API pricing. With Fable's API prices, the rewrite consumed 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads. Anthropic sells API tokens at a margin as its business, so the cost of the rewrite for it was lower. It's a large amount: the equivalent of the annual base salary for a software engineer at a mid-tier company in the US!
  
  But then again, could have an engineer done all this work in a year? Probably not, and Mitchell Hashimoto says the same:
  
  "On the cost, I think $165,000 at API pricing for Fable (didn't verify) is an incredible deal. There's absolutely no way an engineer with that salary would've been able to achieve the milestones Claude did in 11 days. No way. (Even if you break it down to N engineers paid $165K total in 11 days it doesn't math out)
  
  This does, however, also reconfirm my own biases which is that Fable in particular is most excellent at hard, focused tasks with clear reward functions. I've been tweeting about this recently."
  
  What if AI enables rewrites and migrations that wouldn 't have been considered before? The idea of rewriting Bun in Rust without AI was impractical, admits Jarred:
  
  "By hand, I think this would've taken three engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever."
  
  A rewrite or migration taking months or years is why so many of these projects never happen. Let's take aside the cost for a minute and consider this question: if AI can shorten a one-year rewrite to a week: would you do it?
  
  If the answer is "hell, yes:" a blueprint now exists in the form of the Bun migration on how to do it. There are some caveats not detailed in the post, though:
  1. You need an engineer who is very motivated and knows the codebase very well
  2. You need an extremely robust test suite, so when the test suite passes, you know it works
  3. You need to be willing to invest a lot in tokens, not knowing how well it all will work
  In fairness, #3 is the weakest point because we know LLMs are pretty good at "mundane" work like code migrations. With a good test suite (#2) and a motivated engineer to iron out things (#1), you'll more likely than not succeed.
  
  The remaining question is how much can be spent. It will likely not be $165K: and costs can be reduced with a simpler project, or by being thoughtful about model usage. For example, do high-level planning with the most expensive model, and cheaper ones for coding and review tasks.
  
  Migrations with AI are surely speeding up, but only when projects are well- engineered like Bun's has been.
  
  Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:
  1. Grok's CLI uploaded all your local files to the cloud, then got caught.
  2. New trend: concern about massive increase in code review load.
  3. Are more devs at enterprises upset about enterprise pricing by AI labs - and does it matter?
  4. Linux creator: AI "clearly useful."
  Read the full issue here
8. 🔗 r/reverseengineering "Remcos RAT – Svchost Injection, API Hooking & Obfuscated Payload Analysis" rss
  
  submitted by /u/StructBreaker
  [link] [comments]
9. 🔗 @binaryninja@infosec.exchange Every superhero needs a Sidekick. Join us tomorrow at 2pm ET to see the mastodon
  
  Every superhero needs a Sidekick. Join us tomorrow at 2pm ET to see the incredible powers of Sidekick 26: https://www.youtube.com/live/S5hAxyopaQk
10. 🔗 earendil-works/pi v0.80.8 release
  New Features
  - Unified model runtime and provider authentication — ModelRuntime centralizes model configuration, provider-owned /login, and dynamic provider catalogs. See Providers.
  - Live model catalog refresh — /model refreshes configured providers in the background, and pi update --models forces an immediate refresh. See Install and Manage.
  - xAI device-code OAuth and Grok 4.5 Responses support — Sign in to xAI with a device code and use Grok 4.5 with low, medium, or high thinking. See xAI.
  Breaking Changes
  - Replaced the SDK's CreateAgentSessionOptions.authStorage and modelRegistry options with the async modelRuntime option. AuthStorage and its storage backends are no longer exported; use ModelRuntime (or a custom pi-ai CredentialStore), or readStoredCredential() for one-off reads of auth.json.
  - Removed redundant ModelRuntime.getAll(), find(), getSnapshot(), and getAuthOptions() projections. Use the pi-ai Models methods getModels(), getModel(), getProviders(), and checkAuth() directly.
  - Replaced SDK request-auth assembly through ModelRegistry.getApiKeyAndHeaders() with ModelRuntime.getAuth(). Passing a provider ID returns provider-scoped auth; passing a model also resolves built-in, models.json, and extension model headers.
  - Changed extension-facing ModelRegistry.refresh() from synchronous void to Promise<void> because models.json loading is asynchronous. Extensions must await it before making synchronous registry reads.
  - Moved canonical dynamic catalog refresh to async ModelRuntime.refresh()/pi-ai Models.refresh(). Legacy extension OAuth modifyModels remains supported as a synchronous compatibility projection after credential initialization.
  Added
  - Added ModelRuntime as the canonical async SDK and internal model/auth facade while preserving the synchronous extension-facing ModelRegistry API. ModelRuntime.create() accepts any pi-ai CredentialStore through its credentials option.
  - Added provider-owned /login discovery directly from registered pi-ai providers, including ambient auth status and informational links.
  - Added file-backed dynamic catalogs in models-store.json, per-provider pi.dev catalog overlays, and Radius gateway support including offline migration from legacy credential-cached catalogs.
  - Added extension provider refreshModels(context) support for dynamic model discovery with optional provider-controlled persistence.
  - Added pi update --models to force an immediate model catalog refresh without updating pi or extensions.
  - Added inherited xAI device-code OAuth login and Grok 4.5 OpenAI Responses support, with low, medium, and high thinking levels (#6651 by @Jaaneek).
  Changed
  - Changed ModelRuntime to compose built-in providers, immutable models.json configuration, and extension overlays through ad-hoc pi-ai provider methods.
  - Changed ModelRuntime to own final request assembly: getAuth(model) includes configured model headers, stream methods resolve auth once, and before_provider_headers runs as the Models-only header transform before provider dispatch.
  - Changed /model to render the current model snapshot immediately, refresh configured providers in the background, and update the open selector with partial results or timeout errors.
  Fixed
  - Fixed configured-provider catalog refresh to parse pi.dev's model-ID keyed responses, throttle checks to once per four hours, send the versioned pi user agent, treat unimplemented routes as unavailable overlays, and show concise refresh status in /model.
  - Fixed adjacent assistant thinking blocks to render as one thinking section.
  - Fixed inherited OpenAI Codex session IDs longer than 64 characters to meet the API limit (#6630).
  - Fixed inherited terminal output to normalize tab characters consistently (#6697 by @xz-dev).
  - Fixed the Windows terminal title after checking npm packages (#6629).
  - Fixed Bun standalone binaries to bundle OAuth adapters for interactive logins.
11. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release, -1 release, ~1 changed rss
```
sync repo: +1 release, -1 release, ~1 changed

## New releases
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.7.3

## Changes
- [BinSync](https://github.com/binsync/binsync):
  - removed version(s): 5.10.1
  - 5.15.2: archive contents changed, download URL changed
```
12. 🔗 3Blue1Brown (YouTube) But what is cross-entropy? | Compression is Intelligence Part 2 rss
  
  Where the loss function for training LLMs comes from. Job opportunities aligned to this audience: https://3b1b.co/talent Early views and other perks for supporters: https://3b1b.co/support Home page: https://www.3blue1brown.com
  
  Manim animations by Aaron Gostein and Grant Sanderson NanoGPT animation by Clayton Rabideau 3d black-box model by Paul Dancstep Chess game and Lagrange Multiplier scenes by Nishad Deulkar Music by Vince Rubinetti
  
  Timestamps
  
  0:00 - Language trees and zipping 3:02 - Recap optimal codes 5:20 - Defining cross-entropy 8:26 - Intuition and examples 12:59 - Application to language trees 14:55 - Pre-training LLMs 20:38 - What makes this loss function best? 26:13 - Distillation 30:12 - 3b1b Talent 31:35 - KL Divergence
  
  These animations are largely made using a custom Python library, manim. See the FAQ comments here: https://3b1b.co/faq#manim
  
  Music by Vincent Rubinetti. https://vincerubinetti.bandcamp.com/album/the-music-of-3blue1brown https://open.spotify.com/album/1dVyjwS8FBqXhRunaG5W5u
  
  3blue1brown is a channel about animating math, in all senses of the word animate. If you're reading the bottom of a video description, I'm guessing you're more interested than the average viewer in lessons here. It would mean a lot to me if you chose to stay up to date on new ones, either by subscribing here on YouTube or otherwise following on whichever platform below you check most regularly.
  
  Mailing list: https://3blue1brown.substack.com Twitter: https://twitter.com/3blue1brown Bluesky: https://bsky.app/profile/3blue1brown.com Instagram: https://www.instagram.com/3blue1brown Reddit: https://www.reddit.com/r/3blue1brown Facebook: https://www.facebook.com/3blue1brown Patreon: https://patreon.com/3blue1brown Website: https://www.3blue1brown.com
13. 🔗 r/reverseengineering ASUS bsitf.sys (CVE-2026-13585): Arbitrary Physical Memory Mapping 0-day writeup + PoC rss
  
  submitted by /u/watchdogsrox
  [link] [comments]
14. 🔗 r/reverseengineering Reverse-engineering NVIDIA's cuda-checkpoint for faster cold starts rss
  
  submitted by /u/mttd
  [link] [comments]
15. 🔗 r/reverseengineering 🔥 Apkx-Hunter v2.0.0 Released — OWASP MASVS Security Scanning Added! This version introduces **OWASP MASVS (Mobile Application Security Verification Standard)** security scanning with **15 categories** and **166 detection patterns**. rss
  
  submitted by /u/SyscallX-18113
  [link] [comments]
16. 🔗 r/reverseengineering GitHub - joshuapassos/CMF-Watch-Pro-2-BLE-Protocol rss
  
  submitted by /u/JoshuaPassos
  [link] [comments]
17. 🔗 r/reverseengineering First firmware dump of Canon PIXMA TS3451 — AES-GCM manifest encrypted by MatrixSSL Asset Store, looking for help with key derivation rss
  
  submitted by /u/Kertie2_
  [link] [comments]
18. 🔗 Console.dev newsletter Ant rss
  
  Description: Lightweight JS runtime.
  
  What we like: Smaller binary, 100% compatibility, fast package installation. Supports TypeScript with no build step. Includes a VM-isolated sandbox as core functionality with capability-based security.
  
  What we dislike: No docs. Is writing a JS runtime in C a good idea in 2026?
19. 🔗 Console.dev newsletter Sätteri rss
  
  Description: Markdown pipeline.
  
  What we like: Compile Markdown to HTML or JS and process it through a plugin-based pipeline. Hook into multiple stages of the compilation process. Uses syntax highlighting with Shiki as an example plugin. Supports various features like frontmatter, math, smart punctuation, GitHub formatting for tables, footnotes, etc.
  
  What we dislike: No support for Svelte SVX.
20. 🔗 Rust Blog Announcing Rust 1.97.1 rss
  The Rust team has published a new point release of Rust, 1.97.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.
  
  If you have a previous version of Rust installed via rustup, getting Rust 1.97.1 is as easy as:
```
rustup update stable
```
  If you don't have it already, you can get rustup from the appropriate page on our website.
  
  What's in 1.97.1
  
  Rust 1.97.1 fixes a miscompilation in an LLVM optimization.
  
  We have backported both an LLVM fix and a disable of the underlying change in Rust 1.97.0 of Rust's generated IR that increased the likelihood of this happening. However, note that the underlying miscompilation has been present since at least Rust 1.87.
  
  If you'd like to help us out by testing future releases, you might consider running your code's CI or locally using the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!
  
  Contributors to 1.97.1
  
  Many people came together to create Rust 1.97.1. We couldn't have done it without all of you. Thanks!
July 15, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-15 rss
  IDA Plugin Updates on 2026-07-15
  
  New Releases:
  - ida-llm-explainer LLM Explainer v1.7.0
  - mcrit-plugin mcrit-ida v1.1.8
  Activity:
  - binsync
    
    24364095: Give Versioning to Auxiliary Server (#530)
  - disrobe
    
    0627e9df: ruby: keep regexp literal flags by decoding the ibf option byte and r…
    
    420fbe41: php-decompile: parenthesize an equality operand of a relational compa…
    
    5c2fe9d4: lua decompiler: index a reserved-word field or method name with a bra…
    
    8d7be9f4: x86 lifter: model memory bt/bts/btr/btc, CL-controlled shl/shr/sar/sh…
    
    28a53812: py-decompile: keep the else arm of a guard whose then-arm is a with o…
    
    a42c1033: as3: re-emit e4x attribute multinames with the @ sigil so obj.@id no …
    
    2ec575a6: beam: quote erlang reserved-word atoms so re-emitted terms re-parse t…
  - ida-llm-explainer
    
    bc97e2b6: v1.7.0: packed-string carving, caller-fetch, lvar & signature fixes
  - ida_rpc
    
    4fa7de72: Add support for IDA Pro 9.4
  - mcrit-plugin
    
    d531fd8b: proper logging without reconfiguration and with own sub logger
    
    59a53139: ruff format
    
    46094c50: fix: isolate plugin loggers
2. 🔗 r/reverseengineering IDA Pro 9.4 released rss
  
  submitted by /u/KindOne
  [link] [comments]
3. 🔗 r/reverseengineering low-level Windows kernel abstractions in Rust rss
  
  submitted by /u/0xryka
  [link] [comments]
4. 🔗 r/reverseengineering Anatomy of a CUDA Binary rss
  
  submitted by /u/mttd
  [link] [comments]
5. 🔗 r/reverseengineering Exploiting Random Number Generation rss
  
  submitted by /u/AdvisorPowerful9769
  [link] [comments]
6. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 releases rss
```
sync repo: +3 releases

## New releases
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.7.0, 1.6.2
- [mcrit-ida](https://github.com/danielplohmann/mcrit-plugin): 1.1.8
```
7. 🔗 jesseduffield/lazygit v0.63.1 release
  Fixes for a few regressions introduced in the v0.63.0 release.
  
  What's Changed
  
  Fixes 🔧
  - Improve index.lock retry mechanism by @stefanhaller in #5788
  - Fix userEvents panic by @stefanhaller in #5793
  - Fix a deadlock on Windows when switching between longer diffs by @stefanhaller in #5815
  Maintenance ⚙️
  - Allow releasing from a branch other than master by @stefanhaller in #5819
  Full Changelog : v0.63.0...v0.63.1
8. 🔗 r/reverseengineering Automatically Attacking Software Reverse Engineering AI Agents rss
  
  submitted by /u/rolfr
  [link] [comments]
9. 🔗 Baby Steps Battery packs: Let's talk about crates, baby rss
  This blog post describes an idea I've been kicking around called battery packs. Battery packs are a curated set of crates arranged around a common theme. For example, there's a CLI battery pack that has everything you need to build a great CLI, an opinionated pack for creating a backend web service, and one for embedded development (based on the Embedded Working Group's Awesome Rust repository). We've also got some smaller ones, such as the error-handling battery pack that shows how to handle errors in Rust. But this is just the beginning - a key part of the battery pack design is that anybody can create one.
  
  Battery packs are meant to address one of the most common things I hear from new Rust adopters. Everyone loves the wealth of high-quality crates available on crates.io. And everyone hates having to spend a bunch of time researching and comparing alternatives. Battery packs can serve as a good set of default choices. And they don't lock you in. At heart, they're basically just a list of recommended crates, so you can always swap something out if you find an alternative.
  
  We've got a prototype of the battery pack tool working today, so you can try it out if you're curious. Just run cargo install cargo-bp and then try a few commands! For example,
```
> cargo bp list
```
  will show you the set of available battery packs, based on a crates.io search (as I'll explain below, a battery pack is itself packaged and distributed as a crate, but not one that you take a direct dependency on). And cargo bp add will add batteries from a battery pack into your crate, so e.g.
```
> cargo bp add cli
```
  would let you select and add common CLI libraries. If you want to see a more involved demo, try out cargo bp add embedded, which is derived from the Awesome Embedded Rust repository.
  
  Let's talk about you and me
  
  One of the key ideas from battery packs is that anybody can publish one. They are just a crate named X-battery-pack; the dependencies of that crate are your recommendations. Features are designations of common sets of crates frequently used together. The examples are your templates. And so forth.
  
  Letting anybody create a battery pack is in contrast to the previous ideas for an "extended standard library for Rust"1, and it is intended to address some of Rust's unique challenges. For one thing, it lets people publish battery packs that are tailored to specific requirements. For example, the CLI and backend service battery packs are targeting a "typical computer". But I could imagine the Rust embedded working group publishing a battery pack with libraries focused on no-std and binary size optimization.
  
  Being open-ended also addresses the " who decides?" question. To my mind, the best people to recommend what libraries you ought to use are other people building systems like yours. This is why I mentioned the Embedded Working Group publishing an Embedded battery pack, for example, as I think they are clearly a set of people who know their space well. But even within the embedded space there are yet smaller groups, and I imagine that sometimes it'll make sense to get narrower. For example, perhaps a battery pack targeted embassy and its associated ecosystem? Unclear.
  
  Creating a battery pack
  
  If you wanted to create a battery pack, how do you do it? One answer is that you just create a new crate. But a better approach is to use the "battery-pack battery pack"2, which bundles a template:
```
cargo bp new battery-pack
```
  This will prompt you for the name of the battery pack you want to create and a few other things and make your crate. Then you can just use cargo add dependencies to represent the libraries you want to recommend and publish.
  
  "Batteries" are more than dependencies
  
  The "batteries" that you can add to your project aren't always dependencies. They can also be "recipes" or templates. For example, the CI battery pack3 can configure your project with the kind of "super neat-o" github actions you've always wanted but never wanted to bother configuring. To use it, select one or more of the templates to install:
```
cargo bp add ci
```
  I expect this kind of "actions to improve your crate" to become a rich source of things. Right now we're using a relatively lightweight template system built on minijinja, but I think we're going to want to expand on this.
  
  Giving it some structure
  
  Battery Packs also support more than just a flat listing of dependencies/features/templates. You can group dependencies and features into categories and then, for each category, distinguish between "pick at most one" or "pick any number". For a fun example, try cargo bp add embedded, which is derived from the Awesome Embedded Rust repository. If you run it, you'll see something like this, which groups the choices thematically and, in some areas like "concurrency framework", makes it clear that you want to pick one:
```
──────────────────────────────────────────────────────────────────
 ▼ Concurrency Framework (pick at most one)
 > ○ ✦ embassy [embassy-executor, embassy-sync, embassy-time]
   ○ ✦ rtic [cortex-m, rtic]    RTIC — interrupt-driven real-time

 ▼ Display & Graphics (pick any number)
   [ ] ✦ display-ssd1306 [embedded-graphics, ssd1306]    SSD1306
   [ ] ✦ display-st7789 [embedded-graphics, st7789]    ST7789 col

 ▼ Popular Drivers (pick any number)
   [ ] ✦ display-ssd1306 [embedded-graphics, ssd1306]    SSD1306
   [ ] ✦ display-st7789 [embedded-graphics, st7789]    ST7789 col
   [ ] ✦ sensor-bme280 [bme280]    BME280 temperature/humidity/pr
   [ ] ✦ sensor-lis3dh [lis3dh]    LIS3DH 3-axis accelerometer (I
   [ ] ✦ usb-device [usb-device, usbd-serial]    USB device stack

 ▼ Hardware Abstraction Layer (pick at most one)
   ○ ✦ atsamd [atsamd-hal, cortex-m-rt, critical-section-impl, co
   ○ ✦ esp32 [embedded-hal, esp-hal]    ESP32 (Xtensa, WiFi + BT,
   ○ ✦ esp32c3 [embedded-hal, esp-hal]    ESP32-C3 (RISC-V, WiFi
   ○ ✦ esp32s3 [embedded-hal, esp-hal]    ESP32-S3 (Xtensa, WiFi
   ○ ✦ nrf52832 [cortex-m-rt, critical-section-impl, cortex-m, em
   ○ ✦ nrf52840 [cortex-m-rt, critical-section-impl, cortex-m, em
   ○ ✦ nrf9160 [cortex-m-rt, critical-section-impl, cortex-m, emb
   ○ ✦ rp2040 [cortex-m-rt, critical-section-impl, cortex-m, embe
   ○ ✦ stm32f0 [cortex-m-rt, critical-section-impl, cortex-m, emb
 embedded-battery-pack v0.1.0  ↑↓/jk Navigate | Space Toggle | ←/→
```
  Let's talk about all the good things…
  
  So why am I so keen on battery packs? It's largely because I've heard so many would-be or recent Rust adopters talk about picking crates as a challenge. But I feel they would help with some other problems as well.
  
  What I really want to see is working groups in the Rust Commercial Network banding together to publish battery packs and recommendations. These would cover the dependencies that they're actually using.
  
  Supporting maintainers
  
  One of the reasons I want to have RCN-recognized battery packs is that they are a natural focal point to then prompt RCN members to fund the maintenance of those crates. I am imagining that for each sponsored battery pack vended within the RCN, there is an associated "ecosystem fund". Companies or individuals could sponsor this fund to get access to early patches, security disclosures, etc or other perks. The money would be used to support the maintainers of those crates, to implement missing features, and so forth.
  
  Fostering interoperability
  
  Another value-add from battery packs is the ability to drive interop efforts. I think that as soon as we start talking about standardizing, we're also going to recognize that there are some places where standardization is hard. For example, early conversations within the network service working group (unsurprisingly) immediately identified that while most people are using tokio, some major companies are using their own runtimes internally. It's not like the need for "async runtime interop" is news. But right now, every crate winds up effectively implementing their own set of little traits to make it work. Sponsored battery packs offer the possibility of a neutral home for that sort of thing.
  
  …and the bad things that could be
  
  There are some risks to people using battery packs. The most obvious is that the fact that anybody can publish a battery pack may mean that you just get a ton of battery packs, which doesn't really help anybody! I'm not so worried about this because I think that there will be a few obvious places that most people go first, and then I think once people are oriented, they'll get excited to explore what crates.io has to offer and start discovering more niche battery packs.
  
  Avoiding stagnation
  
  Battery packs are designed to evolve. I've seen it happen a number of times that there is a dominant crate for something, often taking a "traditional approach", but then somebody else comes along and presents an interesting alternative that gradually takes off. I love that and I don't want to put it at risk.
  
  One example of evolution around CLI argument parsing. For a time, docopt was a popular way to parse command- line options. Then clap came along and presented a more structured alternative; that was nice, but then structopt came along and connected clap to an auto-derive, so you could just write your data structure and be done. And that was awesome. (That is now the standard in clap.) I want to be sure that, even if there is a CLI battery pack, there's room for the next clap to come along.
  
  There are a few things about battery pack that I think will help us deal with this. First, they are a "thin abstraction". You don't "depend on" a battery pack, you depend on the crates within it. So if a new version comes out that uses clap instead of docopt, that doesn't impact you at all. Your code keeps working same as it ever did. And of course it helps that anybody can publish a battery pack. You can now have variations on battery packs that are focused around a new approach to help it get started.
  
  Done right, I think that standardized battery packs can also help the ecosystem evolve and pivot. As it is now, knowledge of new crates has to spread by word-of-mouth. But if everybody is aligned around a new approach, adopting that new approach within a battery packs sends a clear signal that your group is aligned that something is the new hotness.
  
  …Let's talk about
  
  crates4
  
  "Always bet on the ecosystem"
  
  I see always bet on the ecosystem as a key Rust design axiom. It's the reason we chose a small standard library and a package manager in the first place. It's also why battery packs are designed to be published by anyone.
  
  But just like plants sometimes need a trellis to grow taller, any successful ecosystem reaches a point where it needs another layer of structure to help it keep growing. Without that, you have this "layer of tacic knowledge" (in the words of a Rust Vision Doc interviewee) that becomes an obstacle for folks. And I think we've reached that point with crates.io.
  
  I am hopeful that battery packs can provide that next layer of structure. But at the end of the day, if there's a better approach, that's fine too, so long as we find a way to help people find (and fund!) the crates they need. So let's talk about it!
  1. My first recollection of it was the Rust Platform idea we floated in 2016! ↩︎
  2. Yo dawg… ↩︎
  3. Hat tip to Jess Izen, who proposed and developed the CI battery pack. Neat idea. ↩︎
  4. Oh, and: my apologies to Salt-N-Peppa. ↩︎
July 14, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-14 rss
  IDA Plugin Updates on 2026-07-14
  
  New Releases:
  - ida-llm-explainer LLM Explainer v1.6.2
  Activity:
  - augur
    
    41edd0f2: ci: improve
  - capa
    
    30f93787: Merge pull request #3114 from mandiant/dependabot/pip/msgpack-1.2.1
  - ghidra
    
    7462bcec: Merge remote-tracking branch 'origin/patch'
    
    45d95c50: Merge remote-tracking branch
    
    ce37accf: Do not normalize build_exe in pcodetests definitions
    
    d463fbff: Merge remote-tracking branch 'origin/patch'
    
    88566a13: Merge branch 'GP-7065_ghidorahrex_PR-9371_p-mikeg_fix_arm_sev_encoding'
    
    f18269b0: Fix sev.w arm encoding.
    
    237d1a9f: Merge remote-tracking branch 'origin/patch'
    
    87d10fc6: GP-7064: Fixing XmlLoader path traversal
  - haruspex
    
    1edfcb68: ci: improve
  - ida-llm-explainer
    
    21d60a55: Release v1.6.2: batch progress header + hardware note
    
    708885de: README: note the consumer hardware behind the batch screenshot
    
    8c4aafda: README: batch-mode screenshot with a local Qwen model
    
    fd2f8f84: Batch progress label: live done/running/queued counts, avg time and ETA
  - IDAPluginList
    
    a3173079: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
  - rhabdomancer
    
    3e09ac3a: ci: add cargo test
  - rikugan
    
    8118c74f: chore(release): bump version to 1.10.4
    
    82c6b418: Merge branch 'feat/docs-review-post-error'
2. 🔗 r/reverseengineering AI reverse-engineered Philips baby monitor and built a Rust client rss
  
  submitted by /u/Ok_Leader485
  [link] [comments]
3. 🔗 earendil-works/pi v0.80.7 release
  Breaking Changes
  - Removed the openai-responses compat.sendSessionIdHeader flag from models.json. Session-affinity behavior is now controlled by compat.sessionAffinityFormat ("openai", "openai-nosession", or "openrouter"). Replace sendSessionIdHeader: false with sessionAffinityFormat: "openai-nosession" (#6496 by @petrroll).
  New Features
  - Cache-friendly dynamic tool loading - Extensions can add tools during execution while supported Anthropic and OpenAI Responses models preserve prompt-cache prefixes. See Dynamic Tool Loading.
  - Message copy shortcut - Ctrl+X copies the last assistant message in the transcript or the selected message in /tree, making older and branched messages directly copyable. See Display and Message Queue.
  - Fable 5xhigh and max thinking - Native xhigh and max thinking levels are available across generated provider catalogs. See Model Options.
  Added
  - Added cache-friendly dynamic tool loading for extension tools activated by tool results. Supported Anthropic and OpenAI Responses models load definitions where they become available, preserving the cached prompt prefix. See Dynamic Tool Loading (#6474).
  - Added inherited native xhigh and max thinking levels for Claude Fable 5 across all generated provider catalogs (#6490 by @davidbrai).
  - Added Ctrl+X to copy the last assistant message, or the selected message in /tree.
  - Added inherited toolChoice support for OpenAI and Codex Responses, including required and named tool selection (#6588 by @xl0).
  Fixed
  - Fixed inherited OpenRouter model context windows to use the top provider's actual context length (#6481 by @davidbrai).
  - Fixed inherited OpenRouter OpenAI-compatible session IDs to use the x-session-id header instead of OpenAI-specific session-affinity fields (#6496 by @petrroll).
  - Fixed Ctrl+V to paste clipboard text when the pasteboard does not contain an image.
  - Fixed /login amazon-bedrock to prompt for and save a Bedrock API key instead of only displaying ambient AWS credential setup instructions.
  - Fixed inherited Amazon Bedrock ambient AWS credentials to keep using SigV4 authentication, including for custom model IDs (#6532 by @ribelo).
  - Fixed inherited Cloudflare Workers AI and AI Gateway authentication to use ambient account and gateway IDs when stored credentials contain only an API key (#6292 by @markphelps).
  - Fixed inherited legacy terminal decoding for Alt+symbol key combinations such as Alt+, and Alt+. (#6523 by @ribelo).
  - Fixed the GitHub Copilot mai-code-1-flash-picker model to route through the /responses endpoint (#6544 by @petrroll).
  - Fixed branch summaries to work with providers that use ambient authentication instead of API keys (#6595 by @davidbrai).
  - Fixed inherited Amazon Bedrock errors to report unhandled provider stop reasons instead of only An unknown error occurred (#6598 by @davidbrai).
  - Fixed npm package removal when installed packages have conflicting peer dependencies (#6604 by @davidbrai).
  - Fixed inherited Azure OpenAI Responses reasoning replay when encrypted_content appears only in the terminal response event (#6608 by @davidbrai).
  - Fixed inherited Anthropic-compatible proxies that omit usage from message_delta events (#6611 by @davidbrai).
  - Fixed inherited OpenCode OpenAI Responses models to omit the unsupported session-id header while preserving other cache-affinity data (#6645 by @davidbrai).
  - Fixed system prompt cache invalidation across dates by removing the current date from the default prompt (#6621).
4. 🔗 r/Harrogate Takeaways near the station? rss
  
  Coming to Harrogate tomorrow evening and need to get a takeaway from somewhere near the station before driving to my accommodation to watch the football with family. What takeaways would you recommend?
  
  Seen there’s a McDonald’s and Rudy’s pizza (do they do click & collect), no delivery services come to my relatives house due to how rural they are so must have in person pick up.
  
  submitted by /u/castiellangels
  [link] [comments]
5. 🔗 r/reverseengineering Interactive documentation and visual reference for binary formats and system memory layouts. rss
  
  submitted by /u/RubberDuck31337
  [link] [comments]
6. 🔗 pydantic/pydantic-ai-harness v0.7.0 (2026-07-13) release
  What's Changed
  - feat: input and output guardrails (block, redact, retry) by @dsfaccini in #249
  - Fix docs-parity gate and OutputGuard retry test after guardrails merge by @dsfaccini in #348
  - refactor: graduate capabilities out of experimental (ACP excepted) by @dsfaccini in #347
  - docs: capability pages for the unified docs site + README/doc parity gate by @dsfaccini in #329
  - Remove stale Claude-only AICA attribution by @dsfaccini in #362
  - feat: add Memory capability by @DEENUU1 in #354
  New Contributors
  - @DEENUU1 made their first contribution in #354
  Full Changelog : v0.6.0...v0.7.0
7. 🔗 r/reverseengineering AntiVE-BehaviorWatch ( AI model Inside a EXE ) rss
  
  submitted by /u/ObligationLucky842
  [link] [comments]
8. 🔗 @HexRaysSA@infosec.exchange 📢 IDA 9.4 is here! mastodon
  
  📢 IDA 9.4 is here!
  Huge thanks to our beta testers for spending the last several weeks refining this release.
  
  • The Apple Dyld Shared Cache workflow has been rebuilt from the ground up.
  • The decompiler now speaks Swift, with proper ABI modelling for self, async context, and error paths.
  • Two new processor modules land — Qualcomm Hexagon and MCore.
  • Navigation gets a major upgrade with Pathfinder and a redesigned Jump Anywhere.
  • The Teams add-on now runs on Git.
  • And idalib, previously Pro-only, now ships with IDA Home.
  
  👉 Read the blog for the full breakdown and/or jump ahead to the release notes, then grab your update in the Download Center.
  https://hex-rays.com/blog/ida-9.4-release-a-new-dyld-shared-cache-swift- analysis-new-teams-add-on-and-more-
9. 🔗 New Music Releases Saliva - Longshot rss
  Saliva - a new release is available:
  - 2026-07-14: Longshot (Single)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.

generated: July 17, 2026 at 16:06:52

IDA Plugin Updates on 2026-07-16

New Releases:

Activity:

New Features

Fixed

What’s new?

Bugfixes

New Features

Improvements

Download

Acknowledgements

But how does it pelican?

What can we learn from the pelican?

New Features

Added

Changed

Fixed

Removed

Why a rewrite?

Rewriting Bun with Fable

How repeatable is this process?

New Features

Breaking Changes

Added

Changed

Fixed

What's in 1.97.1

Contributors to 1.97.1

IDA Plugin Updates on 2026-07-15

New Releases:

Activity:

What's Changed

Fixes 🔧

Maintenance ⚙️

Let's talk about you and me

Creating a battery pack

"Batteries" are more than dependencies

Giving it some structure

Let's talk about all the good things…

Supporting maintainers

Fostering interoperability

…and the bad things that could be

Avoiding stagnation

…Let's talk about

"Always bet on the ecosystem"

IDA Plugin Updates on 2026-07-14

New Releases:

Activity:

Breaking Changes

New Features

Added

Fixed

What's Changed

New Contributors