ampl VS movfuscator

Compare ampl vs movfuscator and see what are their differences.

ampl

a C++ scripting language (by codr7)

movfuscator

The single instruction C compiler (by xoreaxeaxeax)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
ampl movfuscator
3 82
2 9,013
- -
0.0 0.0
over 2 years ago about 1 year ago
C++ C
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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.

ampl

Posts with mentions or reviews of ampl. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-10-29.

movfuscator

Posts with mentions or reviews of movfuscator. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-12-11.
  • controversialOpinion
    2 projects | /r/ProgrammerHumor | 11 Dec 2023
    Everything can be reduced to assignments. https://github.com/xoreaxeaxeax/movfuscator
    2 projects | /r/ProgrammerHumor | 11 Dec 2023
    Who needs jmp when you have mov
  • M/o/Vfuscator: The single instruction C compiler
    3 projects | news.ycombinator.com | 5 Nov 2023
  • Subtraction Is Functionally Complete
    3 projects | news.ycombinator.com | 7 Oct 2023
    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...

    3 projects | news.ycombinator.com | 7 Oct 2023
  • The bigger the interface, the weaker the abstraction
    2 projects | news.ycombinator.com | 29 Jul 2023
    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
    2 projects | /r/programmingcirclejerk | 15 May 2023
  • I am going to learn goto
    2 projects | /r/ProgrammerHumor | 16 Apr 2023
    You only need the mov instruction https://github.com/xoreaxeaxeax/movfuscator
    2 projects | /r/ProgrammerHumor | 16 Apr 2023
  • this new generation invents everything for attention
    2 projects | /r/ProgrammerHumor | 21 Mar 2023
    https://github.com/xoreaxeaxeax/movfuscator true

What are some alternatives?

When comparing ampl and movfuscator you can also consider the following projects:

demovfuscator - A work-in-progress deobfuscator for movfuscated binaries [Moved to: https://github.com/leetonidas/demovfuscator]

obfuscator

Molebox - MoleBox lets you convert your application into an all-sufficient stand-alone executable, containing everything needed: components, media assets, registry entries.

onelinerizer - Shamelessly convert any Python 2 script into a terrible single line of code

sectorlisp - Bootstrapping LISP in a Boot Sector

Cura - 3D printer / slicing GUI built on top of the Uranium framework

Unity-game-hacking - A guide for hacking unity games

sectorforth - sectorforth is a 16-bit x86 Forth that fits in a 512-byte boot sector.

movfuscator - The single instruction C compiler

compiler-explorer - Run compilers interactively from your web browser and interact with the assembly

Invidious - Invidious is an alternative front-end to YouTube

awib - a brainfuck compiler written in brainfuck