If you often spin up a virtual machine just to run Windows, you might be sad that you have to allocate so much space for it. The Tiny11 project provides a Windows 11 installer that strips and compresses a bare minimum system do under 8GB of space. We aren’t sure what the licensing aspects of it all mean, but there are a few things you need to know. You can see a video about the project below.
The installer requires you to activate Windows, so that’s probably a good thing from a legal standpoint. Besides being compressed, the installer, based on Window 11 Pro 22H2, removes sponsored applications and Teams. It does, however, have the component installer and the Microsoft store, so you can add back things you want that aren’t in the default install.
Anyone who was lucky enough to secure a Gmail invite back in early 2004 would have gasped in wonder at the storage on offer, a whole gigabyte! Nearly two decades later there’s more storage to be had for free from Google and its competitors, but it’s still relatively easy to hit the paid tier. Consider this though, how about YouTube as an infinite cloud storage medium?
The proof of concept code from [DvorakDwarf] works by encoding binary files into video files which can then be uploaded to the video sharing service. It’s hardly a new idea as there were clever boxes back in the 16-bit era that would do the same with a VHS video recorder, but it seems that for the moment it does what it says, and turns YouTube into an infinite cloud file store.
The README goes into a bit of detail about how the code tries to avoid the effects of YouTube’s compression algorithm. It eschews RGB colour for black and white pixels, and each displayed pixel in the video is made of a block of the real pixels. The final video comes in at around four times the size of the original file, and looks like noise on the screen. There’s an example video, which we’ve placed below the break.
Whether this is against YouTube’s TOS is probably open for interpretation, but we’re guessing that the video site could spot these uploads with relative ease and apply a stronger compression algorithm which would corrupt them. As an alternate approach, we recommend hiding all your important data in podcast episodes.
[Kuba Tyszko] like many of us, has been hacking things from a young age. An early attempt at hacking around with grandpa’s tractor might have been swiftly quashed by his father, but likely this was not the last such incident. With a more recent interest in cracking encrypted applications, [Kuba] gives us some insights into some of the tools at your disposal for reading out the encrypted secrets of applications that have something worth hiding. (Slides here, PDF.)
There may be all sorts of reasons for such applications to have an encrypted portion, and that’s not really the focus. One such application that [Kuba] describes was a pre-trained machine-learning model written in the R scripting language. If you’re not familiar with R, it is commonly used for ‘data science’ type tasks and has a big fan base. It’s worth checking out. Anyway, the application binary took two command line arguments, one was the encrypted blob of the model, and the second was the path to the test data set for model verification.
The first thing [Kuba] suggests is to disable network access, just in case the application wants to ‘dial home.’ We don’t want that. The application was intended for Linux, so the first port of call was to see what libraries it was linked against using the ldd command. This indicated that it was linked against OpenSSL, so that was a likely candidate for encryption support. Next up, running objdump gave some clues as to the various components of the binary. It was determined that it was doing something with 256-bit AES encryption. Now after applying a little experience (or educated guesswork, if you prefer), the likely scenario is that the binary yanks the private key from somewhere within itself reads the encrypted blob file, and passes this over to libssl. Then the plaintext R script is passed off to the R runtime, the model executes against the test data, and results are collated.
[Kuba]’s first attack method was to grab the OpenSSL source code and drop in some strategic printf() function calls into the target functions. Next, using the LD_PRELOAD ‘trick’ the standard system OpenSSL library was substituted with the ‘fake’ version with the trojan printfs. The result of this was the decryption function gleefully sending the plaintext R script direct to the terminal. No need to even locate the private key!
Augmented Reality (AR) promises to relieve us from from the boredom of mundane reality and can also help you navigate unfamiliar environments. Current AR tech leaves something to be desired, but researchers at the Korea Electrotechnology Research Institute have brought AR contact lenses closer to actual reality.
The researchers micro-printed FeFe(CN)6 ink onto the contact substrate and thermally reduced it at 120˚C for nine seconds to form Prussian Blue, an electrochromic pigment. By confining the material with the meniscus of the ink, resolution was better than previous techniques to display data on contact lenses. While the ability to reversibly change from clear to blue faded after 200 cycles, the researchers were targeting a disposable type of smart contact lens, so degradation of the display wasn’t considered a deal breaker.
Since voltages applied were constant, it seems this isn’t a true bi-stable display like e-ink where power is only required to change states. The on condition of a section required 0.5 V while off was -0.2 V. The researchers printed a contact with straight, left, and right arrows as well as STOP and GO commands. Connected to a GPS-equipped Arduino Uno, they used it to navigate between ten different checkpoints as a demonstration. Only a 3D printed eyeball was brave enough (or had IRB approval) to wear the contact lens, so watching the state change through a macro lens attached to a smartphone camera had to do.
This is the first we’ve heard of Parametric Press — a digital magazine with some deep dives into a variety of subjects (such as particle physics, “big data” and such) that have interactive elements or simulations of various types embedded within each story.
The first one that sprung up in our news feed is a piece by [Omar Shehata] on the humble JPEG image format. In it, he explains the how and why of the JPEG encoding process, allowing the reader to play with the various concepts along the way, in real time, within the browser.
RGB colour-space subsampling doesn’t affect each component to the same degree due to the human eye cone cell response. Also, the chroma components are much less affected than the luminance.
For those not familiar with the format, the first step (which is actually optional) to JPEG encoding is to transform the image from the RGB color space, into a YCbCr (luminance, chrominance) color space. Since the human eye is far more sensitive to luminance (brightness) differences than it is to Cb (chroma relative blueness) and Cr (chroma relative redness) differences, these latter two components can be subsampled by only storing a single value for each, in every 2×2 pixel matrix. JPEG allows other matrix sizes, but 2×2 is the most common.
This sets the scene for the clever bit, that comes next and allows more of that harder-to-perceive chroma information to be discarded. It’s fun to play with the chroma sub-sampling slider and see how the different colours are not equally affected, due to the relative sensitivities of the human eye cone cells.
Next, the three YCbCr components are treated independently to a discrete cosine transform and quantization. This transforms each 8×8 pixel block into 64 discrete spatial frequencies. The JPEG compression level (which you can change) affects how many of the upper-frequency components get discarded, and thus how much of the fine spatial detail gets discarded. This is the main source of JPEG image quality loss. Finally, the compressed blocks are delta encoded, where each subsequent block is coded as the difference from the previous one. Like chroma subsampling, this doesn’t offer any compression on its own but allows the subsequent run-length encoding to be more effective, giving more (lossless) compression. Finally, the whole lot is then Huffman compressed with a unique table stored in the JPEG header. So want to play with JPEGs some more? here’s the GitHub source.
If all of this theoretical stuff is a bit useless to you, perhaps you just want to decode some JPEGs, then here is a speedy library for just that.
It’s been at least a couple of months since we’ve seen a different 3D modeling language project, so here’s [Lukasz Janyst] with GhostSCAD: a take on creating OpenSCAD models, using the Go language as the front end, bringing all the delights this modern modular language has to offer (and a few of its own idiosyncrasies.) As [Lukasz] says in the blog, from a programmer’s viewpoint, openSCAD has a number of failings that make it not necessarily hard, just kinda annoying to work with, due to the way the geometry tree works. The OpenSCAD way of working ends up with the programmer requiring knowledge of the internal workings of sub-modules, in order to work at the top level (assembly) which is not an ideal situation from a code reuse perspective.
A programmer would describe this problem as “abstraction leakage” and it doesn’t make modular, reusable coding easy to do without a lot of extra work. [Lukasz] says regarding the example GhostSCAD project, that some parts were modeled in a way that knowledge was needed of some mounting points of sub-modules, but those sub-modules had no way to expose this information to the outside world. GhostSCAD enables the programmer to define parts that expose specific parameters to the world that can be queried, for example, to produce a joining part, or an exploded assembly diagram. These properties can be interpreted without the querying module having any knowledge of the internal structure of the thing it’s working with. GhostSCAD provides a Java3D-like API for defining the geometry tree, which may be familiar to some.
For those of us who have spent entire careers working with structured data, it comes as something of a surprise to be reminded that XML is now 25 years old. You probably missed the XML standard on the 10th of February 1998, but it’s almost certain that XML has touched your life in many ways even if you remain unaware of it.
The idea of one strictly compliant universal markup language to rule them all was extremely interesting in an era when the Internet was becoming the standard means to interchange information and when the walled gardens dating back to the mini- and mainframe era were being replaced with open standards-based interchange. In the electronic publishing industry, it allowed encyclopedia and dictionary-sized data sets to be defined to a standard format and easily exchanged. At a much smaller level, it promised a standard way to structure more mundane transactions. Acronyms and initialisms such as WAP, SOAP, and XHTML were designed to revolutionize the Web of the 21st century, but chances are that those are familiar only to the more grizzled developers.
In practice the one-size-fits-all approach of XML left it unwieldy, giving the likes of JSON and HTML4 the opening to be the standards we used. That’s not to say XML isn’t hiding in plain sight though, it’s the container for the SVG graphics format. Go on — tell us where else XML can be found, in the comments!
So, XML. When used to standardise large structured datasets it can sometimes be enough to bring the most hardened of developers to tears, but it remains far better than what went before. When hammered to fit into lightweight protocols though, it’s a pain in the backside and is best forgotten. It’s 25 years old, and here to stay!
coding easy to do without a lot of extra work. [Lukasz] says regarding the 
