<html><head></head><body><div dir="auto">Hello Denis,<br><br>Thank you for your elaborate response.<br><br>> The job to do to make that happen is to take the firmware binary which<br>is in 8051 assembler and produce source code from that.<br><br>> The good news is that the firmware is really small and that it's not<br>very hard to do compared to reverse engineering other WiFi firmwares.<br><br>> The bad news is that last time I looked automated tools like retdec<br>didn't support this CPU architecture so it might require a bit of time.<br><br>> But given the size it's probably coded in assembly directly, so maybe<br>that makes it easier, especially if you can at the end produce the same<br>binary (see below why).<br><br>Thanks a lot for this information, but would you be so kind as to share some resources on how to embark on this? This would be my first reverse engineering project, so if you have any similsr tutorials or other resources I'd be glad.<br><br>I will have enough time from this weekend for this, and since you claim this is doable, I would certainly want to push through. I've heard the major obstacles for libre kernel to be networking only, this might help in running on a few more computers since Realtek's this line of chips are actually really ubiquitous and indeed upstream Linux does have the drivers in-tree, I've tested the same chip on it.<br><br>> Once this is done the next step could be to somehow get this source<br>code to build and get the same binary than the one you extracted from<br>the driver. This is important as it could make most distributions<br>accept the source code without having to do a lot of source code<br>reviews.<br><br>Noted. But why would distributions have to worry? Wouldn't the driver and firmware be in-tree and compiled with the kernel? <br><br>Apologies for my ignorance, if I might have said something wrong.<br><br>Regards,<br><br>Divya Ranjan<br></div><br><br><div class="gmail_quote"><div dir="auto">On 25 October 2024 23:28:45 GMT, Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><div dir="auto">On Sun, 20 Oct 2024 02:28:22 +0000<br>Divya <divya@subvertising.org> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">What exactly includes non-free firmware? I linked the firmware for<br>the chip that is licensed under GPLv2. I am aware that linux-libre is<br>completely free software. But the chip in question has its firmware<br>publicly available as free software. Unless I'm missing something,<br>where is the non-free firmware?<br></div></blockquote><div dir="auto"><br>Assuming upstream Linux has a driver for these, there is a way to get<br>this fixed relatively easily compared to other nonfree firmwares, and<br>have the firmware get included in FSDG distributions.<br><br>The job to do to make that happen is to take the firmware binary which<br>is in 8051 assembler and produce source code from that.<br><br>The good news is that the firmware is really small and that it's not<br>very hard to do compared to reverse engineering other WiFi firmwares.<br><br>The bad news is that last time I looked automated tools like retdec<br>didn't support this CPU architecture so it might require a bit of time.<br><br>But given the size it's probably coded in assembly directly, so maybe<br>that makes it easier, especially if you can at the end produce the same<br>binary (see below why).<br><br>So the first thing to do is to try to find a way to understand which<br>parts of the firmware is code and which part is not. Maybe writing code<br>to follow all instructions with radare2 or similar software could do<br>that somehow. We have the address at which code starts to execute<br>already.<br><br>Once this is done the next step could be to somehow get this source<br>code to build and get the same binary than the one you extracted from<br>the driver. This is important as it could make most distributions<br>accept the source code without having to do a lot of source code<br>reviews.<br><br>Also if I remember well there are several sections inside the firmware<br>binary as there are gaps that can seen with hexdump -C. Maybe some<br>zones are data or maybe there is a simplistic bootloader and then code.<br><br>After that, it could be a good idea to comment a bit the source<br>code and to use some meaningful names. The driver has some information<br>on the communication between the driver and the firmware.<br><br>So it might be possible to name the registers / memory address used to<br>do this communication and they are probably easy to find as the<br>constant used by the driver are also easily found inside the 8051 code,<br>but I've not been able to confirm that as I didn't try to modify the<br>firmware to do experiments with it. If I remember well there is some<br>comments or variable / functions names about a mailbox<br>communication interface in the driver somewhere.<br><br>See <a href="https://libreplanet.org/wiki/Group:Hardware/Components/WiFi/Realtek">https://libreplanet.org/wiki/Group:Hardware/Components/WiFi/Realtek</a> for<br>more details, especially this link:<br><a href="https://libreplanet.org/wiki/Group:Hardware/research/e-readers/Kobo/Aura_H2O_Edition_2#WiFi_firmware">https://libreplanet.org/wiki/Group:Hardware/research/e-readers/Kobo/Aura_H2O_Edition_2#WiFi_firmware</a><br><br>Also a difficulty here would be to understand where to stop, for<br>instance it's unclear if a partially commented source code would be OK<br>or not, but maybe other people can comment on that. If it's easy enough<br>to comment all the source code, doing that might avoid complex<br>discussions and save a lot of time.<br><br>Denis.<br></div></pre></blockquote></div><div dir="auto">Divya Ranjan, Mathematics, Philosophy and Libre Software</div></body></html>