efforg/rayhunter#649

View on GitHub →
#649 Support for freetz-ng fritzbox firmware modification on

First off, thank you for the great talk at Def Con! I have a FritzBox 6850 5G with a Snapdragon X55 5G modem. I compiled a custom firmware using freetz-ng, so I have root.

I was just checking and /dev/diag is not available. I checked the kernel config, but couldn’t see any way to enable CONFIG_DIAG_CHAR and I honestly don’t know if that would be necessary. But I found online references, that the device could be exposed over a different name.

So after looking I found one suspicious one: /dev/mhi_DIAG

But also, when I queried /dev/usbtty2, I saw the modem there:

root@fritz:/home/rayhunter-daemon# echo -e "ATI\r" > /dev/ttyUSB2; cat < /dev/ttyUSB2
Quectel
RM500Q-AE
Revision: RM500QAEAAR13A01M4G
OK

Obviously I couldn’t run the installer, but after checking out the daemon, I didn’t see a way to override the device path in the config.toml.in

Is this generally something the project would be interested in pursuing? I would offer to create a package for freetz-ng if we can get this running. I probably can also work out the GPIO, to flash a red info light on the box on imsi catcher detection. The benefit for these devices is they usually run domestically over longer periods, and not ad hoc. Which could help in reducing false positives, or generally help in long time surveys.

1
Comments (3)

Obviously I couldn’t run the installer, but after checking out the daemon, I didn’t see a way to override the device path in the config.toml.in

I think for now you can symlink the device in the place where the daemon expects it, such as ln -s /dev/mhi_DIAG /dev/diag and it should work. Otherwise you’d have to patch the code yourself and build rayhunter-daemon from source.

I think we’d be open to make the path for /dev/diag configurable if there’s proof it actually helps for a particular device.

1

I was looking into it a bit more and tried your suggestion, but apart from an error in console about a missing battery, nothing is showing. As far as I can tell from the code, this error is not function breaking though, and after reading some more I think the issue lies with the mhi being a newer protocol over pcie, where I need to compile a kernel module to make the /dev/diag convert those signals.

I’ll see what I can do to make that work and keep this discussion updated, but it’s probably not going to be something the project is willing to support.

@hoinzy sorry for bringing this old thread up, but are there any hardware that you know in this project that is mains powered and stationary? I would like a device that can be permenantly powered and maybe also have external antennas for better reception.