Couple questions about Assembly

[Aeonix]

Couple statements, couple answers.
I don't understand everything.
If I'm wrong, correct me, but don't be mean about it.
You weren't senior in your first steps either.
Some of these are guarranteed wrong,
because I want to taunt out the correct answer.

Statements:
S1. Assembly works 1 on 1 with the CPU. It's as "least as possible overhead" as possible that is still currently in active use.
Everything that has to do with usable lowest level and is still "cool" to use is Assembly. Operating systems, operating system installations, rescue CD, boot systems and lowest level (partitioning etc.) applications are made in Assembly in order to not make people insane by typing 1's and 0's. Assembly's so-called OP codes work in ratio 1 to 1 in binary, and is often pretended that Assembly is just language of processor. "You just don't go lower than that".

S2. Assembly has no security flaws.
As "hacking" (software cracking) requires a lot of working hardware and software. It's like trying to cut atom (Assembly written program) with an axe (software written in other languages on different machine). Assembly has no possible corruption as it has no networking access, it doesn't have faulty delimiters, it doesn't care about social engineering and the only actual way to make Assembly program behave like it shouldn't, is to directly and physically overwrite the data or intercept within processor itself. And if you try to intercept calls by wrong memory to wrong sector, you'll most likely crash system than actually achieve your result. Making at least 99% of wanna be "hackers" (includes script kiddies up to ones with legendary titles) to find better pray. On top of that, it's harder to correctly corrupt couple megabytes of assembly without knowing what each piece of code is meant for.

S3. Compilation of C++ to Assembly is exactly same as writing in pure Assembly.
That's a tough one. According to this site. It is possible to convert C++ code into Assembly and in actual case, it is possible to actually see what part corresponds to what. Meaning that securely written C++ code, using securely written compiler, results in (mentioned in point 2) unshakable Assembly/binary system.

Questions:
Q1. How did people not turn insane when C/C++/Assembly was not a thing?
I'm not old enough to recall these times. But before there was C and C++ and Assembly. You had to write binary, how possibly did you keep up with 10.000 lines of code consisting only of 1's and 0's?

Q2. Wouldn't eliminating security flaws one by one make for safer fundament?
I know that there is no such thing as unbreakable software. But wouldn't fixing stuff from ground up immensly improve security overall? After all, it's all about the fundamental security flaws. When it comes to system vulnerabilities. There's only 3 ways, through human (social engineering), through programmed mistake (impossible to avoid at this point) and underlying software. If we fixed underlying software, the higher languages wouldn't have that many leaks as result of upstream bugs and errors.

That's it. Please don't be an a++hat, just trying to understand stuff.

[rproffitt]

There are so many topics in your post that each one could take a session on its own.

A lot of what you wrote is based on assumptions long gone. When was the last time you were on a computer with just a single core? For me that can happen in embedded work but most of what you wrote and I have to make a big assumption is your run of the mill smart phone or PC.

This means that assembler is not your best choice as there is no known system to that will take your code and thread/break it across the cores for more throughput. This is possible with byte code systems (Java, others.)

The speed angle buckles and breaks as processors sprout new instructions. Your assembler code is a "do this" code and your byte code says "do this as best you can." So your Java/Android app can optimize it for each CPU and instruction set.

I've written a lot of assembler for embedded systems but today, I'd skip assembler for a next level up language.

Finally that's news to me that assembler has no security flaws. This must be from an assembler fanboy?

[Aeonix]

There are so many topics in your post that each one could take a session on its own.

I was actually hoping for that. The more I know, the better.

A lot of what you wrote is based on assumptions long gone.

We talking a decade or more?

When was the last time you were on a computer with just a single core?

Decade or so.

I have to make a big assumption is your run of the mill smart phone or PC.

I tried thinking of seeing how the I could affect computer hardware using assembly (send a sound? print a text? make a visible box? turn on light of camera? blink diode of my mouse?), nothing serious.

This means that assembler is not your best choice as there is no known system to that will take your code and thread/break it across the cores for more throughput.

So Assembly is monolithic only, it's not possible to somehow split it up?

This is possible with byte code systems (Java, others.)

Doesn't Java require working operating system and it's sub-tools to boot? On the other hand, wasn't that what Android relies on? Including some other low-level language?

Your assembler code is a "do this" code and your byte code says "do this as best you can."

Doesn't "do this as best you can" add overhead? It needs to go through a lot of possibilities. "Do this" seems more direct and what I want, "do this as best as you can" is kinda a wildcard here.

I've written a lot of assembler for embedded systems but today, I'd skip assembler for a next level up language.

Could you hint more light on that? Not about the language, but why would you give up Assembler for next language. To me it's like saying that you would rather create serious client-side JavaScript application, than run C++ program on a port. It seems that if you know both. C++ would be more secure, faster and well, look more professional. Could you give me an idea why Assembly is too much? Is it because you need to repeat the same dull code, or did programming languages and their functions just get better that they do exactly what you need (byte-codes you say)? Are such alternatives trustworthy solution compared to higher-level programming languages?

So your Java/Android app can optimize it for each CPU and instruction set.

My Java/Android app?

Finally that's news to me that assembler has no security flaws. This must be from an assembler fanboy?

Could you give me an idea how well written binary program would have flaws? I mean after all we're talking "move memory A to B", and "add memory A to memory B". Those seem pretty incorruptable as they require two integers, and if they're not there, it fails. And no, this comes from me. I just can't put my finger on it, on how something so simple and so out-of-this-world can be broken. After all, nearly every bug and vulnerability found is based around same principle of incorrectly written code and I thought since binary execution is flawless (how can it fail adding 1 to 1, without there being a hardware failure), how can it be cracked? Like I mentioned, some of the statements were guarranteed to be wrong. Just trying to get more information.

[rproffitt]

"So Assembly is monolithic only, it's not possible to somehow split it up?"

Sure you can. In fact we now use dual ARM chips to dedicate one to motor control and one to I/O. This is an embedded system so from the ground up, the app as a whole is dual core. This still won't help if we added say some WiFi or other link and wanted the host OS to do the work of splitting the load up.

"Could you give me an idea how well written binary program would have flaws?"

Since the executable might be in the clear, you can reverse assemble and edit it to do your bidding. There is no "signing" of the app so it's wide open to editing. https://www.google.com/search?q=android+apk+signing for example broaches how in an OS we can have signed apps.

Apple takes that a step farther. Some say too far.

PS. Your topic is quite large. If you ever try this again, keep it on a single topic or one question.

[AssertNull]

it doesn't care about social engineering

If you're in the security business, you had better care about social engineering. That goes for all Operating Systems, all hardware, all applications, all programming languages. Computer security, like all security, takes time, effort, and commitment. Whenever you get a lazy or greedy or ignorant person anywhere in the chain (including the consumer), you have a potential security breach. Anyone ever been on a project with a tight deadline? The person in charge of security says "I think we have a few security bugs in here. We need more time to investigate", the project manager says "We have a deadline. Release it, then find the security problems later and we'll release a patch. We're out of business if we miss Black Friday".

There's your security problem right there. I don't care where the security problem is: Operating System, hardware, application code, or lack of actual security guards guarding an actual building so thieves can't break in physically and steal all the code and schematics, whenever security threatens efficiency and the almighty dollar, you'd better care about human psychology and social engineering.

[rproffitt]

Just today I read this.

"Message to programmers: ALL USER INPUT IS EVIL."

For your assembler app to be useful it likely takes input and produces output. Writing in assembler does not automatically shield you from the evil users, bots or other bad computers.

Example: DDOS attacks that leverage your IP stack. Your code for instance has some feature to send status or more to a return IP. Hello DDOS and it does not matter what your code was written in.

[Reverend Jim]

Doesn't "do this as best you can" add overhead?

The people who write the tools (compilers, interpreters) generally know a lot more about optimization tricks than the rest of us. In some cases, with properly written high-level code, optimizations can be done that, were they done at the source code level, would render the code unintelligible. So in most cases "do this the best you can" is generally better than you or I could do it.

Assembly works 1 on 1 with the CPU...Assembly's so-called OP codes work in ratio 1 to 1 in binary, and is often pretended that Assembly is just language of processor. "You just don't go lower than that".

Essentially true but does not take into account micro-code. Assembly, though, is the lowest level accessible to the programmer.

it doesn't care about social engineering

No software cares about social engineering or anything else for that matter.

applications are made in Assembly in order to not make people insane by typing 1's and 0's.

Applications are generally not coded in Assembly because the (possibly) limited gains in execution speed/efficiency are greatly outweighed by the much longer development time required by low-level coding. I've had to code at the bit level, assembly level and all other levels above that. My sanity is mostly intact.

Assembly has no security flaw

Any code that performs any non-trivial task can have security flaws.

Assembly has no possible corruption as it has no networking access

This statement and several that follow are clearly false. All higher level languages must eventually be broken down (compiled/interpreted) to assembler directives before they can be linked and executed so if a high level language has network access then so must the lower levels.

Compilation of C++ to Assembly is exactly same as writing in pure Assembly

Most compilers today do some optimization. For example, if you have an expression that is being evaluated in a loop and it clearly does not depend on anything else in the loop, the compiler can move that evaluation out of the loop. As such, even though the code ends up as Assembler code, there is not necessarily a clear correspondence between the two versions.

securely written C++ code, using securely written compiler, results in (mentioned in point 2) unshakable Assembly/binary system.

As has already been pointed out. No software is secure from social engineering hacks.

How did people not turn insane when C/C++/Assembly was not a thing?

There are a lot of books on the history of computing. If you are up to a serious read I recommend Colossus: The Secrets of Bletchley Park's Code-Breaking Computers. Several of the computers I have worked on in my early career were programmed, patched and debugged by toggling in code bit-by-bit on the front panel. We didn't go insane because there was a job that needed doing and that was the only way to do it.

how possibly did you keep up with 10.000 lines of code consisting only of 1's and 0's?

Very early computers were programmed by running cables. Even with the complexity of that task, the time saved by doing the job on the computer was worth the effort, especially (in the case of the Colossus book) if it meant early warning of an enemy attack on London. In any case, programming in Assembler does not involve keeping up with 10.000 lines of code consisting only of 1's and 0's.

But wouldn't fixing stuff from ground up immensly improve security overall?

Yes it would, as long as the design is tightly managed.

In the case of Microsoft, there are a lot of cooks. Instead of one grand design you have many departments, each with the same "not invented here" mentality. As such you get redundant code and a lot of reinvented wheels. Add to that the pressure of meeting shipping deadlines determined, not by the designers/coders, but by marketers.

In the case, however, of the Amiga OS it was designed first as an academic project, then rewritten for a brand new computer. The first generation (academic) was called TripOS. It was developed as an exercise. Thus, there was no hard deadline. It was designed by a small group and was highly object oriented with little redundancy. Thus, when there was a bug in some logic it was likely not replicated anywhere else. Fix it in one place and it's fixed everywhere.