closed source apps

For all the opinionated extra stuff.
Post Reply
HughAguilar
Posts: 2
Joined: Sun May 02, 2021 3:06 am

closed source apps

Post by HughAguilar » Sun May 02, 2021 3:58 am

I would like to find out how many people are using Menuet, and how many would be interested in a way to distribute programs closed-source.
I would also like to find out what people use Menuet for (my own interest is cross-development for micro-controllers).

Note that distributing programs closed-source can mean two things:
1.) You distribute an executable that is written in FASM. The downside here is that disassembly is easy, so an attacker can easily
obtain source-code that can be assembled with FASM, although it will not have your label-names, comments, etc..
The major downside is that the user can't be assured that your program is not malware, so the user will be hesitant to run
your program for fear that your program is covertly searching his hard-disk for credit-card numbers and/or passwords.
Another downside is that you have to program in FASM which is (for me) difficult, so this does not work well for light-weight
programs that aren't worth spending a lot of time on. Linux has Python, Perl, etc. for light-weight programs; nobody uses FASM.
2.) You distribute an encrypted binary-overlay (app) for a VM for a language designed specifically to be secure.
The upsides are that this should work to prevent attackers from obtaining any kind of source-code, and should assure the user
that your program is not malware (because your program can't access the hard-disk outside of the current directory).
The downsides are that HLL code is not as efficient as assembly-language, and (more importantly) Ville is strongly opposed
to corrupting Menuet with HLL code --- he is very proud of the fact that Menuet is all assembly-language.

What I have found, is that the FASM forum is very focused on code being open-source. This is so maintenance programmers
can obtain source-code. Their goal is to have somebody else be the "pioneer" who writes 95% of the program, then they
step in and write 5% of the program and claim credit for 100% of the program --- a "hostile fork."

I already discussed this on the FASM forum:
https://board.flatassembler.net/topic.php?t=21674
Revolution, and others, totally shot me down:
revolution wrote:You declare that SecureForth will be secure, but discuss only a small subset of actual security problems that happen. You haven't addressed anything for Meltdown, RowHammer or Spectre. Plus whatever future problems show up.
Banning assembly or HLL won't make your language secure. Things can be insecure, not because of the language, but things outside of the language. Things that you have no control over. And the language (any language) is used as leverage to exploit such problems. There is literally nothing that you can do, aside from deleting everything, that will make your code bypass all possible security problems.
Personally, I think that Meltdown, RowHammer and Spectre are urban-legends. This isn't real. This is somebody's vague speculation
about how a secure system could be attacked, and then pseudo-experts read about this in internet articles and begin to
represent themselves as experts on the subject, although they have not written any code, or even seen an successful attack done.
I think that it is possible to write an HLL that is secure in the sense that programs written in this HLL can be distributed
closed-source so attackers can't obtain the source-code, and users can be assured that the programs aren't malware.

I would think that Menuet users would be especially interested in a secure system that prevents attackers from obtaining source-code,
because Menuet has already been attacked --- Kolibri is a hostile-fork of Menuet --- this is why the 64-bit version of Menuet is
closed-source now. Users of Menuet aren't secure though. I started writing Simple51 in FASM for the 64-bit Menuet, but gave up on that,
one reason being that the Kolibri attackers could easily steal it (it was 64-bit, but almost all of the registers used were 8-bit or 16-bit
so it would be trivial to convert the program into 32-bit to run under Kolibri.

HughAguilar
Posts: 2
Joined: Sun May 02, 2021 3:06 am

Re: closed source apps

Post by HughAguilar » Tue May 04, 2021 3:38 am

HughAguilar wrote:
Sun May 02, 2021 3:58 am
I would think that Menuet users would be especially interested in a secure system that prevents attackers from obtaining source-code,
because Menuet has already been attacked --- Kolibri is a hostile-fork of Menuet --- this is why the 64-bit version of Menuet is
closed-source now. Users of Menuet aren't secure though. I started writing Simple51 in FASM for the 64-bit Menuet, but gave up on that,
one reason being that the Kolibri attackers could easily steal it (it was 64-bit, but almost all of the registers used were 8-bit or 16-bit
so it would be trivial to convert the program into 32-bit to run under Kolibri.
Given about 5 minutes of googling I found discussion on the internet of reverse-engineering Menuet:
https://news.ycombinator.com/item?id=6309751
comex on Sept 2, 2013 [–]

In IDA, Menuet would probably be really easy to reverse engineer for a two main reasons:

- Very, very little code. Everything is implemented in the most minimal way possible. This is extremely important - you can literally read through all the code in the kernel from top to bottom and be sure you haven't missed any functionality. Good luck doing that with some 1MB C program.

- Almost no indirection. Few indirect jumps, almost no use of malloc (!). In IDA this makes it very easy to name functions and variables and easily see where they are used, which isn't possible for anything dynamically allocated, as in idiomatic C. This is to some degree IDA's fault: a smarter tool could do a decent job at automatically inferring the types signatures of C functions and provide similar functionality for struct fields, but IDA does not. However, it does make the problem more tractable in general.

Note that reading the actual assembly, at a local level, is missing from that list. If anything, compiler generated assembly is probably easier to read, due to recognizable idioms, although there are exceptions such as repetitive code in inline functions or templates that would never be written by a human.

(The fun thing is, with a decompiler you can actually read the code in question as C.)
I had to look up IDA because I had never heard of it. This is it:
https://www.hex-rays.com/ida-pro/

I understand that Ville is proud of having an OS written entirely in assembly-language. He has described this to me as a "niche" that few people are in. I don't want to criticize Ville because I never criticize people for something that they are proud of --- certainly, I have been criticized heavily for writing MFX.

As a purely practical matter though, a small lonely niche isn't all that great of a place to be. Also, 64-bit Menuet can be reverse-engineered, so it will likely become a new Kolibri product some day. The post cited above was from 2013 which is about 8 years ago, and this attack hasn't succeeded yet, which is encouraging. It seems likely though, that the attack will eventually succeed.

What I propose is a new OS written in FASM that uses Forth ITC (indirect-threaded-code) inherently. This should defeat the reverse-engineer crowd for a while (not forever, but long enough to make the attack uneconomical). The selling-point for this OS is that the user can distribute his code closed-source so it won't get stolen, and the user can run closed-source code and be assured that it is not malware. I think this is possible. I described the basic idea already:
https://board.flatassembler.net/topic.php?t=21674

An OS such as this has a future. Microsoft is already blocking almost all independently written software using S-Mode. I foresee a day when only Microsoft software will run under Windows (similar to how only Nintendo software would run under the Super Nintendo game-machine) and independent software development will be effectively banned. People want to write software independently though. For example, I wrote HJA430 recently:
https://board.flatassembler.net/topic.php?t=21841
In this assembler I introduced code-blocks, which are my own invention. Texas Instruments assembler doesn't have code-blocks --- there is no assembler for any processor that does have code-blocks --- you will wait quite a while for Microsoft to provide an assembler with code-blocks. I invent things all the time. Code-blocks aren't my greatest invention --- this was just something I thought up recently --- in retrospect it seems obvious. I think the reason why code-blocks weren't invented previously is that most programmers are sheep following the herd, and they never invent anything even if doing so would be obvious given a little bit of thought. Modern assemblers (including FASM) look remarkably similar to the IBM360 assembler of the 1960s. They have the same limitations:
* Overuse of labels, resulting in spaghetti-code.
* Only one instruction per line of source-code.
* A very prickly macro language.
With a few weeks effort (working when time allowed, as I do have a day job), I came up with HJA430 that removes all of these limitations; it wasn't that hard.

So, the OS that I'm describing would allow inventors to write software independently without their big ideas getting stolen immediately, and would allow users to run closed-source programs such as HJA430 without concern that while they are developing MSP430 code to control their model railroad, HJA430 isn't covertly searching their hard-drive for credit-card numbers and passwords.
This is a niche that nobody is in right now.

The problem, of course, is that I don't know anything about OS development. I'm just a Forth programmer.

P.S. I should point out that a lot of programs are light-weight. Under Linux these are done in Python or Perl or whatever. Most of these light-weight programs involve conversion of text from one format to another. I have my STRING-STACK.4TH package that provides a lot of support for pattern-matching and substring-extraction --- this would work well for most light-weight programming --- nobody wants to write light-weight programs in FASM, and if you did use FASM you would require a code-library roughly comparable to STRING-STACK.4TH or a regular-expression package --- if you are going to use such a heavy-weight code-library in FASM, you might as well be using an HLL such as Forth or C or whatever --- the elitism of being an assembly-language programmer is watered down significantly when you are using GLIBC etc. to write programs.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests