That's all very impressive, Jan, but if you were *truly* a hardcore programmer, you'd be using machine code. ;-) More seriously, bloat enables coders to hide back doors much more effectively. They'd never get away with that kind of subterfuge with ASM.
Back in the 20th century, I knew how to program in C. I knew what the assembly code would like after I compiled it.
This is C++.
Now I program in Python. I really don't know how to program in Python. I'm googlesmart. I google what I want to do, download the appropriate library and follow the documentation. I don't know if there is something malicious in there. That's why I really hate every little stupid program and app that thinks it needs to auto-update and needs admin approval to install and screw with the operating system. If there is a portable option, I get that and I keep old versions until they break.
Nobody writes machine code. Assembler has a one-to-one relationship with machine code, but tit is easier to write and read.
Of course they would. Have your ever tried to make sense of poorly documented and commented assembly code?
And it is possible to make machine code self-modifying - at least on some machines - which offers even more opportunity, to put in back doors (and take then away again after you've exploited them).
Many thanks for that well thought-out and well-reasoned response, Jan. Nice to hear from someone who knows what they're talking about instead of some half-baked garbage from a moron like Bill Sloman who wouldn't even be able to set up something as elementary as an Antikythera orrery. ;-)
I never got on with C++. C has a certain elegance to it that I very much like and I've never moved on from it. In fact I'm such a purist, I stay faithful to the K&R variant. They tell me it's limiting to do that, but it does *everything* I need to do so why go further? I find the simplicity and lack of unnecesary bloat very appealing. I'd probably still be coding in ASM if C hadn't come along. For me at least, K&R C is perfection.
Very wise. I like your style, Wanderer!
Now that you mention it: That piece of hardware was actually pretty sophisticated, and I think that even today, only few people would have been able to use it to good effect.
There is a series of videos of someone who built a replica and he explains its workings to some length. Search for "clickspring antikythera" on youtube. I found it fascinating, and also somewhat humbling to realize that my knowledge of our solar system is nothing compared to what was encoded in this mechanism.
Of course, these days software does it better.
Jeroen Belleman
You open the garage door. It's dark inside.
( sorry, had to :) )
Nobody hu? Smith does. Written a compiler in hex code using only a hex to bin converter.
You must silence hysteric virus detectors before you could do that.
Groetjes Albert
Totally agree. I'm waiting till one managed to subvert one of the mainstream browsers with a backdoor via the obligatory daily updates.
Groetjes Albert
I write in machine code sometimes when it's the best approach. On the comp.lang.c newsgroup, we've had a *lot* of entries for the 'obfuscated C contest' over the years and a sub-set of us decided it would be a hoot to have an obfuscated machine code contest as well. Personally I found it really, really enjoyable (I was in the minority as we never had another one, though).
In German they would say "can you the garage door open make?"
Kind of makes more sense to a computer (or that gnome in the Star Wars films).
Graet to see you Don after all these years - 2006!!
I had a customer many years ago who did write a ton of code in hex. To enable modifications they had a bit of space after each function, so edits to a function did not need shifting everything after it :)
Peter
D>One writes code to be *read*. Just because you CAN do something
On Wed, 14 Feb 2024 11:58:59 -0700 Don Y wrote
I update the anti-virus, spyware and malware programs. I got fan-made kerbal space program mods that want to access to the internet to check for updates. Or your download some freeware to open some .crap extension that some fool used on a file and this app wants admin priviledges so it can integrate into the operation and become a default program. When I was in college I had programming Professor who taught Pascal and his big thing was 'scoping'. Every procedure should be self-contained and have simple defined connection to the global program. Now every program wants to pepper my computer with dll's they that programmer picked up from a package he got from who knows where.
You're right. I don't know if my current system is infected but I know the odds of getting infected don't get better with more interactions and more partners.
This project is meant to be read. You can't be serious suggesting that this is a tool to be used. If you spend the time looking at the code, you'd discover that it is quite educational, and make you wonder where the software bloat comes from.
<SNIP>Groetjes Albert
One perfectly good reason is to make life hard for the reverse-engineers. Build in a pile of redundant code, only release executables, never the source, and thereby improve your software sales.
Atomic clocks don't do that. Sounds like you have one of those radio-controlled jobs that's works off a time signal.
That's hex, not MC.
.... and this is why obfuscated language competitions are such fun. Except obfuscated Perl, of course - as there's no point! :-)
One-to-one relationship between assembler mnemonics and numbers? This is a myth. You seem oblivious that Intel's MOV AX,BX chooses between two instructions to the discretion of the assembler at hand? (not to speak of shorter forms that involves AX only.)
I've made a reverse engineering assembler that allows disassembled code to assemble to a copy of the original, obliged to differentiate between the two. See
Move primary register AX to secondary register BX using default size (X). Move primary register BX from secondary register AX
It is hard to analyse viruses without those finesse.
Groetjes Albert
That is a silly response to a description of an assembler that accomplish a one to one correspondance between machine code and mnemonics. I don't care what other assemblers do or doesn't do.
It's not an "imagined requirement" of an assembler. It's a description of the way the original assemblers worked. Compilers came later, and some of their features got grafted into assemblers that were still being used to convert low level code into machine code.
The technology changed and the language changed to reflect that. No imagination involved - except in the design of the up-graded assemblers.
No. An assembler is required to generate the opcode that corresponds to the mnemonic that the programmer specified. A compiler or autocoder is free to use whichever way of say loading zero into the accumulator it likes. But if the programmer writes movi acc, #0 then in assembler then that is what they get (even if xor acc,acc is much faster).
Once you start with macro assemblers and have smart macros then all bets are off but for intrinsic mnemonics they are a clean translation to hex.
I can't offhand think of any assembler that didn't have a regular and reproducible mapping of its opcode mnemonics to hexadecimal numbers (and vice versa although going backwards tended to be a many to one mapping).
MOV for instance often has several hexadecimal codes that it corresponds to because there are so many different sorts. But that is more of a problem for disassemblers than anything else.
The way I obtain unsupported genuine modern opcodes in some archaic inline assemblers that lack support or any other way of doing it is to hack together a jump forward a few bytes and a load immediate long hex constant. It is only worth doing this as an absolute last resort.
Haha hello :)
The pump packed up; turned out that the 25uF (400V AC) starting cap degraded to 15uF.
Divorced the witch in 1999, then the next one (2003-2023) sadly ended in 2023.
Youngest has a PPL (UK and FAA) and flies, both mine and his RV6. Chases females on Tinder and Hinge, like everybody else :)
Stupidity - assemblers have always been around.
Indeed.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.