Any way to obfuscate the `file!()` macro

help
1

I use tracing for logging.
It prints file name on error, and it helps me a lot to debugging problems from users.

However, I am required to remove the path provided by file!() macro,
the Rust executable, due to various reasons.

Is there any way to obfuscate the file!() macro?

  1. The path should not be in the string table of the Rust executable
  2. The path should never appears in memory when the program is running
  3. Neither absolute nor relative path are allowed.
  4. Some formed of obfuscated path should be printed instead, and I can transform it back to the real path, by some other unreleased tools

I know I can create and use some other file! like macro,
but I want also make the obfuscation works for the 3rdparty crates without modifying their source code.

My possible solutions:

  1. Possible to do this using proc macro? I don't know. Even this works, this not working for 3rdparty crates, but this can solve path problems in my own workspace.
  2. Add many --remap-path-prefix options to rustc, for all possible path of .rs files that Rust may access. I think this works, but this is very complicated to setup.
  3. Modify the string inside executable post compilation, but I am afraid that this may damage the file
  4. Hook the Rust compiler. Is this possible?
2

(2) is probably the best way until trim-paths stabilizes.

Well, actually the best way IMO is to use a sanitized/sandboxed build environment. But modulo that...

3 Likes
3

Can you elaborate a bit on why you have this requirement? It would be very difficult to satisfy it as framed: option 2, manually remapping the name of every file in every crate in your program, is the most promising way to do what you have said as you've said it. I am hoping that a more complete understanding of why you're doing this may help us figure out a more practical alternative.

Put another way, what is it about the string "src/main.rs" that you object to?

4

Just want to make it harder for reverse engineering.

The string of file! contains the name and version of open-sourced crates,
make it much easier for reverse engineering.

Put another way, what is it about the string "src/main.rs" that you object to?

I didn't get what you mean, but I think src/main.rs is okay to keep, because it does not provide project specific information

1 Like
5

I guess the point is, you don't need to remap the path for every file, but only for every crate at most.

6

To be clear, most OSS licenses require attribution anyway, so anyone using your software must have access to the names and other information required by each dependency’s license.

1 Like
7

This is true, but I would like to remove the version information

8

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.