Radia NvdmAPI
The 'Authenticated Connections'-HowTo

Version 1.07, 09-April-2004

 Java

 

How to identify the encrypted password for opening an authenticated connection to a Radia manager
 
 

Novadigm uses a symmetric DES-based encryption to secure the user's password during network transfer. To open an authenticated connection, the API thus has to send the password in encrypted form.

As with symmetric encryption the encryption key is the same as the decryption key, this key must be kept secret. Consequently, there are only two approaches to implementing authenticated access in NvdmAPI: to either 'crack the code' (by brute force or analysis of original Novadigm code) or to do without the encryption. For a couple of reasons, the latter appeared to be more appealing... This means, to open an authenticated connection with NvdmAPI, you as a programmer have to provide the password in the encrypted form, and the API will just pass on this byte stream to the Radia manager.

Now, how do you know the encrypted password? Well, it's fairly easy to spy out -- you just have to monitor how the standard Radia System Explorer connects to the manager! Here is how:

  1. stop your Radia manager
  2. open your Radia manager's configuration file (edmprof.dat on Windows, edmprof on Unix) and turn on the logging of COMM events (i.e., in section MGR_TRACE, set COMM = YES)
  3. save the configuration file and start your Radia manager
  4. take a Radia System Explorer pointing to your manager, and log on using your user-id and password -- just as you would normally do
  5. now make a copy of your Radia manager's log file -- it contains all the information we need (we'll examine it later)
  6. you should now set back the trace level of the manager to normal, i.e., close the Radia System Explorer, stop the manager, edit the manager's configuration file to adjust the trace level to your usual settings, save the configuration file, and restart your manager

Now let's have a look at the manager's log file (the copy you created in step 5)...

You will see that the manager traced all incoming and outgoing network packets. The first packet is an incoming EMDLOCTP packet from the Radia System Explorer, which requests to establish a connection. The manager answers this with a fairly similar outbound EDMLOCTP packet. The third packet in the log file is an incoming ZADMIN packet from the Radia System Explorer. Now this is the one we need -- it should look similar to this one in the screenshot:


(click to enlarge)

This packet contains all the required logon information. First, identify the string ZADMIN at the end of the packet (marked in blue in the screenshot). The one ASCII character left of this string tells the length of the (plaintext) password -- in my example it's 8 charcters. The 8 bytes left to this information are the encrypted password (marked in red) -- in my example, these are: F2 F4 5A EE E7 D8 0E F6, starting at offset 0x0124 in the packet. The offset where the encrypted password starts will most likely be always 0x0124, but it's generally more fail-save to first look for the (blue) ZADMIN string, and then to go 8+1 bytes to the left.

So here it is: the encrypted password! To create the connection with NvdmAPI, you would then write:

rcs = new NvdmConnection("192.168.10.10", 3464, "RAD_MAST",
new int[] {0xf2, 0xf4, 0x5a, 0xee, 0xe7, 0xd8, 0x0e, 0xf6}, 8);
(IP address of 192.168.10.10 just being an example)

 

Important Note:
The encrypted password will always be a multiple of 8 bytes; in fact, it will be the smallest multiple of 8 which is >= the length of the plaintext password (in my example, both the plaintext password and the encrypted password accidentally happen to be 8 bytes). So if the length of the plain text password happens to be 12, e.g., you'll have to look for 16 bytes, starting at 16+2 bytes left to the ZADMIN string ("+2" because the length of the password will now take up 2 characters!).

Another Note:
The described approach to find the offset of the encrypted password within the packet assumes the sequence of object attributes in the packet to always be the same -- which most probably is the case, but cannot really be guaranteed. The most secure way to identify the correct offset is to calculate it based on the attribute data in the packet (that's also the way NvdmAPI is doing it internally). However, this is a little bit more complicated to explain and would require you to understand a lot of details about the internal object structure of Novadigm's protocol. For the sake of simplicity, just try it as explained above -- if this doesn't work, don't hesitate to contact me.

 

Copyright © 2002 Dr. Lothar Baum, All Rights Reserved.

Please send comments, bug reports, and enhancement requests to: lbaum@web.de