I'm writing a library with FlasCC which is wrapped in an actionscript class. That is users of the library should call functions of the wrapper class, and the functions of the class will call the actual C++ functions.
But there is a problem, all functions and CModule are public. So the users can actually call the C++ functions themselves, and can access the core memory directly.
Is there a way to avoid this?
There is this, from the documentation (apologies if you've already read it):
FlasCC is not designed to be an obfuscator for either ActionScript or C/C++ code. Although the generated ActionScript bytecode should be no easier to reverse engineer than natively compiled machine code the FlasCC engineering team makes no strong claims about this, nor do they test whether this is true.
By default the mangled C++ name of every source function will be trivially visible in both the decompiled output and also in ActionScript debugger and profilers. To hide the names of any generated C/C++ functions you can pass
-fllvm-opt-opt=-strip to gcc so that any function names not listed in your exports.txt file will be renamed to a symbol of the form
__unnamed_N. Functions that need to be called from ActionScript, which you must protect by listing in exports.txt, will not be renamed.
For true obfuscation you will need to find a third party solution that either obfuscates the LLVM bitcode or the ActionScript bytecode in the final SWF. A search on the web should yield plenty of results for SWF obfuscators, but the FlasCC engineering team has not investigated which ones are reliable.
To understand the problem from the other side you might want to play around with various SWF decompilers and ActionScript bytecode disassemblers to get a better understanding of what exactly is in a SWF and how easy/hard it is to extract the various components from it.
My reading of this suggests that the answer to your question is basically, "No, but you can try some third-party obfuscators"...FlasCC team, please correct or clarify if this is not accurate...