As hackers, we occasionally forget that not everyone is enamored with the same nerdy minutia that we are. Configuring hardware by changing some lines in the code and compiling a new firmware doesn’t sound like that big of a deal to those of us who’ve been around the block a few times, but might as well be ancient Sanskrit to the average person. As long as your projects are for personal use this isn’t really a concern, but what if you plan on distributing the code for a project or perhaps even selling finished products? Shipping it out with hard-coded variables simply isn’t an option.
With the setup demonstrated in the video below by [Proto G], you don’t need anything more exotic than a web browser to configure the device. The end user simply searches for the device’s WiFi network, connects to it, and is presented with an easy to understand dialog which has them select a WiFi network to configure against along with some fields to enter in custom variables. All this information is then stored to a file on the SPI flash. When the ESP32 reboots, it reads the configuration from the saved file and applies the requested settings.
This is very similar to how many consumer devices are now configured, and even the less technically-inclined recipients of such a device should be able to work through the setup with a bit of hand-holding. If you plan on handing one of your ESP32 projects to John Q. Public, this is the kind of configuration you should be aiming for.
Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.
While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leo Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, [Leo] ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.
All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.
We ran across something interesting on GitHub of all places. The “Open Source Society University” has a list of resources to use if you want to teach yourself computer science for free. We found it interesting because there are so many resources available it can be hard to pick and choose. Of course, you can always pick a track from one school, but it was interesting to see what [Eric Douglas] and contributors thought would be a good foundation.
If you dig down, there are really a few potential benefits from going to college. One is you might learn something — although we’ve found that isn’t always a given, surprisingly. The second is you can get a piece of paper to frame that impresses most people, especially those that want to hire you but can’t determine if you know what you are talking about or not. Lastly, if you go to the right school you can meet people that might be useful to know in the future for different reasons.
The Internet has really changed all of those things, you can network pretty easily these days without a class ring, and there are lots of ways to earn accredited diplomas online. If you are interested in what we think is the most important part — the education — there are many options for that too.
Years ago, while the GPLv3 was still being drafted, I got a chance to attend a presentation by Richard Stallman. He did his whole routine as St IGNUcius, and then at the end said he would be answering questions in a separate room off to the side. While the more causal nerds shuffled out of the presentation room, I went along with a small group of free software aficionados that followed our patron saint into the inner sanctum.
When my turn came to address the free software maestro, I asked what advantages the GPLv3 would have to a lowly hacker like myself? I was familiar with the clause about “Tivoization“, the idea that any device running GPLv3 code from the manufacturer should allow the user to be able to install their own software on it, but this didn’t seem like the kind of thing most individuals would ever need to worry about. Was there something in the new version of the GPL that would make it worth adopting in personal or hobby projects?
Interestingly, a few years after this a GPLv2 program of mine was picked up by a manufacturer and included in one of their products (never underestimate yourself, folks). So the Tivoization clause was actually something that did apply to me in the end, but that’s not the point of this story.
Mr. Stallman responded that he believed the biggest improvement GPLv3 made over v2 for the hobbyist programmer was the idea of “forgiveness” in terms of licensing compliance. Rather than take a hard line approach like the existing version of the GPL, the new version would have grace periods for license compliance. In this way, legitimate mistakes or misunderstandings of the requirements of the GPL could be resolved more easily.
Contrary to popular belief, LISP does not stand for “lots of irritating spurious parenthesis.” However, it is true that people tend to love or hate this venerable programming language. Whichever side of the fence you’re on, many of the ideas it launched decades ago have become staples of other newer languages. How much C code do you think it takes to make a functional LISP system? If you guessed more than 200, you’ll want to go look at this GitHub repository.
Actually, the code isn’t as good as the (sort of) literate programming white paper on the program, but it gives a good overview of how 200 lines of C code can produce a working LISP-like language good enough to create its own eval loop. It does lack memory handling and error detection, so if you really wanted to use it, you’d probably need to spruce it up a bit.
The BBC micro:bit has been with us for about eighteen months now, and while the little ARM-based board has made a name for itself in its intended market of education, we haven’t seen as much of it in our community as we might have expected.
If you or a youngster in your life have a micro:bit, you may have created code for it using one of the several web-based IDEs, a graphical programming system, TypeScript, or MicroPython. But these high level languages are only part of the board’s software stack, as [Matt Warren] shows us with his detailed examination of its various layers.
The top layer of the micro:bit sandwich is of course your code. This is turned into a hex file by the web-based IDE’s compiler, which you then place on your device. Interestingly only the Microsoft TypeScript IDE compiles the TypeScript into native code, while the others bundle your code up with an interpreter.
Below that is the micro:bit’s hardware abstraction layer, and below that in turn is ARM’s Mbed OS layer, because the micro:bit is at heart simply another Mbed board. [Matt] goes into some detail about how the device’s memory map accommodates all these components, something essential given that there is only a paltry 16 kB of RAM in hand.
You might wish to program a micro:bit somewhat closer to the metal with the Mbed toolchain, but even if that is the case it’s still of interest to read a dissection of its official stack. Meanwhile, have a look at our review of the board, from summer 2016.
There is often an observable difference between what is considered the right thing to do, and what actually is being done.
Terry Pratchett said it best when he made Death declare mercy and justice nonexistent: “TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF JUSTICE, ONE MOLECULE OF MERCY.” (Note that Death is not shouting, he simply speaks upper case.)
We can’t measure justice and mercy. These are collective fictions — things we agree to believe to enable us to get along — and finding consensus on the immeasurable extends to political systems, religion, and most of economics. In a recent article [zwischenzugs] makes the point that methodologies in software development fall into the same category. Like collective societal fictions, methodologies tend to elicit strong emotional responses among those dealing with them.
A software development methodology is a playbook for getting from nothing to something. It’s a control system for how people working on the project spend their time. And there are a lot of these prescribed methods, from Agile to Waterfall, and any combination of letters is likely to turn an abbreviation for a methodology. An interesting game when hanging out in groups of software engineers is to start the “Have you ever tried the…” conversation. Just don’t expect to move to another topic anytime soon.
One disheartening aspect of methodologies is their resistance to scientific scrutiny. Two samples of development teams will differ wildly in so many characteristics that a meaningful comparison of the way they organize their work is not possible. Which will leaves us with anecdotes and opinions when discussing these things.
Current opinions regarding the impact of methodologies on the success of a project range from ‘marginal’ to ‘essential’. The latter position is mainly propagated by consultants selling agile certifications, so you may want to take it with a grain of salt. Whether a team adheres strongly to the methodology or adopts it in name only, it’s obvious they serve a purpose — but that purpose may not match the face value of the method.