tl;dr RTL8251B does not need a firmware blob

https://lists.openwrt.org/pipermail/openwrt-devel/2025-Febru...

It figures that Realtek is a key part of the story. The availability of Realtek PHYs and NICs is what's finally allowing 2.5GbE and 5GbE to go mainstream for consumer equipment. Aquantia got bought by Marvell and ended up with enterprise-level pricing on all their stuff. Intel completely tanked their reputation for NICs with a few failed attempts to implement 2.5GbE support, and haven't even tried to introduce a consumer-grade 5GbE option. But now that Realtek is in the game, 2.5GbE is widespread in new desktop motherboards and fairly cheap in USB Ethernet adapters.

Indeed, running latest OpenWrt release is the fix, yes.

> Implement additional obfuscation and OS checks in the Android app

Hold my beer.

> Has anyone don this or could anyone point me in the right direction?

Policy based routing https://blog.scottlowe.org/2013/05/29/a-quick-introduction-t...

You can't beat gdb+opencd.

SoftICE is actually something different, it's like kernel mode debugger, so you could essentially freeze the running kernel at any time and poke into the system internals.

Yes, I know. There was a continuation of it called Syser[1] but it is dead long ago too. Even the site of the company is not available anymore, it seems.

[1] https://syser-debugger.soft32.com/

> Which 2FA would mitigate.

Or Rust, right? </sarcasm> https://github.com/php/karma/search?q=exec

Qt itself, like for example https://github.com/qt/qttools?

Good suggestion. Code snippets showing the naming style they use:

    connect(contextShortcut, SIGNAL(activated()), this, SLOT(showContextDock()));

    connect(m_messageView->selectionModel(),
        SIGNAL(currentColumnChanged(QModelIndex,QModelIndex)),
        SLOT(updateLatestModel(QModelIndex)));

Taken from https://github.com/qt/qttools/blob/7ec161d6f/src/linguist/li...

It's almost there </sarcasm>:

  origin git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  rpi https://github.com/raspberrypi/linux.git

  $ git diff --shortstat origin/linux-4.19.y..rpi/rpi-4.19.y
  911 files changed, 321070 insertions(+), 5576 deletions(-)

  $ git diff --shortstat origin/linux-5.4.y..rpi/rpi-5.4.y
  810 files changed, 309964 insertions(+), 2518 deletions(-)

  $ git diff --shortstat origin/linux-5.5.y..rpi/rpi-5.5.y
  820 files changed, 308669 insertions(+), 2420 deletions(-)

That's really terrible recommendation. You should add firewall rules and allow SSH access only from trusted hosts, ideally over VPN. It's not about login attempts but about possible bug in SSH (and other network services), because it's all just software, written in C, so believe it or not, but it's there, it's not if but when.

The firewall isn't immune to exploitable bugs: https://nvd.nist.gov/vuln/detail/CVE-2017-18017

Likewise for VPN stacks: https://nvd.nist.gov/vuln/detail/CVE-2017-7521

If you're not prepared to expose a service to the world, you probably should run it at all. Ad hoc, non-standard configurations add substantial complexity and maintenance burdens. Complexity is the enemy of security, and having less time to manage more complex configurations is not a good recipe.

If you really need a service, then choose the best one and move on. The rule of thumb is that if you can reach a service, you should assume anybody else can, as well. This is especially true regarding SSH. I've seen plenty of servers p0wned via SSH, but never by breaking SSH. Instead the vector was always through an SSH user's computer infected by malware.

You want secure SSH? Disable password authentication and force everybody to use smartcard authentication like a Yubikey. I do rate limit SSH access using OpenBSD PF, but only because the authentication failures fill up and pollute the logs.

Have you seen yubikey/smartcard being used for sshin a large team? Would love to hear about your setup and learnings.

OpenSSH is solid piece of software. It hasn't had any (public) authentication bypasses that wasn't configuration related since it started to look like it looks today. Multiple skilled teams have looked at it thoroughly since. It has also been hardened with things like privsep and sandboxing.

This is not OpenSSL. Language alone does not make a product insecure. For practical purposes it is certainly not just a matter of when.

Contrast that with your VPN product, which probably falls over if someone looks at it funnily. Unless your product is called Wireguard, and we are ten years in the future, perhaps.

> That's really terrible recommendation

it would be if it was meant to be comprehensive.

Absolutely this. Sad to see how many people refer changing ssh port to non-standard as "security" measure.

Every little bit helps. I have hosts I access from "where ever."

It's fallen out of favor these days, but if you're running on firewalls that can be configured for port knocking consider doing that. A non-sequential knock pattern that unlocks the remote IP for X amount of time can prevent a ton of grinding attacks.

Add a TLS auth channel to the portknock with a wait window and OTP and you are really in business with this approach.