Technically, it's not possible to decode the input data without the ABI. Your ABI specified what data and data type in encoded in the function parameters. That said, you might have seen etherscan/bscscan with decoded input parameters. Thanks to sources like https://www.4byte.directory/, we have a list of known function signatures and their parameter types. These block explorers likely use something similar to decode known functions. So if the function call you are trying to decode is known in the signature database, you can technically decode it. For example, lets say the input data is
In that, the first 4 bytes are the function signature -
0x2e1a7d4. The remaining are input parameters.
We could then lookup in https://www.4byte.directory/ for the signature (link). It says the function is
Now that we have the function definition, we can easily decode the input. You can do it via libraries like web3 or ethers, or some web tools to do the same. In this case, the input is
0x38d7ea4c680000 which is the hex for
16000000000000000. So the function call was
But like said, this worked only because the function signature of
withdraw(256) was known. If it's a new function signature that is not previously known, it's impossible to decode the input. You can read more about how input is encoded here.