I've been doing a lot of reading on V8 Bytecode, specifically Bytenode and Electron-Vite's implementation, and how they are advertised as a way to protect source code, but that doesn't actually seem to be the case.
Reading this stackoverflow post suggests that decompiling Bytecode would be possible due to being able to see V8's JS-to-bytecode compiler, thus, being able to reverse the operation.
Alongside that, it seems a decompiler was actually created, and is available here. Although it is outdated, I'm guessing it could be done again with updated versions of V8. This article describes the process used to create the decompiler and seems to have a good understanding of the inner workings of the interpreter, and, without that insight, it seems it would've been much harder to create the decompiler.
My question is this, if someone didn't know how the interpreter worked, would V8 bytecode be un-decompilable and considered "secure"? Secure here meaning the same as modern day encryption, i.e. the time to brute force / guess how the interpreter worked would be so long that it is considered secure.
If somehow I didn't know how the interpreter worked, would V8 bytecode be un-decompilable and considered "secure".
No.
Actually, taken literally, yes, building the decompiler is not possible without understanding how the interpretation works. However, understanding how an interpreter works does not require it to be open-source. That does definitely help, but it would also be possible to reverse-engineer the interpreter to gain this understanding without source code or documentation access. Maybe decompile the interpreter executable first :-) This is always possible to do as long as you are able to execute the (compiled) JS program, given to you as bytecode plus interpreter executable.
This has nothing to do with brute-forcing, and is not comparable to cryptographical security - there is only obfuscation. It's straightforward engineering - it may require hiring costly specialists, but it's not "unbreakable".
In the end, every language (that you understand) can be (de)compiled back to JavaScript. You may still not be able to make sense of that JS code since it may have lost variable names, comments, and parts of the structure, but some things (like property names or calls to runtime builtins) will have been preserved and you can have a go at reverse-engineering the bytecode.