How difficult is a kotlin native executable to backwards engineer?

# kotlin-native

[spierce7]

How difficult is a kotlin native executable to backwards engineer?

[Landry Norris]

Should be about the same as any other executable. If you use nm -C, you can find out that an executable is a Kotlin executable because of the stdlib. In theory, if you wanted to obfuscate your code, you could add CName annotations to your methods. It would be interesting to see a gradle plugin that does that.

[Landry Norris]

Note that CName only affects the name of the symbols in the binary. You could obfuscate the name with that, but your Kotlin code would still be able to use the real name.

[spierce7]

Should be about the same as any other executable.

how backwards engineerable are executables normally?

[Landry Norris]

It seems to be out of reach of an amateur like me, but I’d imagine without name obfuscation it wouldn’t be our of reach of someone who really knew what they were doing. Obfuscating symbols should at least make it harder to reverse engineer.

[Landry Norris]

Either way, you’d need a fair bit of time and knowledge to reverse engineer a binary.

[spierce7]

I thought name obfuscation happened in production executables. That’s what the dsym files etc are for, right?

[Landry Norris]

Depends on the platform and build toolchain. I’ve really only looked deep into linuxX64 binaries and some macArm64 binaries built with the command line compiler, and those had the raw symbol names. If you’re referring to iOS, it may be different.

[spierce7]

huh - thanks

[spierce7]

Seems completely unnecessary / wrong to keep symbol names in a production / release application

[Landry Norris]

I think the assumption is that there’s other tools to obfuscate symbols before you release.

[Landry Norris]

Also, keep in mind that my testing was with the command line compiler (konanc), not the gradle plugin.

[spierce7]

ah, that makes sense