TechyMagThings

This week Jonathan chats with Francois Proulx about SmokedMeat! That’s the third in a trio of Open Source security tools from Boost Security, and this one is the red team tool to demonstrate vulnerabilities. Why are Continuous Integration vulnerabilities such a persistent problem, and what’s on the horizon that may help? Watch to find out!

• https://github.com/boostsecurityio/poutine
• https://github.com/boostsecurityio/bagel
• https://github.com/boostsecurityio/smokedmeat

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

Regular expressions (regexes) are an amazingly powerful way to perform operations on collections of e.g. text. Regexss can also be considered to be a programming language, even a Turing complete one. Ergo it’s perfectly acceptable to thus design a way to use regexes to run and play a game of DOOM, as [Artem Lytkin] recently did.

The GitHub project page can be found here, containing the Python-based code that allows the demonstration to run, as well as the other components, including the C runtime and the 96.6 MB text string that defines a CPU’s registers, RAM, a framebuffer, the DOOM engine compiled to this custom CPU’s instruction set and the WAD file for the game itself.

The C-based driver applies the fixed, ordered list of find-and-replace rules to this string, which after more than ten-thousand of such substitutions later results in a single frame of the game. At about 80,000 substitutions per second on the given test system, that gets you to a sort-of playable framerate, even.

Naturally, the practical value of playing DOOM like this is pretty low, but as a demonstration of why regexes are awesome it’s hard to beat.

It’s been said for centuries that you cannot think on an empty stomach, and that love goes through the stomach. Although these may seem like merely cute jabs at the simplicity of human nature, recent research in rat models by [Logan Tierno Lauer] et al. indicates that the gut may be more influential in something as fundamental as memory formation and cognitive function than previously assumed.

Key to the gut-brain connection is the vagus nerve, an essential part of the autonomic nervous system that wires the brain into the body’s organs, including the gastrointestinal (GI) tract. It provides both sensory and motor fibers, so that the brain can literally sense the state of said GI tract, with various triggers as result. One of these is – as demonstrated in the paper – the release of acetylcholine (aCh) an important neurotransmitters in the CNS for cognitive functions including attention, memory and motivation.

Using in vivo fiber photometry it was found that during eating medial septum neurons released aCh, with various ways to impair this mechanism along the vagus nerve leading to this response disappearing. This also confirms earlier research that points the finger at a so-called early life Western Diet (WD) causing impaired memory and overall cognitive function, likely due this high fat and high sugar diet causing dysfunction in this aCh regulation mechanism.

Beyond once again reinforcing the need to eat healthily, this research also provides further insights in condition with declining cognitive function, such as Alzheimer’s and dementia.

The ability to write Python on microcontrollers with the likes of MicroPython and later CiruitPython has made them much more accessible. [MakerClassCZ] brings that to game development with PicoGame.

Like any good project, it starts with a problem that needs solving. Put simply, the existing CircuitPython libraries aren’t too impressive for gaming. The DisplayIO library tends to do full display refreshes, which are slow on such tiny displays, and the Stage library just wasn’t flexible enough for [MakerClassCZ]’s liking. So he built his own.

PicoGame, like the others, implements the performance-sensitive things in C, but does partial updates for the screen, on its own massively increasing the framerate. On the other end, it uses fixed-point math–much cheaper than soft-float–and makes an active effort to keep the RAM usage low so Python can have it. What’s even more clever is using the downtime between sending one tiny portion of frame to calculate the next just in time.

Of course, the display is still the limit. If you need to update a lot of it, you might end up with 10 FPS if you’re lucky. But if you can settle for less motion, you could see 100.

A talk from the recent Electromagnetic Field event in the UK caught our eye, in which [Amy Jeskins] looked at the overlooked engineering skill of pattern cutting. She takes us through the mechanics of creating a pattern for a piece of clothing, and asks why it is not a skill taught to engineers.

She’s a specialist in theatrical costume, and the talk takes us through some examples of her work before looking at the history of tailoring and pattern making. She explores flat cutting and draping a pattern on a form before coming into the present day with CAD packages designed for clothing work. It’s the social aspect of the talk that’s perhaps the most interesting, looking at how it has become a gendered skill and thus not something considered where it should belong, as engineering. We’re reminded of one of the most important additions for a healthy hackerspace, a textile room, as we’ve seen people there bridge this divide from both directions.

If you have never made a piece of clothing then we’d suggest giving this talk a watch, and maybe taking up a sewing machine to give it a try. In the past we’ve taken you through some of the prerequisites for a textile bench. The full talk is below the break.

Back in the early 1980s when 8-bit home computers became affordable educational toys for children, the traditional paper publishing industry did its best to keep up. For a few brief years, there were children’s books dedicated to the innards of a computer in meticulous detail, and courtesy of [Jason Jacques] we have a chance to look at one of the lesser-known ones.

The British publisher Ladybird made a series of four computer books, and while the first three had content for both the Sinclair Spectrum and the BBC Micro, the last in the series only featured the BBC. [Jason] took that book and re-imagined the missing Sinclair Spectrum version.

The surprise is how deep it dives into the architecture of an 8-bit computer, and it’s refreshing to see something that’s not unduly dumbed-down for kids. We’re guessing that this would have appealed to the 5% of kids who ran with their computers rather than just playing Jet Set Willy back then, and we’re sure a few grown-up 50-somethings may remember it or books like it.

If you think you may have seen Ladybird books here before, it may be because we reviewed another influential tech book of theirs for kids. Meanwhile you can take a look at the contemporary computer books from their arch-rival Usborne.

After getting his hands on a rope driver module from the Apollo project era that had a big ‘Scrapped Module’ stamped on it, [Mike Stewart] was naturally left curious as to what exactly had failed in this module. Originally destined for the Apollo Guidance Computer, these Raytheon-manufactured modules were the pinnacle of space-grade high-tech of the 1960s, with requisite acceptance testing so as to not endanger a very expensive space mission.

The cool part here is that the acceptance documents for the module in question (B16-B17) have been scanned in and can be found on the Internet Archive. With the part itself being potted and very much inaccessible, this document helpfully lays out the expected measurements on the module’s pins, as well as schematics and mechanical drawings. Unfortunately the reasons for the rejection were not recorded, so replicating the failing test results is required to understand the reason.

A slight complication here is that the testing procedure doesn’t just involve hooking up a multimeter for some voltage and capacitance measurements. There are also temperature and voltage extremes, and vibration tolerance involved, which would be somewhat complex to test, but most of all risk damaging a historical artefact. Thus a somewhat conservative testing procedure was chosen, even if this may not reveal the actual fault.

As noted in the video, sometimes modules were also rejected because someone simply dropped it on the floor along the way. However, generally if a module was found to be faulty they would open it to diagnose said fault, with a closer look at this module indeed revealing suspicious marks in the potting compound where it was apparently opened and conceivably repaired. This also might explain why they also put the ‘For engineering use only’ on it.

With multiple of such locations visible in the potting compound, these locations were mapped to the schematics for the module, to get some idea of what may have been accessed. After this, basic testing was performed on the module, as per the acceptance testing document.

Along the way an error was detected in said document, in the form of the wrong pin number. In table 4-2 the input pin 269 was mistakenly listed as having output pin number 169 when it should have been pin 168. Pin 169 is chassis ground, so this was presumably fixed in a later version of the document.

After all the testing with just stationary, room-temperature conditions, everything appeared to check out. This means that likely this was indeed a repaired module that got subsequently used for engineering purposes rather than installed in flight-ready hardware. The only issue found was that channels were out of calibration, but whether this was an original flaw or due to the module being half a century old is hard to tell in the absence of repair logs.

Overall it’s an exciting opportunity to document another part of history, since so many of the details pertaining to these original modules and related technologies got lost or muddled over the decades.