Exception in 'get_malicious_ldap_packet' when message_id greater than 255

[hardcoreslacker]

This error can manifest in a few different ways. Sometimes the b'\x02\x01' string is found in the ldap message from the target, but in the wrong place. That will get you a traceback from "dcerpc" because the ldap message we send back lacks the required information to trigger the exploit (or more accurately is parsed wrong):

Traceback (most recent call last):
  File "/home/kali/ldap_nightmare/CVE-2024-49113/LdapNightmare.py", line 75, in <module>
    main()
  File "/home/kali/ldap_nightmare/CVE-2024-49113/LdapNightmare.py", line 60, in main
    DsrGetDcNameEx2(
  File "/home/kali/ldap_nightmare/CVE-2024-49113/rpc_call.py", line 32, in DsrGetDcNameEx2
    resp = dce.request(request)
           ^^^^^^^^^^^^^^^^^^^^
  File "/home/kali/ldap_nightmare/CVE-2024-49113/.venv/lib/python3.11/site-packages/impacket/dcerpc/v5/rpcrt.py", line 882, in request
    raise exception
impacket.dcerpc.v5.nrpc.DCERPCSessionError: NRPC SessionError: code: 0x54b - ERROR_NO_SUCH_DOMAIN - The specified domain either does not exist or could not be contacted.

And sometimes (though I can't figure out how to trigger this specifically) b'\x02\x01' is not found at all. Which looks similar to #1 and might actually be the same issue.

get_malicious_ldap_packet was assuming a single byte message_id_field length when calculating 'lm_referral_length_index'; this is correct for message_ids below 256 (as in a freshly rebooted server). The 4th byte in the message (index 3) is the length of the message_id field, so that value added to the static start (index 4) gets us a consistent message_id_bytes value (slice [4: 4+length]). This effects the number of padding bytes needed, which also changes the calculation of the new message length.

I also moved the 'message_length' calculation closer to the start of the method for clairity.