Voxel Custom firmware build for R7800 v. 1.0.2.94SF

[xyzzy]

Have you tried to replace the two older ones with the new one (with a symlink to the new one)?
Maybe the old ones are required for some compatibility?

Netgear uses openssl 1.0.2h for everything, of which I found 27 libraries and programs. One is libcurl, version 7.70.0, which is used by 4 additional programs.

Actually, that's wrong. The fbwifi program is linked against 0.9.8, which isn't present as a file in the image. So it probably doesn't work. But I think sometimes Netgear hides libraries inside archives or downloads them, so it could be in there somewhere.

One of these is "fbwifi". Don't know what it does. It's statically linked to an old libcurl 7.32.0. Netgear didn't provide the source to this program.

In Voxel's firmware, fbwifi uses the old OpenSSL 0.9.8p that is also only provided as a binary library. In Netgear's firmware, it uses the same OpenSSL as everything else (1.0.2h).

Voxel's firmware uses a fbwifi that was compiled with gcc 3.3.2. Netgear's newest firmware uses one compiled by gcc 4.6.

So my theory is Voxel has used an version of fbwifi from an old Netgear firmware and has not updated it. He's keeping the old OpenSSL version around just for this program. OpenSSL is not ABI compatible across major releases, so you can not take a program built for OpenSSL 0.9 and swap in a OpenSSL 1.0 or 1.1 library at run time and expect it to work.

The OpenSSL 0.9.8p Voxel has used has more vulnerabilities, including a 9.3, than the 1.0.2h vulnerabilities in Netgear's firmware.

Now for the other OpenSSL versions. Voxel's firmware has 25 libraries and programs using OpenSSL 1.0.2u, including those using it via libcurl. 14 are binary only from Netgear. 11 are compiled from source. There is probably not a good reason the opens source ones are still using OpenSSL 1.0.2. One of these is the transmission bittorrent program, which does support OpenSSL 1.1.0+, and being effectively a server that gets connections from random people out on the internet, is one of the things you really don't want vulnerabilities in.

Now for OpenSSL 1.1.1o. Virtually nothing uses it. There's `wget-ssl`, `openvpn` and `stubby`. That's it.

 

[Voxel]

What is the purpose of this research? It was discussed already. And it was enough just to ask me. Otherwise, you have quite a few wrong suppositions, conclusions and mistakes.

(1) fbwifi

What is it:

NETGEAR Facebook Captive Portal version 1.0.3

fbwifi <devicename> <serial_number>
devicename Device model name (i.e. R6300v2)
serial_number Device valid serial number


The same version in both the stock firmware V1.0.2.90 and in my version as well (the same output, “version 1.0.3”).

In Voxel's firmware, fbwifi uses the old OpenSSL 0.9.8p that is also only provided as a binary library. In Netgear's firmware, it uses the same OpenSSL as everything else (1.0.2h).

No, you are wrong. ‘fbwifi’ from the latest stock firmware V1.0.2.90 uses OpenSSL 0.9.8:

0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libssl.so.0.9.8]
0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.8]
0x00000001 (NEEDED) Shared library: [libm.so.0]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.0]

Voxel's firmware uses a fbwifi that was compiled with gcc 3.3.2. Netgear's newest firmware uses one compiled by gcc 4.6.

No. Latest version of ‘fbwifi’ from V1.0.2.90 is compiled by GCC 4.6-linaro. I use ‘fbwifi’ from more recent versions of GPL compiled by ordinary version of GCC 4.6.2 (not Linaro).

‘fbwifi’ is rather unnecessary and was used in earlier NETGEAR routers, but there are still references to ‘fbwifi’ settings in datalib and WebGUI, so I kept it. In the stock firmware ‘fbwifi’ is not working due to the lack of OpenSSL 0.9.8, but my firmware check procedure gives me an error, that's why I added the built OpenSSL 0.9.8 to avoid this bug (it's not good to have a broken non-working program in the firmware).

(2) OpenSSL 0.9.8.

What's more openssl 0.9.8p that is included is only as a binary, no source. Probably a GPL violation there.

Violation of GPL license is if someone changes the codes of open-source and does not publish these changes. OpenSSL 0.9.8 is used ‘as-is’ (taken from the stock) w/o any changes. So it has no sense for me to re-compile it every time. This version does not provide any possibility for acceleration (ASM/NEON acceleration) and moreover ‘fbwifi’ (what is using 0.9.8) is rather ‘ghost’ program.

So, it is not a violation of the GPL (at least no more than using a precompiled modified version of 'miniupnpd' in the NG GPL w/o source codes).

(3) OpenSSL 1.1.1.

While 2.94.4 does contain OpenSSL 1.1.1n

No. 1.0.2.94.4SF uses OpenSSL 1.1.1o:

2. OpenSSL v. 1.1.1 package is upgraded 1.1.1n->1.1.1o (fixing CVE-2022-1292, score 9.8, Critical).
https://nvd.nist.gov/vuln/detail/CVE-2022-1292

'transmission':

There is probably not a good reason the opens source ones are still using OpenSSL 1.0.2. One of these is the transmission bittorrent program, which does support OpenSSL 1.1.0+, and being effectively a server that gets connections from random people out on the internet, is one of the things you really don't want vulnerabilities in.

‘transmission’ uses not only OpenSSL, but also libcurl. libcurl must use OpenSSL 1.0.2 because many pre-compiled applications such as net-cgi or e.g. the ReadyCLOUD add-on are compiled with OpenSSL 1.0.2. This means ‘transmission’, if compiled with OpenSSL 1.1.1 will use explicitly 1.1.1 and implicitly 1.0.2 (libcurl). This results in a conflict of different incompatible versions (broken functionality or even crash).

Now for OpenSSL 1.1.1o. Virtually nothing uses it. There's `wget-ssl`, `openvpn` and `stubby`. That's it.

Using OpenSSL 1.1.1 in 'stubby' (and in getdns and unbound as well) automatically enables TLS 1.3 (DoH) which is necessary for many users. The advantage of using OpenSSL 1.1.1 for OpenVPN is obvious. For 'wget' as well. Migration to OpenSSL 1.1.1 of other components is not possible at this time.

P.S.

And @R. Gerrits rightly pointed all above in his post:

I think Voxel tried to change as much as possible to use the latest openssl version. But not everything was compatible.
According to the change logs:

Voxel.

 

[Voxel]

interesting thing:
Netgear GPL sources for 1.0.2.90 still has a binary-only fbwifi that is linked against libssl.so.0.9.8. -> if that FW really only has openssl 1.0.2h then it would mean that the Facebook Captivity portal option for the guest-wifi is probably broken.

Just FYI: it was reported by me to NG yet in 2017...

https://www.snbforums.com/threads/r7800-new-firmware-1-0-2-28.38096/post-315976

Voxel.

 

[HELLO_wORLD]

All of that proves that @Voxel has worked hard and deep into his firmwares, and is doing his best to update from the official firmware (to keep acceleration) as best as he can, without breaking it, and without giving his work for free to Netgear either… It is like walking on a rope, and he is doing extraordinary well

That being said, fbwifi is useless and I will disable it (I can not trust something related to Facebook in my router, as well as these Amazon binaries…)
I don't want that: https://www.facebook.com/facebook-wifi
Plus knowing it is using old binaries with known CVE, more reasons to ditch it

I will tell you over time if it creates problems.

 

[NetBytes]

All of that proves that @Voxel has worked hard and deep into his firmwares, and is doing his best to update from the official firmware (to keep acceleration) as best as he can, without breaking it, and without giving his work for free to Netgear either… It is like walking on a rope, and he is doing extraordinary well

That being said, fbwifi is useless and I will disable it (I can not trust something related to Facebook in my router, as well as these Amazon binaries…)
I don't want that: https://www.facebook.com/facebook-wifi
Plus knowing it is using old binaries with known CVE, more reasons to ditch it

I will tell you over time if it creates problems.

LOL I did this early this morning after reading @Voxel's posts, especially because I have done so to transmission for years now.
So far no issue.

 

[xyzzy]

No, you are wrong. ‘fbwifi’ from the latest stock firmware V1.0.2.90 uses OpenSSL 0.9.8:

If you were to read the next paragraph under the one you quoted, you would see I already noticed this mistake and corrected it.

No. Latest version of ‘fbwifi’ from V1.0.2.90 is compiled by GCC 4.6-linaro. I use ‘fbwifi’ from more recent versions of GPL compiled by ordinary version of GCC 4.6.2 (not Linaro).

That's what I said. Netgear's fbwifi is compiled by gcc 4.6. I don't see a reference to gcc 4.6 in your firmware's version of fbwifi. Just gcc 3.0, 3.3, and 3.5 symbols. But the executable you have used has stripped sections from the elf file, and normally the gcc version stamp would be in the comment section. So, it could be compiled by gcc 4.6.2, can't really tell. The code appears to be almost exactly the same. The difference is in the ELF file containing it.

Violation of GPL license is if someone changes the codes of open-source and does not publish these changes

This is a common misconception. GPL requires offer to provide source, even for an unmodified version. Of course, if the source is commonly available, no one really demands the group who have given them the binary must host the website the source is on, but GPL still requires it. In some cases, tracking down the source code to build your firmware, which I have done, was quite a pain. I never found the temperature sensor driver code (but I don't care about it, so I didn't look that hard).

You mention miniupnpd that Netgrear has not provided source for. This is because miniupnpd is BSD, not GPL. Consider openvpn, which is GPL and, according to r7800_gpl_source_list.txt, unmodified by Netgear, yet they still provide source. I think Netgear has been quite careful to provide source for every GPL program, modified or not.

‘transmission’ uses not only OpenSSL, but also libcurl. libcurl must use OpenSSL 1.0.2 because many pre-compiled applications such as net-cgi or e.g. the ReadyCLOUD add-on are compiled with OpenSSL 1.0.2.

There is simple solution for this. Build two versions of libcurl. One linked against openssl 1.0.2 and another against openssl 1.1. Use the old version with Netgear's binary only programs.

It's also possible to edit the ELF file to remove or modify the shared libs it uses. Of course it still needs the code a shared lib was supposed to provide, but one can change the file it gets it from. Since OpenSSL is not ABI compatible across major versions, there is no easy way to upgrade binary Netgear programs. But all open source programs can use newer libs. It is not necessary to hold them back because of libcurl.

There is a hard way to upgrade Netgear programs. Create a shim library that presents an OpenSSL 1.0 ABI compatible interface but does everything by making calls into OpenSSL 1.1. It's probably not really that hard, since only a small fraction of the code in libssl and libcrypto gets used and the API of that code is practically the same between the two versions.

 

[xyzzy]

That being said, fbwifi is useless and I will disable it (I can not trust something related to Facebook in my router, as well as these Amazon binaries…)

I would like it to not even be in the firmware in the first place. Nuke it from orbit as they say, it's the only the way to be sure.
The sames goes for the AWS code. I don't need code that contacts Amazon on my router at all.

Or that funjsq thing. That one looked like it downloaded a vpn client from a server in China and ran it on your router, with your internet traffic going through it. There ought to be some national security law against having stuff like that in the firmware at all.

But, how do I get a firmware that doesn't even have this stuff to begin with? We get to this:

What is the purpose of this research? It was discussed already. And it was enough just to ask me. Otherwise, you have quite a few wrong suppositions, conclusions and mistakes.

I need to reverse engineer Voxel's firmware so that I can built it myself and change things I want, like eliminating fb and aws and getting rid of old versions of openssl.

 

[NetBytes]

<snip>

I need to reverse engineer Voxel's firmware so that I can built it myself and change things I want, like eliminating fb and aws and getting rid of old versions of openssl.

FWIW: If stopping/disabling the 'rouge' processes is enough, there have been threads discussing disabling many 'rouge' processes from the router.
I contributed a compilation thread of the combined knowledge right here.
While there is a lot of accumulated knowledge in that thread, I strongly suggest using the @kamoj addon if you want an integrated way
to easily disable the things you would like to.

 

[xyzzy]

FWIW: If stopping/disabling the 'rouge' processes is enough, there have been threads discussing disabling many 'rouge' processes from the router.
I contributed a compilation thread of the combined knowledge right here.
While there is a lot of accumulated knowledge in that thread, I strongly suggest using the @kamoj addon if you want an integrated way
to easily disable the things you would like to.

It is of course not always easy to disable something. Remove the link in /etc/rc.d so it doesn't start at boot, but then something calls the init script directly. Delete the init script. Something starts the daemon directly. Remove execute permission. Something adds is back. Delete every trace! Take that streamboost! It's not really deleted, the overlay has just marked it as gone, wipe the overlay and everything comes back. Zombie streamboost is back to destroy the flash chip!

Only way to be sure is to not even have it in there in the first place.

And one can make the firmware smaller by omitting things. Then, there is more space for other things! It would be nice to have strace to debug problems.

Also the R7800 is short on RAM. Even though firmware fits in flash, there is a benefit to reducing RAM usage. If a daemon runs, even if it doesn't do anything (disabled streamboost daemon, I'm looking at you) it still takes RAM. Shared libraries can use the same RAM for every process that uses the library. But if running processes use three different OpenSSL versions, then this takes more RAM than if you only used one or two versions. Loaded kernel modules also take RAM, even if they are unused.

So what I want to do is:

Make it so I can actually build myself a working R7800 firmware. Which I've done.
Fix the Openwrt config system so one can use the menu to turn things on and off.
Add config options for commonly disabled things like the snitch programs and streamboost. The thread you linked to is a great list of such things.

 

[manup85]

Hello voxel, I'm suffering a recurrent issue using readycloud. Not sure if anyone had or have same problem. I have tried multiple step, flashing over, factory reset, flash latest snapshot but as soon readycloud is start working, after 10-15 hours I loose ETH ports but wifi is keep working. It seems something is filling the pipe or not sure. Anything needed from my side that I should share? Thank you

 

[HELLO_wORLD]

Hello voxel, I'm suffering a recurrent issue using readycloud. Not sure of anyone had or have same problem. I have tried multiple step, flashing over, factory reset, flash latest snapshot but as soon readycloud is start working, after 10-15 hours I loose ETH ports but wifi is keep working. It seems something is filling the pipe or not sure. Anything needed from my side that I should share? Thank you

My personal answer would be: get rid of ReadyCloud…
But not the answer you are looking for. I believe it should work on @Voxel ‘s firmware, so someone should be able to help you with that.

 

[manup85]

My personal answer would be: get rid of ReadyCloud…
But not the answer you are looking for. I believe it should work on @Voxel ‘s firmware, so someone should be able to help you with that.

Hello_world, unfurtunatly is the only solution for now with my ISP and private IP to be able to create my NAS with external HDD. if someone as an answer or needs some logs let me know.

 

[fossil]

Hello_world, unfurtunatly is the only solution for now with my ISP and private IP to be able to create my NAS with external HDD. if someone as an answer or needs some logs let me know.

Most of us have readycloud disabled. But here are few things that you can look into.

Do all ports fail? Are you able to ping the device on the failed port (trying to understand if it still has the IP assigned)?
What happens if you disconnect the eth cable on the failed port and connect it back again?

Do you have any switch connected on eth port? (if yes disconnect it and see if the eth ports fail)
Do you have IPs reserved for your devices under dhcp option from R7800 UI? (if no, reserve IPs for your devices and see if the eth ports fail)

NAS on sbc is a much better option. Install and configure samba, omv ... on sbc and you could have your NAS setup in very short time. (Just a suggestion, may not meet your requirement)

 

[manup85]

Most of us have readycloud disabled. But here are few things that you can look into.

Do all ports fail? Are you able to ping the device on the failed port (trying to understand if it still has the IP assigned)?

Do you have any switch connected on eth port? (if yes disconnect it and see if the eth ports fail)
Do you have IPs reserved for your devices under dhcp option from R7800 UI? (if no, reserve IPs for your devices and see if the eth ports fail)

NAS on sbc is a much better option. Install and configure samba, omv ... on sbc and you could have your NAS setup in very short time. (Just a suggestion, may not meet your requirement)

Do all ports fail? Are you able to ping the device on the failed port (trying to understand if it still has the IP assigned)? Yes all the port and there is no ip assigned so unable to ping you anything


Do you have any switch connected on eth port? (if yes disconnect it and see if the eth ports fail)
Do you have IPs reserved for your devices under dhcp option from R7800 UI? (if no, reserve IPs for your devices and see if the eth ports fail) I have one of the port connected to an extender. No ip reserved. Dhcp is active only at main router.

NAS on sbc is a much better option. Install and configure samba, omv ... on sbc and you could have your NAS setup in very short time. (Just a suggestion, may not meet your requirement). Not sure you mean samba like smb lan which I'm already using. But my isp is using private ip which I cannot access from the network. Readycloud is using vpn so it was working fine and I could access my hdd from Internet

Issue is fixed when I unregister from readycloud so as I said it seems more like something is filling some buffer and eth port get disabled. Wifi is working on the main router but not at the extender because eth access point port is disabled

 

[fossil]

Issue is fixed when I unregister from readycloud so as I said it seems more like something is filling some buffer and eth port get disabled. Wifi is working on the main router but not at the extender because eth access point port is disabled

So you have an extender connected on one eth port, it stops working after certain hours (with readycloud enabled). There is nothing else connected on any other eth port.

It still applies what I mentioned above and may be worth trying it out.

When eth port fails, what happens if you disconnect the extender cable from router and connect it back again?
Try to reserve the IP of your extender under (Lan Setup > Address Reservation) dhcp options? (see how it goes)

 

[manup85]

So you have an extender connected on one eth port, it stops working after certain hours (with readycloud enabled). There is nothing else connected on any other eth port.

It still applies what I mentioned above and may be worth trying it out.

When eth port fails, what happens if you disconnect the extender cable from router and connect it back again?
Try to reserve the IP of your extender under (Lan Setup > Address Reservation) dhcp options? (see how it goes)

all 4 port have something connected. the extender is using only one port. i have all 4 showing no ip when event happen but lights on the devices is on, which means port is not going down at layer 1.
i dont think it is related to extender if all ports are going down at the same time. it is something on the internal switch at the router itself.
btw, it is happening also if i disabled readycloud so some setting are still in. i will try to flash factory firmware and then voxel over. let me start from scratch

 

[Voxel]

let me start from scratch

I think it would be the best solution. I'l check ReadyCLOUD again. But note: it sometimes does not work (depends on NG service as well and the last could be not working today...).

Voxel.

 

[Voxel]

https://www.snbforums.com/threads/custom-firmware-build-for-r7800-v-1-0-2-94sf.78610/post-765570
https://www.snbforums.com/threads/custom-firmware-build-for-r7800-v-1-0-2-94sf.78610/post-765614

Out of topic.

So far I see at least four major bugs.

Sorry but I have been in software development for NETGEAR routers for 7 years (my hobby). I've been in commercial software development for 25 years, I've been in software development and research for 40 years, so I have some experience at least. Well I'm known a little bit in companies like EADS/Airbus, Toshiba, Toyota, Matsushita, Sony, Sekisui, T&G, etc.

I'm just not very knowledgeable about the law, so thanks for pointing out the GPL and OpenSSL 0.9.8

Basic: Software development involves such stages:

WHY/WHAT->HOW->Implementation

The most serious and costly bugs/mistakes are in the first stage. You have them... I see the same in the second stage as well. Implementation. I guess you see them yourself (your githib, I briefly checked).

The @NetBytes approach is the most right way. You don't need to be paranoid about destroying something that already works and works well enough. Better to research how it works, and what is enough to disable such functionality without disrupting other components.

Well. This is out of topic. Not related to my thread. Let us stop it here in my thread.

Voxel.

 

[manup85]

I think it would be the best solution. I'l check ReadyCLOUD again. But note: it sometimes does not work (depends on NG service as well and the last could be not working today...).

Voxel.

Hello Voxel,

tnx to looking at this. after 2 days of stability same issue occur even with stock FW V1.0.2.90. i have disconnected the extender but didnt fix the problem. the only way to get back ETH port is to reboot the router. at this point i'm not even sure if it is a software issue... i'll flash over your FW after disabling readycloud.