The opposite is not true though: successful products might have messy codebases, but that doesn’t mean, that messy codebases lead to successful products, or that quality doesn’t matter.
There's a balance to strike, and it's hard to get right. You have to give up quality enough that you actually deliver things to users rather than working on 'the perfect code', but you also have to keep quality high enough that you're not slowed down by spaghetti code and tech debt so much that you can't deliver quickly as well.
This is made more complicated by the fact that where the balance lies depends on the people working on the code - some developers can cope with working in a much more of a mess than others. There is no objective 'right way' when you're starting out.
If you have weeks of runway left spending it refactoring code or writing tests is definitely a waste of time, but if you raise your next round or land some new paying customers you'll immediately feel that you made the wrong choices and sacrificed quality where you shouldn't have. This is just a fact of life that everyone has to live with.
They create executables, which contain encrypted binary data. Then, when the executable runs, it decodes the encrypted data and pipes it into "sh".
The security is delusional here - the password is hard coded in the executable. It was something like "VIVOTEK Inc.".
Ghidra was able to create the C code and I was able to extract also the binary data to a file (which is essentially the bash script).
reply