I did basically everything you mention, back in the day, although on a C64.
In many ways, things were much easier back then: Direct access to most of the hardware, flat memory layout, smaller and vastly simpler ISAs, smaller programs (meaning shorter disassemblies to wade through), no protected mode so you could overwrite anything in RAM and so on. And you wouldn't even have to do it live in-memory, just disassemble the program piecewise from disk. People did extraordinary things back then, and you vastly underestimate their capabilities. Sure, you had to write a lot of tooling yourself, but it was simpler times.
I am not trying to detract from the copy protection mechanism, which truly is ingenious. I was just genuinely curious whether I was misunderstanding anything from the article.
Very clever and great article! But it sounds pretty easy to write a cracker for it: Just rewrite the machine code to jump over the check. Or did I miss anything?
Edit: Guess it depends on the details and amount of "obfuscation" that he mentions.
The BFR runs on a mix of liquid oxygen and methane, according to Wikipedia.
Ignoring obvious scalability problems, wouldn’t it be possible to manufacture that with a pretty decent environmental footprint from various carbon neutral bio sources?
def sumitup(n):
total = 0
for i in range(n):
total = total + i
return total
It was optimized quite well, but still had loops. I know this is a lot to ask, but I would have expected it to be possible to specialize it to a loopless variant:
def sumitup(n):
if n < 0:
return 0
else:
return n*(n-1) // 2
What is your impression of libjit? It looks really nice. I've only tried GNU Lightning, and I made Python bindings for it (although, today I would have used cffi to interface with it instead of my ctypes approach, because of the header files): https://github.com/cslarsen/lyn
I'd love to see a comparison of the various JIT libraries. I guess both give you optimizations and register allocation for free. Of course, the JITting speed is quite important as well.
Indeed I had already linked to your really cool project at the end. Perhaps I should have made it stand out more. The AST approach is more stable, as the Python bytecode can change between any release while the AST changes in a slower, evolutionary pace.
Anyway, I've made a follow-up post that shows how to JIT compile a subset of Python, directly based on the previous techniques: https://csl.name/post/python-compiler/
I do see your point, but I tried to make it clear that this is compilation in an extremely restricted sense: It specializes and executes a function at runtime. And I wanted to cover the core technique of doing just that.
Perhaps I should have included a small example of compiling a linear list of abstract instructions into machine code. But that again would consist of compiling small templates in a coherent way, just like many actual compilers do.
Anyway, point taken, and maybe I'll expand the article or follow up on it.
Is it really that friendly when starting out, though? I found it brilliant, but quite the challenging read. I'd rather just read chapters four and five of SICP [1] and move on to Queinnec as a follow-up on more advanced topics.
Almost always in evenings, whenever I have time and feel like it. If you're a student, you're probably hosed with deadlines, so pick very small things to try out — things like really simple interpreters.
This particular project luckily turned out to be quick to get working. Also, I kept the scope very small, calling it a day right before getting big ideas.
The interesting part is how slow a one-to-one translation of Brainfuck code to machine code will run without any optimizations. That's where the speed comes from, entirely based on those sweet optimizations. So writing one yourself is a rite of passage, like writing a Mandelbrot renderer.
The above project, from the looks of it, looks quite mature, and therefore interesting in its own right.
uv is still quite new though. Perhaps you can open an issue and ask for that?