Is it possible to obfuscate the method calls within a production application? I’m noticing I can sti...

# kotlin-native

[spierce7]

Is it possible to obfuscate the method calls within a production application? I’m noticing I can still look at all the method calls via Strings <exe> | grep -i <name of module>

[ephemient]

https://manpages.debian.org/strip.1.html just like all native binaries

[spierce7]

oh - I didn’t know. What are the effects of removing this information?

[spierce7]

This seems like something the release compilation process would do for me

[ephemient]

it removes debugging information as well

[ephemient]

why should it? the JVM compilation process doesn't, and most traditional (non-Kotlin) native compilations don't either

[spierce7]

If I get a crash in prod, can I still get valid stack traces?

[ephemient]

no

[Landry Norris]

There’s a trade-off between having the symbols obfuscated and having them accessible. You would need a tool that keeps some map of the obfuscated symbols to the original and you’d have to keep this map. I don’t know of any tools like this off the top of my head, since I mainly work with mobile, with desktop as a side hobby, but I’m sure they exist.

[ephemient]

strip doesn't obfuscate symbols, it removes all unused external symbols. functions used internally can still call each other by relative address, but then stacktraces will only have absolute addresses, which cannot be easily mapped back to the symbol names unless you objcopy the debug info out before stripping and collect more than just the stack trace (either a core dump, or at least the memory mapping)

[Landry Norris]

Interesting. I’ll have to learn more about native binaries.

[spierce7]

@ephemient Can this be used with mac kexe’s as well?

[ephemient]

strip: macos has a mach-o version that I expect to work the same, as it's a standard part of the unix development environment
split debug: I have no idea, I only know about this implementation in the GNU toolchain