Map Meterpreter command IDs to their names when raising a RequestError

[zeroSteiner]

Back when we release version 6, we changed Meterpreter commands to use numeric IDs instead of string values. Since then, when a RequestError is raised for whatever reason we get the numeric command ID instead of the name which means the user needs to look it up themselves to get some context as to what command failed.

This PR updates the RequestError to map the numeric command ID back to its string representation by looking up the extension module, then enumerating the COMMAND_ID_* constants to find the correct value. The result is nicer error messages that can help the user quickly identify the problem.

Examples

The following two cases show the before and after. In this case, an error is raised while running the post/linux/gather/gnome_keyring_dump module because the target system doesn't have the necessary libgnome-keyring.so.0 library. This causes the stdapi_railgun_api command (ID: 1028) to fail. Notice the number in the first example, and the string in the second.

Before

msf6 post(linux/gather/gnome_keyring_dump) > run

[-] Post failed: Rex::Post::Meterpreter::RequestError 1028: Operation failed: Python exception: OSError
[-] Call stack:
[-]   /home/smcintyre/Repositories/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/railgun/library.rb:373:in `process_function_call'
[-]   /home/smcintyre/Repositories/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/railgun/library.rb:95:in `call_function'
[-]   /home/smcintyre/Repositories/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/railgun/library_wrapper.rb:25:in `method_missing'
[-]   /home/smcintyre/Repositories/metasploit-framework/modules/post/linux/gather/gnome_keyring_dump.rb:195:in `run'
[*] Post module execution completed
msf6 post(linux/gather/gnome_keyring_dump) > 

After

msf6 post(linux/gather/gnome_keyring_dump) > run

[-] Post failed: Rex::Post::Meterpreter::RequestError stdapi_railgun_api: Operation failed: Python exception: OSError
[-] Call stack:
[-]   /home/smcintyre/Repositories/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/railgun/library.rb:373:in `process_function_call'
[-]   /home/smcintyre/Repositories/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/railgun/library.rb:95:in `call_function'
[-]   /home/smcintyre/Repositories/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/railgun/library_wrapper.rb:25:in `method_missing'
[-]   /home/smcintyre/Repositories/metasploit-framework/modules/post/linux/gather/gnome_keyring_dump.rb:195:in `run'
[*] Post module execution completed
msf6 post(linux/gather/gnome_keyring_dump) >

Verification

You'll need to trigger some kind of an exception to see the new details.

• Start msfconsole
• Get a Python Meterpreter session on a system without libgnome-keyring.so.0
• Run the post/linux/gather/gnome_keyring_dump module and see the error message without the command ID

[jmartin-tech]

@msjenkins-r7 test this please.

[dwelch-r7]

Worked perfectly for me, will land this now

[dwelch-r7]

Release Notes

Improved the readability of Meterpreter error messages by replacing the command ID with the command name.

[adfoster-r7]

I also verified that the pull request would improve the error message recent android issues that were raised and fixed by #14589

Before:

meterpreter > download foo.txt
[*] Downloading: foo.txt -> /Users/adfoster/Documents/code/metasploit-framework/foo.txt
[-] 4: Operation failed: 1
meterpreter > 

After:

msf6 exploit(multi/handler) > sessions -i -1
[*] Starting interaction with 2...

meterpreter > download foo.txt
[*] Downloading: foo.txt -> /Users/adfoster/Documents/code/metasploit-framework/foo.txt
[-] core_channel_open: Operation failed: 1
meterpreter >