new killer scope in town - a true game changer from R&S - RTB2002 & RTB2004

[Kean]

Thanks a lot! Can some more people with official access to the firmware also post the SHA2-256 sum of the firmware? (MD5 has been mentioned, but that's been obsolete for almost 30 years.)

Code: [Select]

% sha256sum RTB22_Firmware_v03.00.zip
4989a4f92f61b2e6f5cfc7cfd5653bc0326056d4edadbd962c12377511453dd9  RTB22_Firmware_v03.00.zip
% sha256sum RTB24_Firmware_v03.00.zip
56de9016b75385af57d7d2e550ac682933edf67af0ff2956f920df96830d3d9c  RTB24_Firmware_v03.00.zip

Edit: Good point noted by another member, so here are the values for the FWU files after extracting from the ZIP.

Code: [Select]

% sha256sum RTB*
ced7c8cca2053d9bbd78b4c99aec8c83c729ea8be71d0c05697bbae4b7769c1f  RTB2002.FWU
73d6a8a695ea9338f4cf9a6672721d82d5afc4a8bbe1ab6dfefa2607872bb3c2  RTB2004.FWU

But as mentioned by tv84 below, the R&S firmware upgrade process almost certainly checks firmware signature and it would be quite some task to fake that let alone reverse engineer the firmware to do whatever it is you think someone wants to do to your scope... implement Doom I presume.

[tv84]

Thanks a lot! Can some more people with official access to the firmware also post the SHA2-256 sum of the firmware? (MD5 has been mentioned, but that's been obsolete for almost 30 years.)

  Do you have any clue of the probability of someone creating a different R&S signed FW package with the same MD5 hash as the one you downloaded?

Only R&S would be able to try such thing (because of the signature) and if you don't trust them then no good using their products.

[peka]

I am too late...
Could somebody share the Firmware 3.0 again for my RTB2004?
Thanks

[Fenstergucker]

The firmware is still there, I have not removed it.

Peter

[peka]

It was my fault, I did not read your post exactly.
Now it works, my RTB2004 has got the new firmware.
Thank you very much!

[Jeroen3]

Just for checks, I can confirm the official R&S download at 2025-04-15:

Code: [Select]

Naam: RTB24_Firmware_v03.00.zip
Grootte: 23624610 bytes : 22 MiB
SHA256: 56de9016b75385af57d7d2e550ac682933edf67af0ff2956f920df96830d3d9c


Code: [Select]

Naam: RTB22_Firmware_v03.00.zip
Grootte: 23444557 bytes : 22 MiB
SHA256: 4989a4f92f61b2e6f5cfc7cfd5653bc0326056d4edadbd962c12377511453dd9


[bayjelly]

Do you have any clue of the probability of someone creating a different R&S signed FW package with the same MD5 hash as the one you downloaded?

MD5 is so well and truly broken, individuals were able to easily create collision *20 years ago*.

Does that make it probable that someone would want to create fake firmware? No. Is it easy to use SHA256 instead of MD5 to guard against the very unlikely chance that some troll is having some fun? Yes.

Only R&S would be able to try such thing (because of the signature)

As a professional who works with bootstrapping including firmware validation, I am well aware how many buggy implementations of validation there are out there (I know you are, too). I don't know about R&S's, and I also think my scope is a very unlikely attack vector, but...

... it's so easy to get a SHA256 hash instead of an MD5 one, so why not just do it? If not anything else, it fosters hygiene and the death of MD5.

[tv84]

... it's so easy to get a SHA256 hash instead of an MD5 one, so why not just do it? If not anything else, it fosters hygiene and the death of MD5.

Sure but, as always, horses for courses.

The MD5 is being used here as a binary integrity checksum, not as an authenticity tool. For that, R&S included the signature inside the FW package.

So, MD5 can/will continue to exist as long as you know what you are doing with it. We're not killing CRCs just because they are dummy-easy to hack...