From the beginning of current year I am learning Docker. First result of this interest on my Github was publishing ccfactory tool, which was supposed to provide easy way to produce compiler toolchains. Almost like they were mass-produced in a factory, thus the name. However, since then I learned a lot and gained some experience. At the moment it is obvious to me, what I did then is not the best design. And because the project is still very fresh, I decided to start once again, from scratch, to create way better design that will be easy to develop and maintain.
Today is time to publish first step to this new design – binutils. I would not do that, but Docker Hub allows to have only one private repo, so the way that I do it disallows me to have it private anyway. So better idea is to describe it somehow to avoid confusion. As I wrote, this first step is binutils and this is simple container that contains binutils and nothing else. My goal is to finally make toolchain base on gcc version 3.3, which might sound weird, but this is what I needed in the past and is best way to prove what this new approach can achieve. With previous one, that I will call legacy from now on, I failed in that and before failing I did even more complicated Dockerfile, than originally planned. So, when finished this one will be proof of good design, I hope. Continue reading “New ccfactory on its way, binutils are already here”
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”
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”
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.
The time has come to start completely new project. I was present on the net since 2009. Till now, I had blog, named after my nickname. It had some troubles, though. Biggest one was problem with indexing the site by Google, which started with fall of co.cc domain from its index.
Because of that, I decided to start something completely new. Now it is time to introduce re-ws.pl – RE WorkStation. This blog will be very similar to the first blog, but I am going to focus on widely understood reverse engineering (and from time to time some hacking, electronics and other random stuff). I already have bunch of projects in status ongoing or planned, so I hope to push lot of interesting stuff in following months.
Two things that should have its continuations very soon are JCOP topic and LKV373A reversing. On the first one, I already published dump of memory during pre-personalization process, together with highlighting of most important fields and in second article, I described process of pre-personalization itself. Next goal is to document whole API, available during the process. Second topic, the LKV373A, is now after describing of general structure of firmware image and creation of Wiki page on github to gather all publicly available knowledge about the device. As mentioned in the article about firmware, goals are to have ability to compute firmware checksum and learn the compression algorithm. I will try to push forward both topics as much as I can. And to prove that I can do something about that I am publishing second part of the story just now.
I hope my work here will be useful to many people, mostly those that does not take technology for granted and willing to know inner workings of their stuff.