Ok, here's a better article from CMU's SEI. See "Binary Analysis Without Source Code".
> In general, the layout used by the Rust compiler depends on other factors in memory, so even having two different structs with the exact same size fields does not guarantee that the two will use the same memory layout in the final executable. This could cause difficulty for automated tools that make assumptions about layout and sizes in memory based on the constraints imposed by C. To work around these differences and allow interoperability with C via a foreign function interface, Rust does allow a compiler macro, #[repr(C)] to be placed before a struct to tell the compiler to use the typical C layout. While this is useful, it means that any given program might mix and match representations for memory layout, causing further analysis difficulty. Rust also supports a few other types of layouts including a packed representation that ignores alignment.
> We can see some effects of the above discussion in simple binary-code analysis tools, including the Ghidra software reverse engineering tool suite... Loading the resulting executable into Ghidra 10.2 results in Ghidra incorrectly identifying it as gcc-produced code (instead of rustc, which is based on LLVM). Running Ghidra’s standard analysis and decompilation routine takes an uncharacteristically long time for such a small program, and reports errors in p-code analysis, indicating some error in representing the program in Ghidra’s intermediate representation. The built-in C decompiler then incorrectly attempts to decompile the p-code to a function with about a dozen local variables and proceeds to execute a wide range of pointer arithmetic and bit-level operations, all for this function which returns a reference to a string. Strings themselves are often easy to locate in a C-compiled program; Ghidra includes a string search feature, and even POSIX utilities, such as strings, can dump a list of strings from executables. However, in this case, both Ghidra and strings dump both of the "Hello, World" strings in this program as one long run-on string that runs into error message text.
You cite yet another article which you clearly don't understand, and whose authors have questionable understanding themselves.
This article cites CVEs of a certain type, which were especially popular in the 2021 timeframe. These CVEs do not correspond to real vulnerabilities in real executables. Rather, they are reporting instances of rust programs violating the strictest possible interpretation of the rules of the rust language. For comparison, quite literally every single C program ever written would have to receive a CVE if C were judged by the same rules, because it isn't possible to write a C program which conforms to the standard as strictly as these Rust CVEs were requiring. CVEs of this nature are a bit of a meme in the rust community now, and no one takes them seriously as vulnerabilities. They are reporting ordinary, non-vulnerability bugs and should have been reported to issue trackers.
The whole discussion about layout order is completely irrelevant. When RE'ing unknown code you don't know the corresponding source anyways, so the one-to-many correspondence of source to layout is irrelevant. You are given the layout. You can always write a repr(C) which corresponds to it if you're trying to produce reversed source. This is no different than not knowing the original names of variables and having to supply your own.
The next objection is literally that rust does not use null-terminates strings, except the authors are so far out of their depth that they don't even identify this obvious root cause of their tools failing. Again, this has absolutely nothing to do with the reversibility of rust programs, except perhaps preventing some apparent script kiddies from figuring it out.
The authors do manage to struggle to shore, as it were, by the end of the article, and somehow they end up correctly identifying their tools and understanding and the root cause of their troubles, not Rust. I take it you didn't make it that far when you read it?
So yes, it's relevant.