Lately I play a bit with Docker containers. In a chain of problems that I have right now, I needed to have static cURL library on Debian. As it turned out linking cURL statically is not an easy task. Rather it causes a lot of problems, especially when trying this with packages available in Debian repos. After a long fight with these I decided to prepare my own distribution of cURL. But instead of creating usual deb package, I did it all on Docker and as a result, I have Docker image. In it I utilized possibilities of staged builds, where there can be few steps having in common only certain files. As a result I created base image, means the one created from scratch, where there are no other files, than the ones that we provide. So I provided only complete cURL install directory and musl libc to be able to run curl binary, as I did not want to tinker with cURL’s build system even more, than I did. Final image weights only ~1,5 MiB, so a result is really nice space saving compared to usual approach to Docker images. Inside, you can run curl binary separated from your operating system (to extent that Docker provides – remember, it is not virtualization!). Also it is possible to use libcurl to link your own binaries with it, this time completely statically!
As always, sources are on Github and this time there are also ready-to-use images on Docker Hub, so you can pull them directly, without need to build them. All instructions are on both pages and this is nothing unusual for any user of Docker, so I will not repeat myself here.
Few days back I published a hint that I am working on some hardware project, that utilized some networking, by publishing KiCAD footprints of connectors that I use. Now the time has come to reveal all the details. This was possible due to board being basically working.
And the project is Raspberry Pi Compute Module 4 carrier/base board. Just to give a brief here, it is a board that is meant to allow connecting CM4 SoM modules to network and take as little space as practically possible. I would call this device smallest possible CM4 carrier board, but then probably somebody will prove me wrong by designing something smaller. But to still be practical, it is almost the smallest it could, as it is exactly same footprint as CM4 itself. By making it even smaller, I would have to remove mounting holes, as they are exactly at the edges.
Getting to the interesting part, it is meant to connect to Ethernet and allow you to do whatever you like. The only thing you need to connect beside Ethernet is power via Micro USB connector. Worth to mention is that this is requirement of this particular iteration of the board, as it should be fairly easy to redesign it a bit to use PoE instead. Anyway, comparing to traditional Raspberry Pi, you get a lot of saved space at a cost of only 3 connector available (not counting UART header). And third, not mentioned yet, is microSD card slot, that is completely optional, but present in my case, as I use CM4Lite variant with no storage, so this is rather a useful feature. Getting rid of this requirement on CM4Lite SoMs might be a subject of future research from my side, as I heard about network boot on RPi, but have not tried it myself yet. Continue reading “uCM4 – really small CM4 carrier board for network projects”→
This time just a quick info. I just published library of KiCAD footprints that I made recently for my new project. The project itself has not been published yet and I want to keep it that way until I get first working prototype (what I hope will happen really soon). Meanwhile I am publishing this small library of footprints that I made for it with perspective of extending it in future with other hardware projects.
Still this is quite new topic for me as I have no electronics education, nor professional experience, so there is still a risk that I may fail at what I do and abandon such kind of projects. But for now, I just finished validation of footprints published here with a board that I ordered from JLCPCB, so you are guaranteed that they are fine (except one marked explicitly as such). Continue reading “My small library of KiCAD footprints”→
Few months ago I wrote a tutorial about creating Linux distribution consisting of just busybox as its userspace. In the meantime I worked a bit with docker and it sounded like nice next step in learning docker to automate the process of creating Linux distribution using it. As a result, today I present Linux distribution built with docker and based on my previous tutorial. I called it busy-linux due to it consisting of only busybox at the moment. My plan is to develop it further, most likely for private purposes only, so there might not be much happening in the project, but for sure I want to create dynamically linked variant in the near future, as this is what my use case requires. In the meantime feel free to try it yourself. Continue reading “Creating one-file Linux distribution with docker”→
For some time already, I am working on a big reverse engineering topic. I hope, I will be able to present something on that in future. Of course this would be something almost unique, if finished. For now I want to present a tool that I made while working on this big thing (as a side note, it’s not the first one, cc-factory was also created for that purpose).
What I had to do, was to read contents of EEPROM, that I found on board, I am analyzing. It is quite obscure, as Google did not return anything useful (beside Taobao auctions). Fortunately I learned that chip it is connected to expect EEPROM from the 93Cx6 series. So, to not break anything, I bought few similar memory chips from usual source. In the meantime, I found that this thing talks Microwire protocol, which is quite similar, but not identical to SPI. This means that flashrom is not an option here. It is however similar enough to SPI that some people were successful in talking to these EEPROMs on SPI bus. Unfortunately, I did not have any device that was confirmed successful and I did not want to experiment with low chance of success. Luckily for me, there is simple Arduino library, that bit-bangs the protocol. I am not a big fan of Arduino, but I have few Digispark boards, so I decided to give it a try. Obviously, the fact that this post appeared means, I was successful. Nevertheless, it was not that easy. At least for me, so I share my experience, just in case someone have similar problem. Enough of this, let’s read (and write, if you want) Microwire 93C56 EEPROM with Arduino sketch and Digispark board, via USB virtual serial port. Because, why not? 🙂 Continue reading “Reading and programming 93Cx6 EEPROM with Digispark”→
Today, I would like to show something different, than usual reverse-engineering, that appears on my blog usually. I needed to prepare a Linux distro for myself to be able to run it on my PC. But not the ordinary operating system that we download from webpage, then use fancy graphical installer to select, what we want and where. My goals were very specific. First was to have it custom-compiled. With that in mind there aren’t many choices left (maybe Gentoo?). Second was to not cross 16 MiB boundary. Why exactly that? That’s simple. I have old (15 years old to be precise) SD/MMC card made for Canon of exactly that size. Quick check showed me that this is possible. I tried buildroot and it failed to fulfill second requirement and I decided not to continue, despite the obvious optimizations on kernel modules, I could do. It’s simply too complex for such a simple task. If not buildroot, then let’s go and see how to do such thing from scratch!
Basically the plan is to have custom Linux distro compiled from scratch. It may sound like something incredibly complex and hard to do. But it’s not. There are just few problems one must learn on how to overcome. The most problematic constraint in my case is, obviously, 16 MiB limit. To not exceed it, I have to use busybox as my userspace. This by the way simplifies distro development significantly. Busybox works the way, that, if linked statically, requires only one, single binary to be able to work correctly. So, to sum up, on software side, we need Linux and busybox. You may wonder, how do I want to boot that system, then? Well. I said I need Linux 🙂 Maybe some people know, some does not, that Linux is itself a boot loader of some kind. At least, when using UEFI and this is what I want to use, it can be loaded directly by UEFI firmware. But that’s another thing to note – I will describe a way to prepare a distro for UEFI – it won’t be as simple as that, for legacy BIOS.
The whole plan will look as follows:
Compile Linux kernel
Compile busybox (statically and stripped!)
Prepare initramfs with whole userspace
Format drive as EFI System Partition
Combine kernel and initramfs into single binary
Optionally sign the binary, in case we want Secure Boot to be enabled
Having a tailored cross compiler is a problem I encountered couple of times in the past. Of course there are solutions to that problem like great crosstool-ng or more complex buildroot. In most cases crosstool-ng (ct-ng) can solve them. But whatever the tool we use, it has always its own drawbacks. For ct-ng these are small number of supported versions of toolchain components and huge dependence of environment, where it is started. The latter is even more problematic, because of the way continuing interrupted build work in ct-ng. Obviously if you want to build in example one compiler for ARM and one for MIPS, both consisting of latest tools, then it is not a problem.
But I have another use case for compiling toolchains. I do some reverse engineering from time to time. Nowadays many products have Linux under the hood and often there is no chance to get any SDK for them. But having ability to build something for the device can help a lot, either to run it there, or link with found tools and run in emulator. But I could also imagine that outside the reverse engineering field there might be a need to get toolchain in exact configuration, which is sadly not available via ct-ng or buildroot. Anyway, in any case where ct-ng or buildroot are not applicable, there is third way – docker. And this is the way I chose. This is how CC Factory appeared. It is docker container that builds gcc cross compiler on first startup and lands you in an container that have working compiler for the platform of your choice. And it does not require big effort to port it for the next architecture, or different tool version, unless the changes between the versions were really significant. Continue reading “Meet CC Factory – a factory for cross compilers”→
I had a project in mind featuring rain sensor, present in Peugeot 407 car, among others, probably. However, reality is that it is on my todo list for years now and I don’t think I will do it ever. But, I already bought the sensor in the past and it was lying in my drawer. So why not to disassemble it and figure out the pinout.
To be precise in what I am talking about, here are some magic values, I know about this thing:
Few months ago, as part of an effort to reverse engineer Lenkeng LKV373A HDMI to Ethernet converter, I announced disassembly plugin for radare2. This week it has been officially released by radare2 team.
My patches are integrated into radare2 version 4.1.0 and 4.1.1. They also should be currently present in GUI variant of radare2 – Cutter. Its version 1.10 is based on radare2 code version 4.1.1.
At the moment of writing this, Arch Linux still do not have these versions in repository, but I expect updates will appear in few days.
GF-07 is dirt-cheap GPS locator. You put SIM card in it, send SMS and you know where it is. That’s it. But not for me. I like to know what I am using, especially if it is that cheap and such obscure device as this one. It comes together with manual that is written in so bad English that I barely understand anything. Immediately after opening SIM slot, one can see few test pads. Fortunately all of them are described in silkscreen. Let’s see what can be done with it as a one-evening hack.