There is no general way yo use a function implementing Blowfish and enforcing its maximum 56-byte key size, to emulate a function implementing a variant of Blowfish that does not enforce that limitation (which in practice means it uses up to 72 bytes of key). For most keys over 56 bytes, the plaintext/ciphertext mapping will be different; combining multiple calls won't help.
The only exceptions are keys which after truncation to 72-byte happen to be periodic with a period at most 56-byte. In that case, one can find the period, truncate the key to the period, and pass the truncated key to the function enforcing the maximum 56-byte key size. That works if the function supports the truncated key size, because Blowfish specifies that the key is used cyclically.
ABCDEFGHIJKLMNOPABCDEFGHIJKLMNOPABCDEFGHIJKLMNOPABCDEFGHIJKLMNOP(64-byte) can be truncated to
Note: If the minimal period of the actual key truncated to 72-byte is not supported (e.g. because the available Blowfish function enforces that the key length is a multiple of 4 bytes), but some multiple less than 56 is supported, then it is possible to use that multiple. Key
ABCDEFGHIJKABCDEFGHIJKABCDEFGHIJKABCDEFGHIJKABCDEFGHIJKABCDEFGHIJKABCDEFxxxx (76-byte with the first 72 of period 11) can be truncated to
But in anything like reverse-engineering or cryptanalysis, I can't understand why there would be the need to "use a standard library to take care of the encryption instead of using a custom implementation". There should be the freedom of using a compiled language like C/C++ or Go, and then Blowfish is available in source form, that's little code, zapping its 56-byte limit is trivial, and such custom implementation can give the best speed by cutting down on interface.