The crate is currently "usable" on stable rust, despite using nightly-only feature, by enabling RUST_BOOTSTRAP=1 in build.rs. This is a very bad idea. This flag is only meant to bootstrap the compiler itself, and any other use of it is unsupported and might lead to the code breaking if/when the API changes. This is not unheard of: Nightly features aren't finalized and often changes shape prior to stabilization.

The currently used features are also not very stable, const_generics and const_fn can easily cause ICEs in the compiler or soundness issues in the final binary, due to implementation bugs.

IMO, this crate shouldn't abuse RUST_BOOTSTRAP like this. The correct way is to tell the users to use a nightly compiler. If that's not possible, the use of RUST_BOOTSTRAP should at least be called out in the README so users can make an informed decision about using this crate.

Would be useful if there was obfbytes!, which takes a byte array (whether it be b"\x2A\x2A", [42, 42] or include_bytes!("data.bin")), and encrypts+obfuscates it.

My use case is making it more difficult to find a hardcoded public key used for validation.

When decompiling a binary obfuscating with obfstr 0.2 with IDA/Hexrays 7.5, the obfuscation is immediately undone, and the XREF immediately give away the string location. See below for the source code, and the decompiler and asm output. This was tested with rust 1.48.0.

obfstr 0.1 does not suffer from this: The strings are properly obfuscated, and IDA fails to find any xrefs for it. I believe the difference comes from obfstr 0.1 having a random offset into the string, which confuses IDA, leaving its XREF analysis and automatic deobfuscators inoperable. Another issue is that the one time pad to deobfuscate the string is kept in .rodata (due to being passed as an array to the deobfuscate method) while obfstr 0.1 would only get passed the initial round key.

I imagine the fix would go like this: Change the deobfuscate method to take a random offset like obfstr 0.1 in order to break the xrefs, and generate the XOR round keys at runtime instead of compile time.

Source code:

use obfstr::obfstr;
fn main() {
    println!("aaaaaaaaaaaa");
    println!("{}", obfstr!("bbbbbbbbbbbb"));
    println!("{}", obfstr!("cccccccccccc"));
}

Currently, rustc does not pass the exact original TokenStream to proc-macros in several cases. This has many undesirable effects, such as losing correct location information in error message. See https://github.com/rust-lang/rust/issues/43081 for more details

In the future, rustc will begin passing the correct TokenStream to proc-macros. As a result, some tokens may be wrapped in a TokenTree::Group with Delimiter::None (when the tokens originally came from a macro_rules!) macro expansion.

I've determined that this change will cause your crate to stop compiling. This PR updates obfstr to be compatible with both the old and new TokenStream contents.

You can verify this PR by attempting to build your crate as follows:

rustup toolchain install nightly-2020-05-29
cargo +nightly-2020-05-29 build

This will built your crate with an older nightly build that contains the change we want to eventually roll out. On this compiler version, your crate should fail to compile without this PR, and successfully compile with this PR.

If you have any questions, feel free to ask me. See https://github.com/rust-lang/rust/issues/72622 for more details

error: prefix `L` is unknown
   --> project/src/sys_windows.rs:183:38
    |
183 |         obfstr!(L"test.dll\0")
    |                 ^ unknown prefix
    |
    = note: prefixed identifiers and literals are reserved since Rust 2021
help: consider inserting whitespace here
    |
183 -         obfstr!(L"test.dll\0")
183 +         obfstr!(L "test.dll\0")
    |

Includes breaking changes:

• Remove obflocal, obfconst, obfeq, ObfString, ObfBuffer
• Change hash to DJB2 to xor variation
• Move xref to its own module
• Remove static mut to just static hopefully the xref breaking keeps IDA at bay The problem with static mut is that it makes it hard to protect against malicious modification

Heya, I came across your article at https://casualhacks.net/blog/2020-05-31/compiletime-processing/

Was wondering if you've looked into doing this for creating compile-time hashes from strings?

For example, I'd like to be able to do const U_POSITION:u32 = hash!("u_color"); and know that it's the same value as some other usage elsewhere. Speed and avoiding collisions are important, but it doesn't need to be cryptographically secure.

obfstr 1.x currently doesn't support raw string, e.g. the following causes a panic:

obfstr!(r"do\stuff"); // Panics
obfstr!(r#"do\stuff"#); // Panics too

To fix this, obfstr-impl's string_parse should probably be updated to take a TokenStream instead of a Literal, and check each token in the stream.

Fixes #17 .

This is my latest attempt at removing RUSTC_BOOTSTRAP from obfstr, while keeping compatibility with as much of the old API as possible. I believe this version to be maximally compatible.

I think this will be ready for release. I would appreciate a second set of eyes to confirm that what I'm doing is actually safe though. In particular, that it is sound for decrypt and as_str to cast the generic parameter to a slice thanks to the constructor being unsafe.

Sadly archive on crates.io for obfstr-impl does not contain. That is resolvable in 3 simple ways: use license-file, add a symlink in the subdirectory, copy file in the subdirectory. Not sure which one you prefer, so not sending a PR.

Obfstr uses the original string as a source of entropy per invocation. A typo made it always use $ e instead of the original string.

Introduce internal __entropy to avoid unnecessary const items.

Heyo,

I just updated my project to the obfstr 4, and overall the improvements are quite nice! However, there is one small downside compared to the previous version: Obfstr 4 generates a huge block of data that xrefs every code dealing with obfuscated string in the .data block:

This is not ideal, as it gives a reverser a simple way to find all the code offsets to obfuscated strings, making the creation of an automated deobfuscation tool a bit easier.

Digging into the code, I figured that this change came from the new xref code. After reading over #44, I eventually figured that this was done to break Ghidra's constant folding which defeated much of the obfuscation.

So I tried to take a different approach here: Instead of storing the xref offsets in the .data, I figured they could be stored in a dedicated function marked inline(never). In theory, ghidra will not be able to "see through" the call, and thus break the constant folding.

Here's the result:

This approach has the other benefits of not using the .data segment, which should make code integrity checks properly verify that the xref offsets aren't tampered with.