I was wondering if it is possible to use rebar3 in a way that the machine having the tool built in erlang, wouldn’t be able to run something like “console” and obtain information about the modules that are included in the tool.
For example, one of the erlang books had something like this to run the compiled version of the program: _build/default/rel/module_name/bin/module_name console
And through this command, you would have a running erlang shell, where you would be able to execute something like; application:get_applications()
Can we use rebar3 to build an erlang program where the user of this program wouldn’t be able to obtain any information about the sensitive business parts in the source code?
And through this command, you would have a running erlang shell, where you would be able to execute something like; application:get_applications()
Regardless of build system used, rebar3 or otherwise, the answer is no: you cannot reliably hide OTP applications or modules used in the release. Any build system produces a directory structured according to the OTP appliction standard. It isn’t even necessary to run any code in the console to find what OTP applications or modules are used in the release; it’s enough to inspect the files on disk. One module corresponds to one .beam file, and one application corresponds to one .app file.
Moreover, since Erlang supports apply(ModuleName, FunctionName, Args) call-style, so all module names and exported function names are kept in memory, allowing curious observer to dump memory of BEAM process and inspect the corresponding tables.
Your best chance at hiding the “sensitive business parts” is to use encrypt_debug_info compiler option. That is, honestly, enough for your typical proprietry code that doesn’t try to hide GPL violations.