🏡

June 27, 2026
1. 🔗 r/reverseengineering Reverse Engineering dobreprogramy.pl Bundler - Extracting Clean Download URLs Without Executing Adware rss
  
  submitted by /u/ContestOk9541
  [link] [comments]
2. 🔗 Locklin on science Statistical picture of Quantum Mechanics rss
  
  The statistical picture of quantum mechanics is an idea I had in my mind more or less as the correct picture, while occasionally simultaneously holding the gaseous nonsense that the Schroedinger equation somehow describes things the individual particles are doing. Stated simply, the modulus of the solutions to the Schroedinger equation describe a statistical ensemble […]
3. 🔗 r/reverseengineering I Reverse Engineered An Undocumented Laptop's Embedded Controller rss
  
  submitted by /u/feusx
  [link] [comments]
4. 🔗 r/reverseengineering I reverse engineered DeepSeek Chat into a free OpenAI compatible API (V4 & R1 models, no API key, no billing) rss
  
  submitted by /u/whatisonearth
  [link] [comments]
5. 🔗 HexRaysSA/plugin-repository commits sync plugin-repository.json rss
```
sync plugin-repository.json

No plugin changes detected
```
6. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss
```
sync repo: +1 release

## New releases
- [ida-settings-editor](https://github.com/williballenthin/ida-settings): 1.2.1
```
7. 🔗 r/reverseengineering GitHub - vichhka-git/renef-skills: Agent Skill (Claude Code + OpenCode) for operating renef.io — Android ARM64 dynamic instrumentation: hook native/Java, patch memory, trace syscalls, bypass SSL pinning/root detection; port Frida & GameGuardian scripts to renef Lua. rss
  
  submitted by /u/ResponsiblePlant8874
  [link] [comments]
June 26, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-26 rss
  IDA Plugin Updates on 2026-06-26
  
  New Releases:
  - ida-settings v3.5.1
  Activity:
  - ida-settings
    
    e4f483c1: Merge pull request #25 from williballenthin/add-idc-show-function
    
    f674ad43: v3.5.1
    
    03429519: v3.5.0
    
    14ab204d: fix: resolve remaining ruff lint warnings
    
    e250c145: fix: ruff formatting
    
    50156100: plugin: rename IDC function to ida_settings_show_plugin_settings
    
    96edbffd: plugin: add ida_settings_show IDC function for cross-plugin integration
2. 🔗 r/reverseengineering Im Trying To Reverse GTAIV And Including Scripts, Here Is My Progress rss
  
  submitted by /u/Glittering_World5725
  [link] [comments]
3. 🔗 r/reverseengineering Project IGI (1999) reverse engineering - partial docs, honest about gaps rss
  
  submitted by /u/Inner-Combination177
  [link] [comments]
4. 🔗 Anton Zhiyanov Solod v0.2: Networking, new targets, friendlier interop rss
  Solod (So) is a system-level language with Go syntax, zero runtime, and a familiar standard library. It's designed for two main audiences:
  - Go developers who want low-level control and zero-cost C interop without having to learn Zig or Odin.
  - C developers who like Go's style.
  The previous version (v0.1) focused on porting core Go stdlib packages and providing convenient C interop. At the end of that post, I said the next release would focus on networking, concurrency, or both. Now, networking is here — the v0.2 release I'm sharing today includes support for TCP, UDP, and Unix domain sockets. Concurrency is still planned for the future, so for now, servers handle one connection at a time.
  
  This release also lets you compile So to more targets, like 32-bit platforms, WebAssembly, and bare metal. And C interop even smoother!
  
  Networking • TCP server • TCP client • Deadlines • IP addresses • Targets • Interop • Stdlib • Wrapping up
  
  Networking
  
  The main feature in v0.2 is the net package. It's a simplified version of Go's net package which supports the three most commonly used transports:
  - TCP (networks tcp, tcp4, tcp6) via ResolveTCPAddr, DialTCP, and ListenTCP, with the TCPConn and TCPListener types.
  - UDP (networks udp, udp4, udp6) via ResolveUDPAddr, DialUDP (a connected socket), and ListenUDP (an unconnected socket with ReadFrom/WriteTo).
  - Unix domain sockets (unix for streams, unixgram for datagrams) via ResolveUnixAddr, DialUnix, ListenUnix, and ListenUnixgram.
  The API mirrors Go closely, so most of it will feel familiar. The big difference is that So has no goroutines, so there's no concurrent server support — you accept and serve connections sequentially. More on that in a moment.
  
  TCP server
  
  Let's build a classic: an echo server that accepts a connection, reads a message, and sends it back.
```
package main

import "solod.dev/so/net"

func main() {
    // Resolve the local address to listen on.
    laddr, err := net.ResolveTCPAddr("tcp", "127.0.0.1:8080")
    if err != nil {
        panic(err)
    }

    // Start listening on the local address.
    ln, err := net.ListenTCP("tcp", &laddr)
    if err != nil {
        panic(err)
    }
    defer ln.Close()
    println("listening on", "127.0.0.1:8080")

    // Accept connections and serve them in a loop.
    for {
        conn, err := ln.Accept()
        if err != nil {
            panic(err)
        }
        serve(&conn)
    }
}

// serve reads one message from the connection, echoes it back,
// and closes the connection.
func serve(conn *net.TCPConn) {
    defer conn.Close()

    var buf [256]byte
    n, err := conn.Read(buf[:])
    if err != nil {
        return
    }
    conn.Write(buf[:n])
}



listening on 127.0.0.1:8080
```
  If you've written a TCP server in Go, this should look familiar — ListenTCP, an Accept loop, and Read/Write on the connection. The only thing missing is a go serve(conn): without goroutines, each connection is handled to completion before moving on to the next Accept.
  
  TCP client
  
  The client starts the connection using DialTCP, then uses Write to send a request and Read to get the reply:
```
package main

import "solod.dev/so/net"

func main() {
    // Resolve the server address.
    raddr, err := net.ResolveTCPAddr("tcp", "127.0.0.1:8080")
    if err != nil {
        panic(err)
    }

    // A nil laddr lets the system choose the local address.
    conn, err := net.DialTCP("tcp", nil, &raddr)
    if err != nil {
        panic(err)
    }
    defer conn.Close()

    // Send a request and read the reply.
    conn.Write([]byte("hello"))

    var buf [256]byte
    n, err := conn.Read(buf[:])
    if err != nil {
        panic(err)
    }
    println(string(buf[:n]))
}



hello
```
  UDP and Unix domain sockets work in a similar way. For UDP, an unconnected ListenUDP socket uses ReadFrom to get data and the sender's address, and WriteTo to send a reply. For Unix sockets, there are ListenUnix (stream) and ListenUnixgram (datagram).
  
  Deadlines
  
  By default, Accept, Read, and Write are blocking. In Go, you'd typically use goroutines and contexts to prevent getting stuck forever. Since that's not available in So (yet), every connection and listener supports deadlines instead:
```
// Give the client 5 seconds to send something.
conn.SetReadDeadline(time.Now().Add(5 * time.Second))

n, err := conn.Read(buf[:])
if err == net.ErrTimeout {
    // The client went quiet; drop the connection.
    return
}
```
  SetDeadline, SetReadDeadline, and SetWriteDeadline are available on TCPConn, UDPConn, UnixConn, and listener types. When the deadline passes, any pending call fails with net.ErrTimeout. If you don't set a deadline, a blocked call will wait forever. This isn't concurrency, but it's enough to keep a single-threaded server responsive.
  
  IP addresses
  
  Along with net, v0.2 ports Go's net/netip package, which provides small, allocation-free value types for IP addresses. Addr represents an IP address, AddrPort combines an IP address with a port, and Prefix is an IP with a prefix length (a CIDR block):
```
addr, err := netip.ParseAddr("192.168.1.10")
if err != nil {
    panic(err)
}
println(addr.Is4())            // true

ap := netip.AddrPortFrom(addr, 8080)
println(ap.Port())             // 8080

prefix := netip.MustParsePrefix("192.168.1.0/24")
println(prefix.Contains(addr)) // true
```
  These are simple value types that don't use any heap allocation, which fits well with So's explicit-memory approach. The net package also provides SplitHostPort and JoinHostPort functions to help you work with host:port strings.
  
  New targets
  
  Solod compiles to plain C, which (in theory) means it can target anything a C compiler can. Because of this, v0.2 adds new targets:
  - 32-bit platforms. The compiler and stdlib now work correctly on 32-bit platforms, where int and pointers are narrower.
  - WebAssembly (WASI). You can compile a So program to wasm32-wasi and run it under any WASI runtime.
  - Freestanding mode. So programs can run on bare-metal systems without any C standard library. No libc means no malloc, but you can use mem.Arena instead.
  Here's the complete toolchain you need to build a freestanding wasm32 binary using zig cc:
```
export CC="zig cc"
export CFLAGS="-Oz --target=wasm32-freestanding -nostdlib -Wl,--no-entry -Wl,--export=main"
so build -o main.wasm .
```
  A large part of the standard library (bytes, strings, strconv, slices, maps, math, encoding/binary, and more) works just fine in freestanding mode. For more details, check out the freestanding guide.
  
  Friendlier interop
  
  A bunch of smaller changes make Solod nicer to write.
  
  Three new directives for low-level work, all documented in the interop guide:
```
//so:volatile
var counter int       // emits a C volatile

//so:thread_local
var perThread int     // emits C11 _Thread_local

//so:attr packed
type header struct {  // emits __attribute__((packed))
    version byte
    length  int
}
```
  so:attr works with variables, constants, types, and functions. You can use it on multiple lines, and the attributes will stack. For example, //so:attr aligned(16) will combine with //so:attr packed.
  
  Type aliases. So now supports Go-style type aliases:
```
type Byte = uint8
```
  Numeric C types. The so/c package now includes named types for C's numeric types — Int, UInt, Long, Short, UChar, LongLong, and others. When you declare an extern function, you can use the actual C types in its signature instead of trying to guess the correct fixed-width Go type for your platform.
  
  Third-party packages. You can now add external So packages using go install or by vendoring, and you can organize your own code into multiple modules. So doesn't have a real package ecosystem yet, but it's a good start.
  
  Better diagnostics. By default, panic messages report the C file and line. Pass --track-source to report the original So source location instead:
```
so run --track-source .
```
  There's also an optional --check-nil flag that adds nil-pointer checks when accessing struct fields and calling interface methods. This way, if there's a bad dereference, the program will panic cleanly instead of causing a segmentation fault. Both options are off by default to keep the generated code more readable.
  
  More stdlib
  
  Beyond net and net/netip, v0.2 adds a few more packages:
  - encoding/hex — hex encoding and decoding, including Dump for hexdump-style output.
  - uuid — generating and parsing UUIDs (v4 and v7), with random components from a cryptographically secure source.
  And a small but handy update to memory management: mem.Arena.Free now reclaims the last allocation if you give it the matching pointer. It's a minor optimization, but it means a quick alloc/free pair on an arena no longer wastes space.
  
  Stdlib documentation
  
  Wrapping up
  
  With v0.2, Solod has evolved from just "command-line tools and C glue" into something you can actually use on a network — like a TCP or UDP server, a small protocol client, or a Unix-socket daemon. The new targets (32-bit, WASM, freestanding) mean the same code can now run in more places, even down to bare metal.
  
  The big thing that's still missing is concurrency. A server that handles requests one at a time works for some tasks, but a real network service needs to manage many connections at once. That's the obvious goal for v0.3 — adding some kind of concurrency, along with the stdlib packages that support it.
  
  If you're interested, take a look at So's readme — it has everything you need to get started. Or try So online without installing anything.
5. 🔗 MetaBrainz Welcome Summer of Code 2026 contributors! rss
  
  We are excited to announce the 7 GSOC participants working with us this summer on MetaBrainz projects!
  Our apologies for not publishing this sooner, in this complicated first part of the year we simply forgot the announcement, but rest assured the work is progressing on all projects.
  
  As always, the selection process was incredibly tough. We received a great batch of proposals and had a limited number of slots.
  We want to sincerely thank everyone who took the time to meet our community and submit a proposal with us!
  
  The whole list of selected proposals can be found on the GSOC website but here is a TL;DR breakdown:
  
  ListenBrainz proposals:
  
  Integrate MusicBrainz events into ListenBrainz
  
  (Shirsak)
  
  MusicBrainz has data about past and upcoming concerts that ListenBrainz users can't see yet. This project will bring live music events directly into ListenBrainz, allowing you to discover shows tailored to your favorite artists.
  
  Compose Multiplatform Migration of ListenBrainz-Android
  
  (Nirvan)
  
  Currently, ListenBrainz has a native Android app but no iOS version. This project will migrate the app to a single, shared codebase using Kotlin Multiplatform. This means future features and bug fixes will launch on both Android and iOS at the same time.
  
  Playlists Sorting and Organization
  
  (Yateen)
  
  Giving ListenBrainz playlists a massive user-experience upgrade. Users will soon be able to search through playlists, organize them using custom tags, sort tracks (by artist, title, or date added), and convert their MusicBrainz collections straight into playlists.
  
  MusicBrainz proposals:
  
  Modernize search storage format for the MusicBrainz database
  
  (Junaid)
  
  Cleaning up the under-the-hood engine that powers MusicBrainz search (Solr). By upgrading internal configurations and removing data redundancy, this project will optimize performance and make searching for music faster and more efficient.
  
  GraphQL Server as a Musicbrainz API Alternative
  
  (Sreehari)
  
  Building a fast, modern alternative way for external developers to request MusicBrainz data. This makes it significantly easier and more efficient for third-party developers to build apps using our database.
  
  BookBrainz proposals:
  
  Set Up BookBrainz for Internationalization
  
  (Garv)
  
  Breaking down language barriers! BookBrainz is currently English-only. This project lays the technical groundwork to support multiple languages and sets up a BookBrainz project on translations.metabrainz.org where volunteer translators can start translating the site immediately.
  
  Development of a new Calibre plugin for BookBrainz
  
  (Waqib)
  
  Connecting BookBrainz with Calibre (the popular e-book management software). This plugin will allow Calibre users to automatically pull book metadata and collections directly from BookBrainz to organize their personal digital libraries.
  
  What if you’re not in GSoC 2026?
  
  Reading this and feeling inspired for contributing to the code still? Volunteer contributors are very welcome all year round even though we might have slightly less time available to help you during the summer. It is also putting you in an ideal situation for applying to next year’s GSoC. You can find some tips for applying to GSoC with us in one of our previous posts. When you are ready, join us on the MetaBrainz Matrix Channel and showcase your initiative and your skills!
6. 🔗 r/reverseengineering Reversed the game I grew up on, COD: BO2 Zombies and made a game cheat for it rss
  
  submitted by /u/damnbruuh
  [link] [comments]
June 25, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-25 rss
  IDA Plugin Updates on 2026-06-25
  
  New Releases:
  - ida-ios-helper 1.0.23
  - plugin-ida v3.0.2
  Activity:
  - ida-ios-helper
    
    449815b9: Merge pull request #21 from gilboz/bugfix/objc-sugar-line-merging
  - ida_ifl
    
    2dbdb564: Merge pull request #21 from Jah-yee/fix/refered-typo
  - plugin-ida
    
    277b3cb4: chore: Release v3.0.2 (#18)
    
    6548e165: fix: Pick PySide6 directly on IDA 9.2+ to avoid PyQt5 shim (#17)
    
    a5f5c2cd: chore(deps): Bump actions/checkout from 6.0.3 to 7.0.0 (#16)
2. 🔗 r/reverseengineering Luma: A new workspace for Frida rss
  
  submitted by /u/oleavr
  [link] [comments]
3. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss
```
sync repo: +2 releases

## New releases
- [hrtng](https://github.com/kasperskylab/hrtng): 3.9.105
- [threatray](https://github.com/threatray/plugin-ida): 3.0.2
```
4. 🔗 @HexRaysSA@infosec.exchange IDA 9.4 teasers continue with two new navigation features: mastodon
  
  IDA 9.4 teasers continue with two new navigation features:
  1️⃣ Jump Anywhere is now the default G dialog — search functions, names, types, and segments in one box with live previews.
  2️⃣ Pathfinder, a new tool for asking "can this code reach that?" directly from the xref graph.
  
  Read the blog for the full breakdown.
  👉 https://hex-rays.com/blog/ida-9.4-smarter-navigation-and-quality-of-life- improvements
5. 🔗 MetaBrainz Upcoming changes to user accounts and authentication rss
  We are in the process of moving user accounts, authentication and OAuth applications from the MusicBrainz website to the MetaBrainz website.
  This centralizes our account management between all the *Brainz projects, along with some security improvements.
  
  Historically, all accounts were managed on the MusicBrainz website simply because it existed before the MetaBrainz Foundation itself. However, creating a MusicBrainz account just to use ListenBrainz or our other sister projects doesn't make much sense.
  We are changing this legacy setup to improve the user experience and bring better cohesion to the entire MetaBrainz ecosystem.
  
  Here is what you need to know about how this transition affects you:
  
  Changes for users
  
  If you use MusicBrainz, ListenBrainz, BookBrainz or any other *Brainz project, most of your experience won't change. However, note the following updates:
  - Account login/creation: When logging in or creating a new account, you will be redirected to the MetaBrainz website to complete the process.
  - Login page localization: We are currently translating the new login pages. Your preferred language might not be fully available yet while this work is in progress. If you can help with translation, please head over to our translation platform.
  - Digest authentication in the web service (API) is deprecated:
    
    Existing users: If you already use digest authentication, it will continue to work normally for the time being, using whatever account password you had at the time of the migration.
    
    Password changes: If you update your account password, the new password cannot be used for digest authentication. (The old password will continue to work until you generate a token; see below.)
    
    Digest authentication tokens: We're adding support for tokens which can be generated from the Applications page. The token should be used in place of your account password in applications that ask for it. As a user, it's strongly recommended that you generate a token if you're currently providing your account password to an application.
    
    New users: Digest authentication is disabled by default. New users must generate a digest authentication token from the Applications page.
  Changes for developers
  
  If you maintain an application or script that integrates with MusicBrainz, you will need to update your authentication flow:
  - OAuth applications : the OAuth applications page will move to the MetaBrainz website after the migration: https://metabrainz.org/profile/applications
  - New auth URLs: The endpoints for authentication are migrated as well. You will need to update these base URLs in your code: https://**music** brainz.org/oauth2/... -> https://**meta** brainz.org/oauth2/...
  - Existing OAuth applications currently set up on musicbrainz.org are deprecated. They will continue to work through the https://musicbrainz.org/oauth2/ endpoint for the time being, but will not be migrated to MetaBrainz OAuth. New applications must be created on MetaBrainz.
  - Mandatory PKCE: Proof Key for Code Exchange (PKCE) is now mandatory for all OAuth flows to ensure better security.
  - Drop digest auth: Move your applications from legacy digest authentication to OAuth. As a transitional measure, you can inform your users about generating a digest auth token.
  Note on
  
  DIGEST Auth TOKENS
  
  While MusicBrainz digest authentication tokens will be supported as a transitional measure, they will be removed in the future. OAuth is strongly preferred and recommended for all applications.
  
  Timeline
  - Monday July 6th : account migration
    
    We will have a short downtime for all MetaBrainz services while we transfer user accounts
  - July 1st 2027 : 1 year after the migration, digest authentication and MusicBrainz Oauth apps will be removed
    
    The deprecated digest authentication will be retired and this authentication flow will stop working. Please migrate your applications to use OAuth.
    
    Existing OAuth applications created on MusicBrainz will stop working. Please create a new OAuth application on MetaBrainz
  If you run into issues or have questions, do let us know on the community forums or reach out on Matrix/Discord/IRC.
6. 🔗 r/reverseengineering VAXD now with support for ARM rss
  
  submitted by /u/Bicurico
  [link] [comments]
7. 🔗 Andrew Healey's Blog A Tiny Compiler for Data-Parallel Kernels rss
  
  Exploring how compilers lower ordinary loops into explicit data-parallel kernels.
8. 🔗 Console.dev newsletter Go Micro rss
  
  Description: Agent harness & service framework.
  
  What we like: Supports a variety of runtime primitives including model routing, memory, tools, guardrails, and durable workflows. Automatically creates MCP gateway. Built-in A2A gateway. All abstractions are Go interfaces to make it easily pluggable. Orchestrates multiple services with a local dev server and deploy tooling.
  
  What we dislike: Encourages microservices, which are often overkill - especially at the beginning of a new project.
9. 🔗 Console.dev newsletter Hasp rss
  
  Description: Local secret broker.
  
  What we like: Local-first secret storage with project bindings to allow access to specific secrets. Can launch apps with the secrets injected or act as a broker with on-demand supply of secrets. Time-bounded grants. First-class support for agents to request secrets. Access auditing.
  
  What we dislike: Local-first is by design in v1, but also a limitation because there’s no control plane or cloud sync.
10. 🔗 Rust Blog The many journeys of learning Rust rss
  
  This is another post in our series covering what we learned through the Vision Doc process. We previouslydescribed the overall approach and what we learned about doing user research, we explored what people love about Rust, dug into what it takes to ship safety-crticial Rust, and described some of the major challenges that people face when using Rust.
  
  In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.
  
  As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.
  
  Many paths to needing Rust
  
  The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.
  
  "Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO
  
  Rust learning resources
  
  Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.
  
  "I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier
  
  Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.
  
  "The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant
  
  "Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage
  
  These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.
  
  "We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry
  
  Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.
  
  Beginner stumblings and unlearning habits
  
  It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.
  
  "There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)
  
  "In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT
  
  We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.
  
  "I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab
  
  Learning to work with the borrow checker
  
  We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.
  
  The compiler as teacher
  
  Rust's diagnostics did the teaching on their own, especially around lifetimes.
  
  "If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs
  
  "Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer
  
  Learning by doing
  
  Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.
  
  "I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust
  
  "Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider
  
  Letting go of "clone guilt"
  
  Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.
  
  "On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university
  
  The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.
  
  We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.
  
  Multi-paradigm, but not the OOP some are used to
  
  The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.
  
  "Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM
  
  "I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company
  
  Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.
  
  "My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries
  
  "The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO
  
  Teaching Rust in academia
  
  We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.
  
  "I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust
  
  The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.
  
  What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.
  
  Learning using LLMs
  
  Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.
  
  "I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate
  
  "I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust
  
  For some learners, an LLM is just another way to find answers, no different than a search engine.
  
  "So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space
  
  One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.
  
  "At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company
  
  We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.
  
  Organizational considerations for Rust learners
  
  We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.
  
  "[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)
  
  "So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider
  
  "We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation
  
  Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.
  
  "They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM
  
  The community and helping each other aspect seems to grow bonds as organizations mature.
  
  "Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company
  
  Silent attrition
  
  We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.
  
  "All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor
  
  There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.
  
  "We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)
  
  We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.
  
  "Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust
  
  While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.
  
  "People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider
  
  Feedback on near-bounces from survey
  
  We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:
  
  "I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A
  
  Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.
  
  One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.
  
  Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.
  
  Need more focused work on silent attritrion
  
  The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.
  
  Conclusions
  
  Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.
  
  That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.
  
  What seems worth trying
  
  Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.
  
  Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.
  
  Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.
  
  Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.
  
  How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.
  
  Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.
  
  What we still don't know
  
  The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.
  
  We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.
  
  The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.
June 24, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-24 rss
  IDA Plugin Updates on 2026-06-24
  
  Activity:
  - ghidra
    
    6f1a6eaa: GP-0: Log error when populate FID has language mismatch (Closes #9287)
    
    3b22c3a0: Merge branch 'GP-0_ryanmkurtz_PR-9304_pgalbraith_fix_9303-npe'
    
    c49db1f7: Merge remote-tracking branch 'origin/patch'
    
    4f02c88d: Merge remote-tracking branch 'origin/GP-941_ghidorahrex_sparcv9_reg_d…
    
    2c94b3a9: Merge remote-tracking branch 'origin/GP-6966_d-millar_autosetup-SQUA…
    
    89378dfc: GP-6523: Reducing ComLoader false positives
    
    00320b3a: 9303: aligning fix with #9188
    
    bd725326: GP-6966: fix for tests
    
    bab81cb6: GP-941: Correct SparcV9 register operand display to be consistent
    
    58c44a03: Merge branch 'GP-7001_ryanmkurtz_pyghidra' (Closes #9288)
    
    d36e9af5: GP-7001: PyGhidra doesn't swallow GhidraScript exceptions anymore
    
    bf1f42fc: 9303: Varnode.High NP gate in ForceUnionAction.findUnion
  - ida-ios-helper
    
    8a8fc417: [objc] fix objc_sugar bug that merged a line into a line that is erased
2. 🔗 r/reverseengineering Fixing the soundtrack in Disney’s Aladdin for DOS rss
  
  submitted by /u/alberto-m-dev
  [link] [comments]
3. 🔗 r/reverseengineering Linux on an ipod touch 2g. Be the change you want to see. rss
  
  submitted by /u/Greenlinkx
  [link] [comments]
4. 🔗 r/reverseengineering Reverse-engineered the Artiphon Orba 2's control protocol (MIDI + SysEx over USB/BLE), spec + Python/JS reference libs rss
  
  submitted by /u/Agreeable-Celery4938
  [link] [comments]
5. 🔗 @binaryninja@infosec.exchange We are live! Tune in now for a walkthrough of Zenyard + Binary Ninja on a real mastodon
  
  We are live! Tune in now for a walkthrough of Zenyard + Binary Ninja on a real target! We’re covering whole-binary analysis, file-wide renaming, multi-file analysis, and asking grounded agent questions with full-binary context. https://youtube.com/live/JG15oxrWgp0?si=enCtsPERsEIvJgOP
6. 🔗 r/reverseengineering W1R3L355 the reverse framework rss
  
  submitted by /u/himmyfox
  [link] [comments]
7. 🔗 Jamie Brandon I'm not a cat rss
  
  (empty)

generated: June 27, 2026 at 21:22:09

IDA Plugin Updates on 2026-06-26

New Releases:

Activity:

Networking

TCP server

TCP client

Deadlines

IP addresses

New targets

Friendlier interop

More stdlib

Wrapping up

ListenBrainz proposals:

Integrate MusicBrainz events into ListenBrainz

Compose Multiplatform Migration of ListenBrainz-Android

Playlists Sorting and Organization

MusicBrainz proposals:

Modernize search storage format for the MusicBrainz database

GraphQL Server as a Musicbrainz API Alternative

BookBrainz proposals:

Set Up BookBrainz for Internationalization

Development of a new Calibre plugin for BookBrainz

What if you’re not in GSoC 2026?

IDA Plugin Updates on 2026-06-25

New Releases:

Activity:

Changes for users

Changes for developers

Note on

Timeline

Many paths to needing Rust

Rust learning resources

Beginner stumblings and unlearning habits

Learning to work with the borrow checker

The compiler as teacher

Learning by doing

Letting go of "clone guilt"

Multi-paradigm, but not the OOP some are used to

Teaching Rust in academia

Learning using LLMs

Organizational considerations for Rust learners

Silent attrition

Feedback on near-bounces from survey

Need more focused work on silent attritrion

Conclusions

What seems worth trying

What we still don't know

IDA Plugin Updates on 2026-06-24

Activity: