Sometimes, after many attempts, you realized that to complete your mission, you must access private fields, or perhaps change final fields.

There are many reasons imaginable: the accessors copy the entire object before returning, and that takes a very long time, the authors forgot to provide an accessor, the library function is highly inefficient and you need to do better, …

Are you out of luck? Fortunately, no.

As most probably know, DMOJ uses a sandbox to protect itself from potentially malicious user submissions. An overview of the Linux sandbox has been published by my friend Tudor. However, it doesn’t go deep into the implementation details, many of which differ between Linux and FreeBSD.

At its core, the sandbox, cptbox, uses the ptrace(2) API to intercept system calls before and after they are executed, denying access and manipulating results. The core is written in C, hence the name cptbox.

Perhaps the most obvious difference between Linux and FreeBSD is that on Linux, ptrace(2) subfunctions are invoked as ptrace(PTRACE_*), while on FreeBSD, it is ptrace(PT_*). But this difference is rather superficial compared to the significant internal differences.

Most people, when first starting assembly, still carry over a lot of high level constructs in their assembly programs. A common pattern is to multiply and divide when a bit shift would suffice.

For example, a lot of people would write a program to write out the binary representation of an integer using the divide and modulo operations. This is rather inefficient compared to using shifts. For example, the divide by 2 can be replaced with a right shift by 1, and modulo 2 can be replaced by a bitwise AND with 1.

Aside: interestingly, taking any number modulo a power of two m is equivalent to doing a bitwise AND with m-1. The proof of this is left as an exercise for the reader.

This post will address the basics you need to know about shifts to get up to speed on writing good assembly.

Most of us have a good idea how to write a simple “Hello, World!” program in C, but sometimes it feels a little too easy. Luckily, we can always make it more of a challenge!

Consider a hypothetical situation where many symbols are banned, such as ", ', \, #, {, and }, and we aren’t allowed the string Hello, World! as a subsequence in the code. How would we write a “Hello, World!” program then?

Is it impossible, because we can no longer use {} to write a block of code for a function? Is it impossible, because we can’t actually embed the string?

Jupyter and IPython makes for a very nice notebook, but by default it comes only with Python support. Fortunately, Jupyter supports many kernels, allowing for many languages from R to Redis, Perl to C++ to be supported. Unfortunately though, getting these kernels to run is not exactly an easy business. This time, we will be dealing with cling, a Jupyter kernel for C++.

It is a fairly common practice to compile Windows application on Linux build servers. However, this is usually done through an approach called cross-compiling. The essence of this approach is using a compiler for Windows applications, but the compiler itself is a Linux application. Usually, the compiler used for this is MinGW (or MinGW-w64 these days), a GCC implementation for Windows.

This works great when porting traditional Unix applications to Windows, since it meshes nicely with the traditional build system on Unix-like systems. But it is rather poor for standalone single .exe applications, which are more common in the Windows world. MinGW has a few DLLs that are needed to run the applications it compiles, and that ruins the single executable experience.

The traditional way to build these simple applications in the Windows world is with the Microsoft compilers, usually in the form of Visual C++. These compilers are fairly nice, but they have one problem: they do not exist as cross compilers. (Well, they can cross compile between different processors, but the compilers themselves will only run on Windows.) What do we do then? Do we resign ourselves into not having single executable applications, or do give up and buy a Windows build machine?

After seeing Raymond’s post on polyglot launchers for Perl and JScript with batch files, I decided to present one for Python:

@python -x "%~f0" %* & goto :eof
# Your Python code here.

This one simply use the special python flag -x to ignore the first line, which is somewhat analogous to the -x Perl flag, but much simpler.

I also have an alternative Perl polyglot header that does not require the special flag -x.

@rem = '--*-Perl-*--
@perl "%~f0" %*
@goto :eof
';
undef @rem;
# Your Perl code here.

I am probably somewhat obsessed with having my websites accessible over a .onion domain, perhaps because I like vanity names (I’ll explain this later).

A while ago, I introduced dmojsites2fpbeve.onion for DMOJ. And today, I introduce quantum2l7xnxwtb.onion for this website.

These .onion websites are accessible over Tor, and do not ever leave the Tor network when accessed this way. Despite not having HTTPS (which is basically unattainable due to the lack of any certificate authority willing to issue free certificates for .onion), the encryption is end-to-end: only your computer and the server at my end can see the actual traffic in plaintext. For those familiar with the Tor network, there is no exit node which can watch your traffic in this setup.

To preview these websites, you can use tor2web.org. In practice, you simply have to append .link after any .onion domain, and tor2web will take care of the rest. For example, quantum2l7xnxwtb.onion can be accessed as quantum2l7xnxwtb.onion.link. Note that you lose pretty much all the benefits of Tor this way.

.onion domain names are composed of 16 “random” alphanumeric characters (more precisely, matching ^[a-z2-7]{16}\.onion$). These are derived from the public key of the onion site. Now, you may have noticed that the DMOJ and Quantum onion sites have a nice, identifiable prefix. This is called a vanity name. To generate these, we perform the equivalent of generating keys until we happen to get the desired prefix. This process is not too fast, as you can probably imagine.

I decided to take it as a challenge to get a full perfect score on the de facto standard of SSL implementation quality, the Qualys SSL Labs Server Test.

Needless to say, getting a perfect score is not without cost. For example, many browsers will be incapable of accessing the site. For this reason, I decided use a “disposable” domain name: ssl100.quantum2.xyz, which also runs on a separate IPv6 address to prevent any contamination on this website (there is no IPv4 since I didn’t have a disposable address), so you will need IPv6 access.

Incidentally, this also gets an A+ on securityheaders.io.