ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.

Getting IDM Drivers passwords (App & Remote loader) from remote server

Getting IDM Drivers passwords (App & Remote loader) from remote server

Sometimes, especially in IDM large deployments we can see scenarios where another provider installs the Remote Loader on their servers and obviously we do not have access to it.

As we know, both the Remote Loader and App passwords, lives and are determined on the remote server. If you do not have access to that server, can we know those passwords? Yes!

This is a small how-to to see these passwords:

We need to have some driver settings, see the configuration for what we have in the IDM:

driverpwd 01

The first two fields define the configuration of the Application.
The third field defines the configuration of the Remote loader.
And then the fields to configure the passwords, which in this case, we do not know.

We can observe the user to the application: NOVELL
We can also see that the Remote Loader listens on port: 8095

Now let's review the driver's log and look for the chains of Remote Loader authentication:

driverpwd 02

The interesting thing here is to note that the authentication records into the tag's handshake and handshake version="1.0"

Ok, we have enough information, let's play!

Now, we have clearly identified for each service within the log, now we have to force those forwarded and capture passwords. This is done by capturing TCP traffic.

# tcpdump 'tcp port 8095' -npi any -s 0 -w driverpasswd.pcap
Why? because the port of the Remote Loader

At this point we need to RESTART THE DRIVER, FROM IDM CONSOLE, after restarting, stop the TCP capture:

Now, according to previously seen, we proceed to find our target.

For the App's password, the most logical thing is to find the value of "Authentication ID", in this example: NOVELL

# tcpdump -X -vv  -r driverpasswd.pcap | grep -A3 "NOVELL"

driverpwd 04

Target 1, done!

The sequence is:

user...$USER.. (NOVELL, for this example)

And we can see flat password.

Now, remember that the Remote Loader uses the tag "handshake":

# tcpdump -X -vv  -r driverpasswd.pcap | grep -A3 "handshake"

driverpwd 05

Target 2, done!

The sequence is:


The idea of this how-to is make a backup of the passwords that we don't have to spare us many problems for the future. I hope you find it useful.

Happy Hacking!
Labels (1)


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Now that is clever... I just wanted them to add support to Named Password token to retrieve the driver and remote password. This way is much more clever.
I've never used a remote loader without SSL encryption unless it was running on the engine server itself, so I fear this howto is not all that useful in most prod environments. Anyway, why not just ask the app server team for the password, or look it up in project documentation? And if unavailable, just reset both passwords and start wrinting documentation... 🙂
Decrypt SSL conversation would have taken me only 5 minutes more (with "ssldump", for example).
I agree that it is not a typical scenario is precisely why it was not as easy as asking the other provider and reset the passwords could not as we had no access to the servers (I wrote it in the post).
Top Contributors
Version history
Revision #:
4 of 4
Last update:
‎2020-03-10 18:55
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.