movfuscator
awesome-falsehood
movfuscator | awesome-falsehood | |
---|---|---|
82 | 50 | |
9,013 | 23,045 | |
- | - | |
0.0 | 7.5 | |
about 1 year ago | 13 days ago | |
C | ||
GNU General Public License v3.0 or later | Creative Commons Zero v1.0 Universal |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
movfuscator
- M/o/Vfuscator: The single instruction C compiler (2020)
-
controversialOpinion
Everything can be reduced to assignments. https://github.com/xoreaxeaxeax/movfuscator
- M/o/Vfuscator: The single instruction C compiler
-
Subtraction Is Functionally Complete
However, the movfuscator as implemented does still require a sigaction(2) syscall to set up a signal handler, under the justifications that "it is not actually part of the program" and that "if we were in ring 0, we wouldn't need help from the kernel" [0]. However, the latter part seems a little dubious to me: without the help of the kernel running non-MOV instructions, you'd never be able to escape from 16-bit real mode into 32-bit protected mode, since you wouldn't be able to load a valid GDT with the LGDT instruction (as far as I am aware).
[0] https://github.com/xoreaxeaxeax/movfuscator/blob/90a49f31219...
-
The bigger the interface, the weaker the abstraction
I _think_ the idea is thinking of an "interface" as "something that you use as a way to interact with something from outside an abstraction". I'd summarize their argument as reasoning that if the goal of an abstraction is to avoid having to care about the internal details of something, an interface is a way to expose a subset of ways to interact with it, and the more you expand it, the more it exposes the internals of the thing being abstracted. I don't think they necessarily mean this only in terms of programming, but you could apply this argument to a programming language interface; if you use an interface for interacting with something instead of its direct functionality, each additional method you add to the interface exposes more details of the inner value, which makes it less of an abstraction.
Assuming my interpretation is correct, I'm not sure I totally buy this argument because there doesn't seem to be an obvious way to define the "size" of an interface where it holds true. The naive way to define the size would be number of methods, but I'd argue that methods can vary so much in terms of the amount of cognitive overhead they "expose" to the user that it's not very meaningful. Consider the Movfuscator compiler[0], which compiles code into binaries only using MOV x86 instructions because it happens to be Turing complete; as complex as it might be to learn x86 assembly as a whole and start writing programs directly in it, I'm dubious that trying to do so only with MOV would somehow be easier. Put another way, an x86 instruction set that only contains the MOV instruction is not a "stronger" abstraction than the actual one because it _introduces_ complexity that doesn't exist in the original. Does adding an ADD instruction alongside MOV increase the strength of the abstraction, or weaken it? I don't think there's an answer that we'd immediately all agree on for this sort of thing.
Ultimately, I think trying to measure interfaces through the number of methods they expose is similar to trying to measure code by the number of lines in it; while there are some extreme cases where we'd likely all agree (e.g. for a fizzbuzz implementation, having 10 lines of code is probably better than thousands of lines of code[1]), we can't really come up with a good objective metric because the "target" number is based on the complexity of what you're trying to define, and we don't have a way of quantifying that complexity. I think the ideas here are still super interesting though, not because they have definitive right or wrong answers, but because thinking about stuff like this overall improves one's ability to write good software for usage by other programmers.
[0]: https://github.com/xoreaxeaxeax/movfuscator
- The M/o/Vfuscator contains a complete mov-only floating point emulator. Since it is approximately 500,000 instructions, you must explicitly link to it if you need it
-
Can the RISC instruction set be simplified even further?
The mov instruction in x86-64 is Turing complete. Someone even made a C compiler using only mov.
-
This is definitely not the best way to initialize an array
Are you sure they didn't use the MOVFUSCATOR?
-
Can every function defined in popular libraries/frameworks be traced back to primitive data types, conditional statements and loops?
Yep. In fact you can reduce everything to just one simple assembly instruction.
- I am going to learn goto
awesome-falsehood
-
Ask HN: Did you encounter any Leap Year bugs today? How bad was it?
Billing. It always has to be the billing. For a list of all other edge cases, you have: https://github.com/kdeldycke/awesome-falsehood#readme
-
24 GitHub repos with 372M views that you can't miss out as a software engineer
Falsehoods Programmers Believe in: https://github.com/kdeldycke/awesome-falsehood
-
Why is it still a practice to not allow special characters in name fields?
Also, a list of other falsehood-programmers-believe collections: awesome-falsehood.
-
Bjarne Stroustrup Quotes
> I feel like there's a "Fallacies programmers believe about text" that should exist somewhere
I got you covered.
https://github.com/kdeldycke/awesome-falsehood#international...
http://garbled.benhamill.com/2017/04/18/falsehoods-programme...
https://jeremyhussell.blogspot.com/2017/11/falsehoods-progra...
https://wiesmann.codiferes.net/wordpress/archives/30296
-
Ask HN: How to handle Asian-style “Family name first” when designing interfaces
There's an excellent GitHub repo that lists a lot of common falsehoods regarding names. I'm not sure how useful it'll be to OP, but the repo in general should probably have way more attention than it already does.
https://github.com/kdeldycke/awesome-falsehood#human-identit...
-
Facebook must pay $100.000 to Norway each day for violating our right to privacy
A decent list for this about prices and currency https://gist.github.com/rgs/6509585 and the full list of other falsehoods https://github.com/kdeldycke/awesome-falsehood
- Falsehoods Programmers Believe In
-
How to organize structs in the code
If you're interested in this sort of thing there's a whole bunch more: https://github.com/kdeldycke/awesome-falsehood
-
Store your epoch times as 64-bit floats
It's saddening to see the number of people who critique the idea of storing time as an unsigned integer by immediately responding that that means that times before 1970 cannot exist. This bespeaks of a continuing poor knowledge of the subject, despite all of the "falsehoods that programmers believe about" documentation that has grown up.
* https://github.com/kdeldycke/awesome-falsehood#dates-and-tim...
Microsoft, for one example, has been modelling times as a 64-bit unsigned 100-nanosecond count since 1601 (proleptic-Gregorian proleptic-UTC) for about 30 years, now.
* https://learn.microsoft.com/en-us/windows/win32/api/minwinba...
Daniel J. Bernstein in the late 1990s chose a 0 point for an unsigned count so far back that it pre-dates most estimates of the point of the Big Bang.
* http://cr.yp.to/libtai/tai64.html
1970 is not the mandatory origin for every timescale. (Indeed, in the early years of Unix itself there wasn't even a stable origin for time.) It is not a valid reason for dismissing the idea of storing time as an unsigned integer.
It's also sad to note that the headlined page's first sentence has one of the very falsehoods that programmers believe about time in it.
What are some alternatives?
demovfuscator - A work-in-progress deobfuscator for movfuscated binaries [Moved to: https://github.com/leetonidas/demovfuscator]
libphonenumber - Google's common Java, C++ and JavaScript library for parsing, formatting, and validating international phone numbers.
obfuscator
nocode - The best way to write secure and reliable applications. Write nothing; deploy nowhere.
Molebox - MoleBox lets you convert your application into an all-sufficient stand-alone executable, containing everything needed: components, media assets, registry entries.
tinygettext - A simple gettext replacement that works directly on .po files
onelinerizer - Shamelessly convert any Python 2 script into a terrible single line of code
awesome-gbadev - A curated list of Game Boy Advance development resources
sectorlisp - Bootstrapping LISP in a Boot Sector
vscode-gitlens - Supercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more
Unity-game-hacking - A guide for hacking unity games
awesome-remote-job - A curated list of awesome remote jobs and resources. Inspired by https://github.com/vinta/awesome-python