Enabling options for R&S test equipment

[piotrekjan]

Had someone play with this audio generator ? What is necessary to run it next to module B41 ?
Basing on alu cover that shows B41 connections, B41 is connected to A10 X105 (located next to it) and A7 X704. Here next question - to A7 X704, two cables are connected one from B41 and on from A9 X901.
Is some "T" adapter necessary to connect these cables together on A7 X704 ?
What about software firmware - this mentioned previously IS1MV5.20 will work for this audio too?
And the last question - these, let's call them "RF cables", inside equipment - what plugs these are - is it possible to buy to make cable ourselves or it is some R&S standard ?

Regards,

[teknut]

Not sure about the audio question but sure about the RF connectors inside. For whatever reason they are using 3 types
SMA - I guess we all know that one right ? - is the one used for the attenuator
SMB - almost the same size as an SMA yet it does not rotate - plugs in and out
MMCX - the smallest one of all used all around
All standard connectors... nothing special

[piotrekjan]

The MMCX is the plug I was looking for.
Thank you and Regards,

[MindBender]

I have updated the source code of the Rohde & Schwarz FSP option generator in post 7 of this thread and put it on GitHub:
https://github.com/CatGenius/fsxx_keygen
It now contains all 200 seeds from API.DLL and it takes the serial number from the command line options.

If no instrument type is specified, it prints all 200 keys, generated from the serial number and the 200 seeds. If you have found some of these keys to activate any options, please report:

• Your instrument type (eg. FSEA20)
• The key number (a number between 0 and 199, not the actual key
• The number (eg. K10) and a description (eg. GSM MS Analyzer) of the option it enables

Please note I am not the original author of this software. I just extended it a bit.

[cmu2017]

Is there also such a program to enable options for the R&S SFE100?

[hg2dok]

Hello everyone! I want to activate the AMPS option in cmu200. Can anyone help generate decimal code?CMU serial is 834639/052
Best regards HG2DOK ARON

[msraya]

Hello everyone

Lately I help a friend of mine to enable CMU200 functionality and to doing a backup. I use old good python code.
Unhappily, this code is large obsolete because of update library functionality and Python 2 obsolescence.

So I try to upgrade python code. I think I success, so I share my findings with you.
Below is the code. There are two programs, one to extract and check serial number from encoded user key file SWOPT.DAT hidden file.
The second to obtain user keys. Bear in mind that this code is for educational purpose only. Each one has the responsibility for their use. I don't help nor support anyone questions about the code, sorry. My aim is to help people with old and obsolete equipment.

from Crypto.Cipher import ARC2
from Crypto import Random
import struct
import base64

for l in open("SWOPT.DAT"):
   if len(l) == 17:
      tmp=bytes.fromhex(l.strip())
      cipher = ARC2.new(b'Revision\0', ARC2.MODE_ECB)
      tmp2 = cipher.decrypt(tmp)
      a, b = struct.unpack("<II", tmp2)
      print ("SN: %d - %d" % (a, b/1000000))


from Crypto.Cipher import ARC2
from Crypto import Random
import struct

serial = 101763
serial2 = 2
options = [21,22,23,24,42,43,45,44,14,29,47,48,53,54]

for option in options:
   record = struct.pack("<II", serial, serial2 + (option <<20))
   encyphered = ARC2.new(b'Revision\0', ARC2.MODE_ECB ).encrypt(record)
   print("Option K%2d, key = %s."% (option,encyphered.hex()))

Regards

[syau]

I have updated the source code of the Rohde & Schwarz FSP option generator in post 7 of this thread and put it on GitHub:
https://github.com/CatGenius/fsxx_keygen
It now contains all 200 seeds from API.DLL and it takes the serial number from the command line options.

If no instrument type is specified, it prints all 200 keys, generated from the serial number and the 200 seeds. If you have found some of these keys to activate any options, please report:

• Your instrument type (eg. FSEA20)
• The key number (a number between 0 and 199, not the actual key
• The number (eg. K10) and a description (eg. GSM MS Analyzer) of the option it enables

Please note I am not the original author of this software. I just extended it a bit.

Tested on FSH6

/* FSH option list */
static const struct option_t  fsh_options[] = {
        {  0, FLAGS__INVALID, "NONE" },
        {  1, FLAGS__INVALID, "NONE" },
        {  2, FLAGS__VALID, "B1 - Distance To Fault" },
        {  3, FLAGS__VALID, "K2 - Vector Calibration" },
        {  4, FLAGS__VALID, "K1 - Remote Control" },
        {  5, FLAGS__VALID, "K3 - Receiver Mode" },
};

BTW, anybody has a FSHRemote for FSH3/6 usable in Win10x64 ? Tried fshremote_2.12.4, it throw as class error 

[Venture]

Hello all,

I wonder if someone could do me a huge favour. I have an  FSU and would love to enable some s/w options (mainly K9 power meter, but others would be nice too).
The problem is that I'm no good with computers and just have a WinXP (don't asK) and a Win10 machine here. I have no clue how to get Python working on either machine to run the keygen.

I'd very much appreciate it if someone could generate some option keys for me. My instrument serial no. is 200372/003.

Failing that, I've had a look here:

https://repl.it/repls/SkeletalDelectableDwarfrabbit

But have no clue how to input serial number or run the code (copy & paste code from the left to window on the right brings up several error messages, plus there doesn't seem to be an option 9 listed there) so maybe someone could write a short "dummies guide".

Thank you!

[ve7xen]

Hello all,

I wonder if someone could do me a huge favour. I have an  FSU and would love to enable some s/w options (mainly K9 power meter, but others would be nice too).
The problem is that I'm no good with computers and just have a WinXP (don't asK) and a Win10 machine here. I have no clue how to get Python working on either machine to run the keygen.

I'd very much appreciate it if someone could generate some option keys for me. My instrument serial no. is 200372/003.

Failing that, I've had a look here:

https://repl.it/repls/SkeletalDelectableDwarfrabbit

But have no clue how to input serial number or run the code (copy & paste code from the left to window on the right brings up several error messages, plus there doesn't seem to be an option 9 listed there) so maybe someone could write a short "dummies guide".

Thank you!

There should be a Run button at the top of the page, and you will eventually get prompted for the S/N in the right hand panel.

However repl.it seems to have broken anonymous snippets and forced signins  . I've recreated the repl and fixed the package management so it should run now. I got the list of valid licenses from somewhere but I don't remember where - probably for CMU200 though. I've added option 9 to the list for you.

Go to https://repl.it/@ktims/SkeletalDelectableDwarfrabbit#main.py and click Run at the top. It will take some time but eventually prompt you for the S/N in the right pane.

[Bicurico]

Hello,

Just for the sake of it, I tried to convert the Python code (few messages above) into VB .net.

I failed miserably and I don't understand what I am doing wrong.

My code produces diffferent (wrong) keys. I am 100% sure that my Byte arrays for the Key and Message are correct - I checked them against the Python script.

It is the .net Cryptography library that seems to produce a different RC2 result than Crypto.Cipher ARC2 does on Python. But that cannot be true, I would say!

So please help me!

Here is my code (it is not pretty, but at this moment I just want it to produce the same keys as the Python script):

Code: [Select]

Imports System.Security.Cryptography
Imports System.Text
Imports System.IO
Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim key() As Byte = str2byte("Revision ")
        key(8) = 0
        Dim opt() As Integer = {9, 14, 16, 17, 20, 21, 22, 23, 24, 26, 27, 28, 29, 42, 43, 44, 45, 46, 47, 48,
                    53, 54, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 83, 84, 85, 86,
                    87, 88, 90, 92, 96, 839, 849, 859, 869}
        Dim serial1() As Byte = BitConverter.GetBytes(123456) ' <--- Serial Number (first part)
        Dim serial2() As Byte = BitConverter.GetBytes(2)      ' <--- Serial Number (second part)
        Dim message(7) As Byte
        message(0) = serial1(0)
        message(1) = serial1(1)
        message(2) = serial1(2)
        message(3) = serial1(3)
        message(4) = serial2(0)
        message(5) = serial2(1)
        ListBox1.Items.Clear()
        For Each o In opt
            Dim ob() As Byte = BitConverter.GetBytes(o << 20)
            message(6) = ob(2)
            message(7) = ob(3)
            Dim mStream As New MemoryStream
            Dim RC2alg As RC2 = RC2.Create
            RC2alg.Mode = CipherMode.ECB
            RC2alg.Padding = PaddingMode.None
            Dim cStream As New CryptoStream(mStream, RC2alg.CreateEncryptor(key, RC2alg.IV), CryptoStreamMode.Write)
            cStream.Write(message, 0, message.Length)
            cStream.FlushFinalBlock()
            Dim ret As Byte() = mStream.ToArray()
            cStream.Close()
            mStream.Close()
            ListBox1.Items.Add(Str(o) + " - " + byte2str(ret))
        Next
    End Sub
    Function str2byte(str As String) As Byte()
        Dim b(Len(str) - 1) As Byte
        For n = 1 To Len(str)
            b(n - 1) = Asc(Mid(str, n, 1))
        Next
        Return b
    End Function
    Function byte2str(b() As Byte) As String
        Dim t As String = ""
        byte2str = ""
        For n = 0 To b.Count - 1
            t = Hex(b(n))
            If Len(t) = 1 Then t = "0" + t
            byte2str = byte2str + t
        Next
    End Function
End Class

To run it, just create a Form, Button1 and Listbox1.

Regards,
Vitor

[ve7xen]

My word VB is a hideous language. Could it be doing something weird because you are providing an IV to a chaining mode that doesn't use an IV? I also note that the examples seem to call RC2.Create like RC2.Create("RC2"), though I am not sure why or what this parameter is for as its purpose seems basically undocumented.

Or perhaps something is going wrong with `Dim serial2() As Byte = BitConverter.GetBytes(2)` as you have specified a literal that fits within uint8_t when calling GetBytes, does it actually cast the literal to uint8_t and you actually get 2+ bytes out of it? I guess since it is little-endian it doesn't matter if it casts to uint32_t or whatever as long as it's not casing to uint8_t. I guess you aren't lying when you say the byte stream is correct.

Notwithstanding that I can't run this code and that this is much uglier than the Python solution, it seems to be generally correct, as far as I can tell.

[Bicurico]

Thank you for your reply. My aim is not to discuss the pros and cons of different programming languages. The sheer fact that they exist means there are reasons for them to exist.

One of the  motivations for me to convert this script from Python to VB.net is simply to understand what the script does. Since the initial code first published by tmbinc (who has my greatest respect), I have wondered how such a small script would get its job done:

Code: [Select]

from Crypto.Cipher import ARC2
import struct

for l in open("SWOPT.DAT"):
   if len(l) == 17:
      a, b = struct.unpack("<II", ARC2.new("Revision\0").decrypt(l.strip().decode("hex")))
      print "SN: %d - %08x" % (a, b)

Of course, the code of the keygen is even more motivating and similarly compact (no need to repost it here).

And this is what I think of Python: a very cryptic language with loads of shortcuts/abbreviations, which makes the code almost impossible to read, especially when you are not familiar with Python.

It took me quite a while to just understand the meaning of "<II"!

Anyway:

1) Yes, my MESSAGE and KEY arrays are 100% the same as used in the Python script. I verified it. Also, no coding issues, as we are speaking of raw bytes. No error with little endian vs big endian, either.
2) I am using, as in the Python script, ECB. This means that IV is NOT being used at all. And again I verified it: I can define whatever 8 bytes in IV() and pass it to RC2 and the result is the same. IV is simply ignored.
3) Padding is set to NONE and this gives me the result of 8 bytes. Before it was adding random bytes to fill up 128 bit.
4) I already tried to setup keylength to 64 bit. That did not change anything.

So at this point I wonder why .Net RC2 gives a different output than Crypto.Cipher ARC2 in Python. I think that RC2 is somehow working in 128 bit mode and ARC2 in 64 bit mode, but I am not sure.

Again, thw whole point is just a personal satisfaction to see "my" VB code producing the same output as the Python script.

And yes, by now I understand what the script does.

Allthough, there is one part I don't understand. My code now produces the same result, but I find it odd:

Code: [Select]

record = struct.pack("<II", serial, serial2 + (option <<20))
So struct.pack will output two little endian integers ("<II") from two inputs: serial and "serial2 + (option << 20)"
(option << 20) left shifts the velue in options 20 times
But now serial 2 is added to this result. My question is: since both are integers, shouldn't they be added like numbers (2 + 20 = 22) instead of (2 + 20 = 0220)?
Is this addition treated as if adding two strings? Why?
Anyway, this is NOT the problem I am experiencing.

Thanks,
Vitor

[tv84]

Just for the sake of it, I tried to convert the Python code (few messages above) into VB .net.

I didn't use .Net C# RC2 implementation.

I did my own implementation based on this.

Don't remember if I tried .Net version...

My question is: since both are integers, shouldn't they be added like numbers (2 + 20 = 22) instead of (2 + 20 = 0220)?

That <<20 is the same as multiplying option by 0x100000. SO, definitely, it's not the same as adding those 2 numbers!

It's option * 0x100000 + serial2.

[Bicurico]

That <<20 is the same as multiplying option by 0x100000. SO, definitely, it's not the same as adding those 2 numbers!

It's option * 0x100000 + serial2.

Ahhh! Now it makes sense. I was wondering why one would want to shift 8 bits more than 7 times... now I understand. I knew that one left shift is the same as multipying by two, as a right shift is a division by two (6502/6510 assembly does n ot have multiplication or division, so that's how I did it back then).

So much to learn...

Thanks tv84!

EDIT:

I want to add the following:
1) I feel dumb and dumber the more I look into how some of the published key generators work, how smoothly they were programmed and, most important, how these algorithms were discovered in first place. It sure is easy to state "yeah, just decompile the code", but I have actually tried it and got next to zero result!
2) Big thumbs up for the extremely smart people that visit EEVBlog. I really prefer to hang out with smarter people and get slightly smarter myself, than the other way around. Hope that is not a turn-off for the smart guys!

Regards,
Vitor

[ve7xen]

The usage of 'struct.pack' here isn't a very 'Pythonic' way to do things, but maps well onto C structures (hence the name of the module) which is presumably how the original C code packs these values for encryption, and it handles the endianness of whatever platform you're running it on for you, so it's a convenient approach rather than trying to pack and handle byte ordering manually. The idea of pack/unpack comes from Perl, which is indeed a very cryptic language  .

The intent of

Code: [Select]

s2 + (opt << 20) is more 'clearly' (IMO) represented as

Code: [Select]

(s2 & 0x000fffff) | (opt << 20). `s2` fills the lower 20-bits of the value, and `opt` fills bits 31-20 (in integer representation anyway, once you pack this the byte order will be reversed). In any language it would be more idiomatic (again, IMO) to use bitwise OR (|) instead of arithmetic addition (+) to accomplish this, but since the bits don't overlap, the result of either operation is the same (+ is XOR with carry, and XOR and OR are the same if you never hit the 1 ^ 1 case).

If you assume that `serial2` always fits in 16-bits (which it should, being a 3-digit number) and doesn't require the 20-bits it has been allocated in the data structure, they could have represented this instead as two separate 16-bit values in the struct, but you'd have to beware of byte order: e.g. struct.pack("<HHI", s1, s2, opt << 4) which is ultimately closer to what you are doing in your VB code.

Now I'm curious what the original (R&S) developers intended to do with those 4-bits they left unused...

[Bicurico]

Thanks!

"Now I'm curious what the original (R&S) developers intended to do with those 4-bits they left unused..."

Kind of thought about this, too.

Also, why on earth did they choose "Revision\0" as the key?

[ve7xen]

I implemented a simple test harness in C# to look at the .NET RC2 implementation.

After lots of digging, I think I have figured out the problem here. It appears that pycryptodome's RC2 implementation implicitly sets effective_keylen to 1024, unless the user specifies a different value, while .NET sets EffectiveKeySize to the size of the provided key. I'm not sure what the historical/idiomatic default for this parameter is in other implementations, but I guess whatever the R&S folks used did this too or the output wouldn't work. This is what's causing the different output - both implementations behave identically with the RC2 test vectors that specify EKS. The problem here is that the .NET RC2 provider doesn't support the actual key length and EffectiveKeysize not being the same, it throws:

Code: [Select]

System.Security.Cryptography.CryptographicUnexpectedOperationException: EffectiveKeySize must be the same as KeySize in this implementation.
I was thinking maybe you could work around this doing the RC2 key expansion yourself to generate the expanded key that Python is using here, and passing that in, but it appears that .NET RC2 doesn't support keys longer than 128bit for some reason, which is weird, since the RFC explicitly calls out that it accepts a variable length key of 1-128 bytes. So it appears that .NET RC2 implementation is not complete, as it doesn't support EffectiveKeyLength properly, nor 1024b keys. The only way around it seems to be to use your own RC2 implementation or one from a third-party library.

I don't understand why they would bother including such an incomplete implementation. The limitation doesn't even really make sense, they still need to implement the full 128-byte key expansion even if the expanded size and actual size are the same, since this is what is used in the enciphering process. Makes no sense.

[Bicurico]

@ve7xen

Thank you for your analysis.
I spent 3 days trying to get the correct output and I was getting a mental  breakdown for not understanding what was wrong.
At least now I know why.

Kind regards,
Vitor

[tv84]

I don't understand why they would bother including such an incomplete implementation. The limitation doesn't even really make sense, they still need to implement the full 128-byte key expansion even if the expanded size and actual size are the same, since this is what is used in the enciphering process. Makes no sense.

Your conclusions are correct and I remember now that was the reason why I did my own implementation.

http://msdn.microsoft.com/en-us/library/system.security.cryptography.rc2.keysize.aspx

I think someone in the .NET development read 128 as the key's max number of BITS instead of key's max number of BYTES.

[Venture]

Thank you very much to Ve7Xen and TV84, my problem is now sorted.

Merry Christmas All!

[scopeman]

Patty,

IIRC the IR Interface tool is the same one that was used to communicate with some Fluke scopemeters.
See:
https://www.ebay.com/itm/Fluke-IR189USB-USB-Cable-Adapter-for-Models-189-287-and-289/202640369405?hash=item2f2e4ea6fd:g:XFoAAOSwO7pceFR5

Sam
W3OHM
Scopeman

[Pattymorr]

Dear Sam,

Thanks for  the Fluke IR189USB USB Cable Adapter for Models 189, 287 and 289. Nice catch for the ones looking for this on the fly and budget. Others with time and resources can go for the price of  DIY with  3 transistors, two IR LED and a USB to Serial adapter if needed.

Patty.

[tv84]

Just a reminder for those old FSH owners, to create the licenses (10-digits) using the FSP keygen in this thread, you must consider only the serial number and not the model number!

So, in the FSP license generator you should always insert like this (example): 123456/000.

[thorswait]

Hi Fisafisa,

I've had the same problem with the AMIQ, I tried some of the keygen software then I went back to what I know best. So I took my soldering Iron and play with the EEPROM on the DAC board X24C16 next to the Altera and I've compare when activating the B19 option on it the only change was a bit in the EEPROM, nothing else no checksum... So I reverse engineer the process and found out that the bit for AMIQB19 is placed on address 0X13 then I was able to revert all the bits and the options I was interested in .

AMIQB1 Addr 0x11 ; AMIQK11 Addr 0x15 ; AMIQK12 Addr 0x16 ; AMIQK13 Addr 0x17 ; AMIQK14 Addr 0x18 etc ... I went up to AMIQK21 (whick I'm not sure if it's actually an option considering K20 is the last option available in WinIqSim)

After modifying the EEPROM and rebooting the system upon a good boot I then use the GPIB command with the command to retrieve the actual key for example for AMIQB1 that would be : SYST:OPT? AMIQB1  then the unit would reply it's key. I had to redo it several time in order to get it working. If you add all the option at once they would be activate and you'll be able to retrieve all the number but if you forgot one and you want to add it after you will need to resend the key to your unit I thing there is some sort of compare with the EEPROM.bin file on the drive that is use for backup.

I hope it would help you or anyone else using an AMIQ to "retrieve their option key"

Regards