🏑


  1. July 29, 2026
    1. πŸ”— WerWolv/ImHex Nightly Builds release

      Nightly

      bf5fab9 Changelog

      • impr: Don't draw jump arrows for call instructions
  2. July 28, 2026
    1. πŸ”— Hex-Rays Blog Hex-Rays is Heading to Hacker Summer Camp 2026 rss

      Hex-Rays is Heading to Hacker Summer Camp 2026

      Vegas in August generally means one thing for the reverse engineering community: Hacker Summer Camp. Hex-Rays will be on the ground for all three events, and we've packed the week with demos, a workshop, some light recruiting and more. Here's where to find us.

    2. πŸ”— r/reverseengineering Reproducing a D-Link firmware CVE on an emulated FirmAE twin, packaged as a signed receipt you can re-verify in 5 min (with a PR:Nβ†’PR:L CVSS correction) rss
    3. πŸ”— r/reverseengineering The Elevator Glitch: How One Function Destroyed Public Lobbies in CoD4 rss
    4. πŸ”— r/reverseengineering Phantom Stealer – jsc.exe Injection, Credit Card Theft & Email Exfiltration rss
    5. πŸ”— @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here: https://v35.us/dn6rcg5

    6. πŸ”— @binaryninja@infosec.exchange Today’s giveaway is huge! It includes one year of Binary Ninja Non-Commercial mastodon

      Today’s giveaway is huge! It includes one year of Binary Ninja Non-Commercial PLUS one year of Sidekick Non-Commercial! Already have a license? The prize can be used as a license extension. https://binary.ninja/10years

    7. πŸ”— r/reverseengineering I reverse engineered an ASUS embedded controller's fan protocol. rss
    8. πŸ”— r/reverseengineering Reverse-engineered the BLE protocol of a discontinued Fisher-Price toy Lumalou after its app was discontinued rss
    9. πŸ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss
      sync repo: +1 release
      
      ## New releases
      - [rhabdomancer](https://github.com/0xdea/rhabdomancer): 0.10.0
      
    10. πŸ”— pydantic/pydantic-ai-harness v0.12.0 (2026-07-27) release

      What's Changed

      Full Changelog : v0.11.0...v0.12.0

    11. πŸ”— r/reverseengineering GitHub - memues/mstar-monitor-firmware-dumper: Dump SPI flash firmware from MStar scaler-based monitors over I2C/DDC rss
    12. πŸ”— Probably Dance If AI Writes All the Code, What Do the Programmers Do? rss

      Eight months ago I was producing roughly 90% human written code and 10% AI written code. This has switched surprisingly rapidly and now my code is probably 90% AI. So what do I do all day?

      I'll go through a change that I made to a matrix-multiply kernel, for which I'll sadly have to be a bit vague. Since GPUs are now giant matrix-multiply chips, where north of 96% of the flops are in the tensor cores (latest Nvidia GPUs have 2250 tflops in bfloat16 matmuls, compared to 75 tflops for everything that's not a matmul), you'd think that they'd make it easy to use all those flops. But no, matrix multiply kernels are giant crazy beasts that are incredibly tricky to get right. Some quick googling finds this explanation on Nvidia hardware and this one on AMD hardware. Just open those two and scroll down both to get a feeling for how much work is involved. (and yes, these implement the simple O(n^3) matmul loop where you iterate along repeatedly and multiply and add all the numbers)

      The particular kernel I was optimizing was using Cluster Launch Control (CLC), a complexity that's covered in neither of the blog posts linked above, and it had some bad interactions with some particular inputs. The resulting change was 95% written by AI. So I'll just go through what I did. AI asks are bolded:

      0. Find and Understand the Problem

      Before I started I had to find and understand the problem. Some coworkers had talked about the matmuls taking too long, and nsys showed that the tensor- cores were oddly idle while that matmul kernel was running, and then it took some more targeted benchmarking to confirm that slightly different inputs give big speedups, which convinced me that something silly must be going on. My coworkers actually had a really good theory, which brings me to the actual start of the work on this task:

      1. Find the Code

      The code was in a library that I was vaguely familiar with, but since matmul kernels are giant scary beasts, it was a bit hard to navigate. So before I even tried, I asked an AI to find the relevant code for me. I explain what the problem is and I explain our theory. Then I also start looking myself but the AI finds the relevant code first and even points me at exactly the right lines to look at. It also confirms that our theory for the problem sounds plausible.

      2. Understand the Code

      Next I decide to understand the code myself, so I intentionally don't ask the AI anything more. As I look around I begin to think that our theory actually isn't right. I mean it was partially right, but the code very much wasn't doing the slow thing that we thought it was doing. It was doing something slower: returning out of CLC mode and giving control back to the hardware scheduler.

      This is a little silly, so after I am convinced of it, I ask the AI to confirm , just to get a second opinion. It agrees with me (but I take that with a grain of salt, because it also agreed with the initial theory).

      3. Monkey-patch the Code

      Since neural network training happens in Python, you fix things by monkey- patching. At least initially this is the fastest way to iterate on this code. But monkey-patching has a bit of boiler-plate that's easy to get wrong, so I ask the AI to set it up for me.

      Then I try to fix the bad behavior, but my fix results in a deadlock. I look at the surrounding code again, but realize I don't understand CLC enough (this is my first interaction with it, and I jumped straight into a complicated kernel where it's part of other pipelining), so I could either spend the time to understand the surrounding code better, or I could just ask the AI to have a look.

      4. Fix the Code

      I ask the AI how it would fix the issue. It immediately tells me why my fix didn't work: I was violating some invariant in the code where the pipelining logic was also used to reason about what state the CLC is in, and my change required keeping the CLC state separately. The AI helpfully tells me that there is one unused slot of shared memory that is reserved for unknown reasons and is entirely unused by the kernel, so it suggests just using that memory to pull out the state that now has to be tracked separately.

      Understanding this would have taken me hours, maybe even a full day, so I tell the AI to just go ahead and implement the fix that it has in mind. The fix immediately works and makes the code much faster for the problematic inputs.

      5. Reviewing the Code

      At this point I spend some time to understand the code and the change better. It looks reasonable to me, but I also ask a second AI to review the work of the first AI. The second AI finds a problem: The matmul kernel was clobbering over some other state that I hadn't fully reasoned through, and this was not a problem when the thread-block was shutting down and giving control back to the hardware, but with CLC it means the clobbered state gets reused. I look at it and I'm not sure it's a real problem. I think this would only happen if we're iterating over padding tokens, and for those the clobbered state is fine. I ask my first AI and it seems worried, because the documentation doesn't say that CLC guarantees ordering, so if we get a valid token after a padding token for some reason, the clobbered state would lead to problems. It also suggests a fix. I think about the fix, which seems too complicated. After some staring at the code I suggest a simpler fix, which the AI thinks should work, so I ask it to implement the simpler fix.

      I also add an assert to check if we ever get valid tokens after padding tokens. Mostly just because it sounds strange to me if CLC behaves like this, so I'm curious to find out.

      6. Benchmarking the Code

      I have verified that the code is faster for the problematic inputs, but a coworker suggests drawing plots with the speedup across various different shapes. So I ask an AI to write a simple benchmarking script for me. (AI was actually already great for these kinds of throwaway scripts a year ago)

      The benchmarking script does not reproduce the initial issue at all. The inputs look plausible to me, but I decide to just ask the AI to reproduce exactly the same inputs that we'd get in prod. (this is not particularly challenging, but manually tracing through the code to make sure you get this exactly right is tedious, so better to just ask the AI)

      After that I can produce the plots that I expect. Interestingly it suggests that even with the fix, we're still far below the speed that this same matmul kernel achieves for other inputs.

      7. Asking for More Ideas

      So I ask my first AI if it has any other ideas to speed up this code. I had one idea already, but I wanted to see what it says. It does suggest my idea, but it also has four other ideas. One of which is a tiny change that sounds really promising. So I ask it to implement that one. And then I also ask it to implement my idea. (this actually took a few steps because I was worried the change would be too big, but the AI comes up with a way to implement my idea with only minor changes)

      Both of those ideas speed up the code more. The code is slightly faster with the idea that I had, but it's also more complicated, so I actually decide to just do the tiny change that the AI suggested, together with the initial fix, and call the kernel 'fast enough' there.

      8. More Review

      At this point I'm getting all of this code ready for review for a coworker, when our code review tooling finds a problem in my new code. Before release I had replaced the assert that I added in step 5 with a print statement, because I don't want code to crash just because I was curious if something ever happens (it never happened in all my testing), but the review bot points out that this should really be turned back into an assert because we still assume that CLC work arrives in order. This is weird to me because I had extensive conversations about this with two other AIs before, making sure that we don't assume that, but the new review bot found an edge case where even the original unmodified code relied on this assumption.

      9. Simplification

      At this point I have some very careful conversations with my various AI bots to try to get to the bottom of exactly what the original code was already assuming and which new assumptions our patches introduce (I also have to read the code myself and understand it, because I don't trust the AIs to get this completely right). And eventually I make the judgement call that we'll just assume that CLC work arrives in order, which can simplify the change because we don't need to worry about the clobbered state from earlier. I ask the AI to simplify and it does an OK job, but since this is the final code, I step in and simplify a bit further still.

      Constant Conversation

      The whole time I'm in constant conversation with AIs. I'm going through way more tokens per day than I did even a few months ago. It's also not just one AI, but multiple different ones. Answering questions about the code, providing ideas, writing new code, reviewing.

      Am I Faster?

      Overall this took a couple days. The initial change took just under a day, where on my own I probably would have taken two or three days, because there were some genuinely tricky interactions with the pipelining, and the AI found a good trick to use some unused shared memory to get out of that easily.

      On the other hand I was also distracted because AI made me question whether we can assume that CLC work arrives in order. I would have not doubted that (even if it's not guaranteed by documentation) and would have saved some time without that paranoia.

      AI also just allowed me to jump straight into the problem. The initial "find me the relevant code" pointed me directly at the right lines, and I was able to make changes without having to spend the time to warm up with it.

      So overall I probably did in four days what would have taken me five days before. The initial speed up of doing the first implementation in less than a day instead of two or three days does not translate into a similarly dramatic overall speedup, mainly because there is a bunch of benchmarking to do and reviewing, and understanding of the actual code. For many years now I have felt that "writing code" is not usually my bottleneck (I'm not too far from the "10 lines of code per day" quoted in the Mythical Man Month). That is the part that AI can speed up dramatically. It also helps in other parts, but with smaller speed-ups.

      Am I Better?

      I think my work had a higher quality according to some metrics: I tried more optimizations and had nice plots for how those optimizations behaved for different inputs. I might have done that on my own, too, but it's certainly easier to just ask an AI. I actually think it's somewhat likely that I would have arrived at the same final code change without AI, but the AI allowed me to explore more of the space before I ended up there.

      The main downside is that I have less understanding now than I would have otherwise had. I did end up having to understand the kernel quite well and I can now navigate that library easily, because in the end I had to make decisions about competing claims by the different AIs. But even though my understanding of the code is much higher than it was at the start, it is still not where it would have been if I had to do this entirely on my own.

      I also think this change was a lot more careful with AI than it would have been without. It's kind of humbling how many bugs the latest top models find in any code that I try to release. It now makes a lot of sense to me how all software is subtly broken, because there are broken edge cases in nearly all my changes (things like "there is a memory leak here. It was actually there before, but we didn't go down that code path before your change."). I think even if we somehow went back to writing code manually and only got to keep AI code review, software would be a lot more robust in a few years. (sadly I'm not sure if that will happen if AI also writes the code)

      Do I Enjoy This?

      The moment of "my first change didn't work because I didn't take the time to fully understand the existing code" gave me a similar feeling to having access to a cheat code in a video game: I could now do the hard work of earning my progress, or I could use the cheat code (the AI) to solve the problem.

      The dissatisfaction of using the cheat code is similar to a video game. But in a work environment it's hard to justify spending the extra days out of personal pride. There's plenty more work to do after I'm finished with this. My job isn't to write code, my job is to fix problems and to ship new features, and "write code" was just the way I got that done before.

      I do get the new satisfaction of finishing more code. E.g. I can finish side projects again despite having less time to program (1, 2). And while I shipped the above code, I also shipped two small side projects at work. (a bug fix to a shared library, and a separate benchmarking utility that I only used a little here, so didn't even mention above) Small changes are great now because I can just ask an AI to give it a try and check back 30 minutes later to see how it turned out. If the changes actually end up as small as expected, these often ship.

      Do I Still Need to Be In the Loop?

      OK so why can't an AI just do all the things that I was doing? Have a supervisor AI that coordinates a planner AI, a writer AI and a reviewer AI? I mean here is a good talk where they wrote a "deep research" bot that works exactly like this, but AI is still not quite there when it comes to outputting something that you have to live with for a long time and may want to tweak yourself.

      Two of the reasons why AI works so well for code is that 1. you can split the work into contained components, and 2. you can go in and tweak the last details. To illustrate the power of these two points, think of other tasks where these are not true, like asking the AI to generate a video for you. But for them to be true, code has to still be tight and readable. My role in this was mostly to get to the bottom of what's actually needed, make a judgement call for picking a good spot on the "optimization vs complexity" trade-off and to then ask the AI to simplify and to then simplify further myself.

      Will AI be able to do even that in a year? Plausibly. Currently the topic in the news is how AI can get pretty unhinged in its pursuit of goals, which I have also seen (at a smaller scale) before, so I'd keep a human in the loop for a while longer.

    13. πŸ”— smol-machines/smolvm smolvm v1.7.1 release

      What's Changed

      • chore(nix): bump flake to 1.7.0 by @BinSquare in #753
      • Don't fail the nix bump release job when Actions can't open the PR by @BinSquare in #754
      • Pin the CLI program name to smolvm in help output by @archsyscall in #755
      • Stop warning about missing packed assets when running the installer's own smolvm-bin by @BinSquare in #759
      • Add a node endpoint that pre-loads a .smolmachine artifact into the local blob cache by @BinSquare in #763
      • Bump libkrun and rebuild the bundled macOS, Linux, and Windows libraries by @BinSquare in #767
      • Bump the workspace to 1.7.1 for the next engine release by @BinSquare in #765

      New Contributors

      Full Changelog : v1.7.0...v1.7.1

  3. July 27, 2026
    1. πŸ”— IDA Plugin Updates IDA Plugin Updates on 2026-07-27 rss

      IDA Plugin Updates on 2026-07-27

      New Releases:

      Activity:

      • augur
      • capa
      • disrobe
        • 5cb6d051: dotnet: accept a metadata name run of any length and keep only identi…
        • 0aca4692: guard python disassembly scratch paths during unwinding
        • 6f6f089f: guard mba scratch paths during unwinding
        • d540965f: guard php scratch paths during unwinding
        • 735becba: guard python deob scratch paths during unwinding
        • 1757cdf4: guard wasm scratch paths during unwinding
        • ecc2faaf: guard javascript scratch paths during unwinding
        • ca770551: guard dotnet scratch paths during unwinding
        • 7648d3ab: guard core scratch paths during unwinding
        • 3665b0a7: guard cli scratch paths during unwinding
        • d5d42adf: guard ruby scratch paths during unwinding
        • 04bee479: guard native scratch paths during unwinding
        • 877c64cd: guard binfmt scratch paths during unwinding
        • b55d5399: docs: state the refusal policy once, that a recovery which cannot be …
        • ffab5d68: guard nuitka scratch paths
        • 72f113c2: guard lua scratch paths
        • 50264158: guard pyfreeze scratch paths
        • 607f2aed: guard jvm scratch paths
        • 5dfa5f7d: cli: resolve a GHIDRA_HOME install to the launcher this platform can …
        • 65ffeced: recover aarch64 bare-return signatures from attributed callers
      • haruspex
      • ida-domain
        • 6c80803c: Fixed segment name and size printing for analyze_database example. (#…
      • ida-hcli
        • 7b133e24: Merge pull request #254 from HexRaysSA/plugin-list
        • 94df02e6: Introduce hcli plugin list alias to hcli plugin status
      • leaknet
        • 898666e9: -ragdoll grabbing/glueing/tool usage works again!
      • Luc-Nhan
        • 90f6d4d7: Auto stash before merge of "master" and "EliteClassRoom/master"
        • 5215c40e: Merge remote-tracking branch 'EliteClassRoom/master'
        • 9060ab26: feat(skills/deobfuscation): add 4 methodology references + auto-triggers
        • b25c7afb: chore: sync uv.lock with pyproject.toml version 1.14.0
        • 290482ed: refactor(skills): rename linux-malware to elf-malware-analysis, defan…
        • 00ccbdaa: fix(skills): support YAML folded (>) and literal (|) block scalars
        • d1961bb7: feat(skills): add /emulator skill and Emulation Awareness section
      • rhabdomancer
      • twdll
    2. πŸ”— @binaryninja@infosec.exchange TWO WEEKS until our next Automated Reverse Engineering course. Whether you mastodon

      TWO WEEKS until our next Automated Reverse Engineering course. Whether you love math and algorithms, or love (correct) LLMs, or juuuust need that last push to find that bug; Automated Reverse Engineering has one of the highest student satisfaction ratings of the premier reversing courses, and there's a good reason why. Sign up today: https://shop.binary.ninja/products/are- aug-26

      https://youtube.com/shorts/iBPSOl4eAQM

    3. πŸ”— @HexRaysSA@infosec.exchange Our Teams add-on just got a major upgrade. It now runs on top of any Git mastodon

      Our Teams add-on just got a major upgrade. It now runs on top of any Git server (GitHub, GitLab, Bitbucket, or self-hosted). Clone, analyze, commit, push β€” no new server, no new credentials.

      πŸ‘€ We're looking for qualified corporate testers (min. 2 users) to try it out at no charge. Specific eligibility terms apply.
      Email sales@hex-rays.com to see if you qualify.

      Read all about the upgrade: https://hex-rays.com/blog/teams-git-native- versioning-collaborative-reversing

    4. πŸ”— Locklin on science Warfighting ability rss

      Imagine you are world hegemon and some shitty little country sidles up to you with an idea of making war on some other country. How can you tell if this is a bad idea? I mean, it’s already a bad idea, how can you assess how bad an idea it might be? Despite all the […]

    5. πŸ”— r/reverseengineering SysCore rss
    6. πŸ”— @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here: https://v35.us/dn6rcg5

    7. πŸ”— @binaryninja@infosec.exchange Today we are giving away 3 Binary Ninja mugs! We’re celebrating 10 years of mastodon

      Today we are giving away 3 Binary Ninja mugs! We’re celebrating 10 years of Binary Ninja with daily prizes and 35% off all Binary Ninja products through August 1. Get the details: https://binary.ninja/10years

    8. πŸ”— HexRaysSA/plugin-repository commits Stop baking derived author logins into combined.json rss
      Stop baking derived author logins into combined.json
      
      The UI now groups publisher pages by metadata.repository_owner (the GitHub
      URL owner) instead of a login derived from the self-declared authors list
      (plugin-repository-ui feat/publisher-by-repo-owner), so the login /
      derivedFromName / repository_owner fields on author entries are dead weight.
      
      Authors in combined.json are now passed through as plain display-only
      {name, email} credits; derive_login and the fabricated-login fallback for
      authorless plugins are gone (they now credit the repo owner by name).
      
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      
    9. πŸ”— r/reverseengineering Mellanox/Nvidia ConnectX-5 FW modification tool to enable PCIe Gen 4 on cards that shipped as Gen 3 rss
    10. πŸ”— r/reverseengineering NEW FIND! Earliest build of MWCCARM Build 0056 (NDS compiler) rss
    11. πŸ”— smol-machines/smolvm smolvm v1.7.0 release

      What's Changed

      • Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
      • Fix the pacman repo build so it packages both architectures by @BinSquare in #626
      • Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
      • docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
      • Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
      • CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
      • Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
      • feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
      • Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
      • Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
      • CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
      • Bump the workspace to 1.6.1 by @BinSquare in #641
      • Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
      • Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
      • CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
      • Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
      • Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
      • CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
      • CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
      • Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
      • release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
      • Stream the pack overlay export to disk by @BinSquare in #654
      • CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
      • feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
      • Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
      • Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
      • Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
      • Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
      • Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
      • Never LRU-evict the reference-shared pack store by @BinSquare in #666
      • Fail an image machine's start when the image pull fails by @BinSquare in #669
      • Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668
      • Cap keep-alive exec output so oversized results return a clear error instead of a frame-too-large crash by @BinSquare in #670
      • Fix file-upload body limit and clarify the oversized-exec-output guidance by @BinSquare in #671
      • CUDA fork: sync-call retry, allocation burst, multi-GPU pinning, sandboxed serve, and machine-create workload by @BinSquare in #672
      • Reload clone-worker modules byte-identical to the golden's images by @BinSquare in #673
      • Recover fork clones whose worker died, and give clone reconnects a real handshake window by @BinSquare in #675
      • CUDA 13 guest surface by @LoganGrasby in #674
      • Re-key the golden's persistent exec overlay to the clone so forks inherit filesystem state by @BinSquare in #677
      • Replay function attributes on clone-worker kernels, and print backtraces on fatal signals by @BinSquare in #676
      • nix/smolvm: bump to v1.6.13 by @BinSquare in #678
      • Route a fork clone's execs to its inherited overlay and heal the restored stale mount by @BinSquare in #680
      • Make fork clones restartable and refuse deleting a golden that still backs live clones by @BinSquare in #683
      • Advertise the CUDA 12.4 surface by default; cu13 wheels opt in via SMOLVM_CUDA_ADVERTISE by @BinSquare in #681
      • Fail a from-vm pack of a never-started machine with a clear error and stop leaking scratch dirs on failed helper boots by @BinSquare in #682
      • Enforce the exec timeout in the keep-alive container path so an image machine's exec honors its deadline by @BinSquare in #684
      • Make a provisioned local volume writable by the per-VM uid that mounts it by @BinSquare in #685
      • Stream exec output live over SSE instead of buffering the whole command to completion by @BinSquare in #686
      • Run a background exec detached inside the machine's keep-alive container so the process survives instead of dying within seconds by @BinSquare in #687
      • chore(libkrun): bump for macOS balloon free-page reclaim by @BinSquare in #689
      • Fix fork-clone serving, sm90 in-VM support, and per-replica module shipping by @BinSquare in #690
      • Enable ring transport and CUDA-graph capture for in-VM serving by @BinSquare in #692
      • Fixing some generic findings from six QA by @BinSquare in #691
      • Relaunch the workload and refresh config from the record on implicit starts by @BinSquare in #694
      • agent: idle balloon-pulse reclaim, on by default by @BinSquare in #693
      • chore(libkrun): bump for balloon cleanup and clone-reclaim persistence by @BinSquare in #696
      • Fork clones reuse the golden's extracted pack layers by @BinSquare in #703
      • Per-fork parameters: machine fork --env KEY=VALUE by @BinSquare in #705
      • Validate resources in the create-machine API so invalid cpu/memory is rejected at create by @BinSquare in #704
      • Block /boot from being mounted into a guest by @BinSquare in #706
      • Validate request env var names on create/exec/run by @BinSquare in #709
      • Take the lifecycle lock when resizing a machine by @BinSquare in #708
      • Reject cmd/entrypoint on an imageless machine create by @BinSquare in #707
      • Don't leak the internal log path when a machine has no logs yet by @BinSquare in #712
      • Remove the dead exec_machine handler and its duplicate OpenAPI exec path by @BinSquare in #716
      • Don't orphan the agent VM when an image pull fails during start by @BinSquare in #714
      • Reject duplicate guest mount targets on the HTTP create path by @BinSquare in #717
      • Validate published ports on the HTTP create path by @BinSquare in #720
      • Hold the lifecycle lock during machine export by @BinSquare in #719
      • Report the real /dev/kvm access failure on post-uid-drop boot failures by @BinSquare in #718
      • Canonicalize the volume path in the deprovision safety guard by @BinSquare in #711
      • Refuse to stop a fork base that has live clones by @BinSquare in #727
      • Validate pinned ports on fork by @BinSquare in #725
      • Validate egress CIDRs on the HTTP create path by @BinSquare in #721
      • Return a clean error instead of panicking on a NUL byte in allow-CIDR/allow-host by @BinSquare in #733
      • Reject duplicate guest mount targets on machine update by @BinSquare in #724
      • Correct the safe_unpack doc comment to match its actual symlink handling by @BinSquare in #736
      • Reject a duration whose seconds value overflows u64 in parse_duration_secs by @BinSquare in #735
      • Close a delete/fork race that could orphan a fork clone's disks by @BinSquare in #726
      • Keep an explicitly stopped machine stopped under restart policies by @BinSquare in #723
      • Register the machine /resize route by @BinSquare in #715
      • Clone graph capture-replay: forked VMs serve with CUDA graphs by @BinSquare in #695
      • Add per-fork secrets to the fork API so each clone gets its own secrets, resolved fresh per exec by @BinSquare in #731
      • Fix the CUDA guest crate builds so they compile without the host feature and on macOS by @BinSquare in #737
      • Fix fork weight sharing so clones import one copy of the weights instead of each privately copying them by @BinSquare in #741
      • Map shared weight chunks read-only so a stray post-fork base write cannot corrupt sibling clones by @BinSquare in #742
      • Bump libkrunfw to the DRM-enabled build so --gpu exposes /dev/dri by @BinSquare in #739
      • docs: describe CUDA API remoting in README by @NickyHeC in #740
      • tiny fix: machine create --from discards --mount-socket and --expose-socket by @Bnjoroge1 in #746
      • Cuda runtime fixes by @BinSquare in #747
      • Attach the machine id to the request span so failures are attributable to a machine by @BinSquare in #748
      • Name the missing credential when a registry denies the pack probe, and reuse a configured image credential for it by @BinSquare in #750
      • Accept registry credentials on machine start so private third-party images can be pulled by @BinSquare in #751
      • Refuse to resize a fork base that has live clones by @BinSquare in #728
      • Classify forking a non-forkable golden as 409, not 500 by @BinSquare in #710
      • Bump the workspace to 1.7.0 for the next engine release by @BinSquare in #752

      New Contributors

      Full Changelog : v1.6.0...v1.7.0

    12. πŸ”— r/reverseengineering /r/ReverseEngineering's Weekly Questions Thread rss

      To reduce the amount of noise from questions, we have disabled self-posts in favor of a unified questions thread every week. Feel free to ask any question about reverse engineering here. If your question is about how to use a specific tool, or is specific to some particular target, you will have better luck on the Reverse Engineering StackExchange. See also /r/AskReverseEngineering.

      submitted by /u/AutoModerator
      [link] [comments]

    13. πŸ”— r/reverseengineering Reverse engineering Dauntless 1.12.0 to restore private-server functionality - Mystic Paradox rss
    14. πŸ”— HexRaysSA/plugin-repository commits sync repo: +1 release, -1 release rss
      sync repo: +1 release, -1 release
      
      ## New releases
      - [idalib-rust-bindings](https://github.com/idalib-rs/idalib): 0.10.0
      
      ## Changes
      - [IDASQL](https://github.com/allthingsida/idasql):
        - removed version(s): 0.0.8
      
  4. July 26, 2026
    1. πŸ”— IDA Plugin Updates IDA Plugin Updates on 2026-07-26 rss

      IDA Plugin Updates on 2026-07-26

      New Releases:

      Activity:

      • augur
      • haruspex
      • ida-ios-helper
        • 066bb214: Merge pull request #24 from OmerMiz1/feature/swift-update-metadata-sh…
        • 156357c3: swift_types: Parsing access to VWT via Swift::Metadata* looks cleaner…
      • ida-pro-mcp
        • 951e6ab4: Merge blackboard-workspace: investigation workspace + IDB round-trip
        • c42f81c6: Close the loop between the workspace and the IDB.
        • 51de46ce: Turn the blackboard into a workspace that answers back.
        • 51872c9d: Rewrite the README around what the project actually does.
        • 6c9cfb3c: Stop the analysis layer from presenting invented detail as evidence.
        • 912b13c0: Correct the changelog's list of removed test files.
        • 7178ed24: Purge ghost tool entries from dev scripts and sync the docs.
        • 35d12ffd: Make the health-race test actually reject the unlocked implementation.
        • aad5c9cc: Fix five host-side safety defects and cover them with tests.
        • 57826aab: Delete the dead analysis-engine, threat-hunt, and mbagcn subsystems.
        • 6c776b88: Make the session ownership guard inheritable instead of fail-open.
      • ida_9.3_python_plugin_fixes
      • idalib
      • IDAPluginList
        • cd4b6883: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • idasql
        • 6dc26dcf: release: add v0.0.18.1 multi-SDK builds (#55)
      • qscripts
        • 9ea89e27: ci: package release as per-IDA-version zips with per-OS/arch subfolders
        • b9c82223: qscripts: multi-SDK (9.2-9.4) + Windows/Linux ARM64, updated ida-cmak…
      • rhabdomancer
      • twdll
        • 9dc4deea: refactor
        • 22224378: feat: add SetFactionLeader func with small refactor for exposing game…
    2. πŸ”— Jeremy Fielding (YouTube) Update On The Bee Chaser and WALL E rss

      Discord πŸ‘‰https://discord.gg/F3XuyhNRPc New Facebook πŸ‘‰https://www.facebook.com/profile.php? Instagram πŸ‘‰ https://www.instagram.com/jeremy_fielding/?hl=en

      If you want to join my community of makers and Tinkers consider getting a YouTube membership πŸ‘‰ https://www.youtube.com/@JeremyFieldingSr/join

      If you want to chip in a few bucks to support these projects and teaching videos, please visit my Patreon page or Buy Me a Coffee. πŸ‘‰ https://www.patreon.com/jeremyfieldingsr πŸ‘‰ https://www.buymeacoffee.com/jeremyfielding

      Social media, websites, and other channel

      Instagram πŸ‘‰ https://www.instagram.com/jeremy_fielding/?hl=en Twitter πŸ‘‰https://twitter.com/jeremy_fielding TikTok πŸ‘‰https://www.tiktok.com/@jeremy_fielding0 LinkedIn πŸ‘‰https://www.linkedin.com/in/jeremy-fielding-749b55250/ Facebook πŸ‘‰https://www.facebook.com/profile.php?id=61591852348093 My websites πŸ‘‰ https://www.jeremyfielding.com πŸ‘‰https://www.fatherhoodengineered.com My other channel Fatherhood engineered channel πŸ‘‰ https://www.youtube.com/channel/UC_jX1r7deAcCJ_fTtM9x8ZA

      Notes:

      Technical corrections

      Nothing yet

    3. πŸ”— r/reverseengineering Reverse engineering my Samsung Odyssey G5 monitor firmware (SPARC V8 scaler, hidden factory menu, dead TCON code) rss
    4. πŸ”— @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here: https://v35.us/dn6rcg5

    5. πŸ”— @binaryninja@infosec.exchange Our 10-year anniversary giveaways continue! Today, 1 very lucky winner will mastodon

      Our 10-year anniversary giveaways continue! Today, 1 very lucky winner will receive free entry to our Intro To Binary Ninja online training class. Make sure you’re subscribed to our newsletter to be entered: https://binary.ninja/10years