For everyone else: There's no need for a signed message or transaction ID since it's a made up scenario of scammer who doesn't know how Bitcoin address works.

He wanted to pass that he "accidentally" typed the wrong last character thinking that it wont invalidate the address.
The alleged address that received the 4.37BTC doesn't have the correct checksum, thus any well-written wallet wont be able to send to it.
You can try it in any wallet that you use.

Some technical explanations:

• Address 1L1UduuGPZ8ttGe59F2w9tTEumQFhtxiuT, base58 decoded, separated the last 4Bytes checksum: 00d08175a8f7d52324279706dae9d132e17a1bfce8  8c7b316e
• The first 4-Bytes of the SHA256x2 hash of the above's left part should be equal to the right part (checksum): 8c7b316e.
• So let's get: SHA256[SHA256(00d08175a8f7d52324279706dae9d132e17a1bfce8)]: 8c7b316c28e25f67a1b027243d1b9558c15a7efb10e8e283c2ce9e12f89f794a
• The first 4-Bytes of the above are: 8c7b316c which isn't equal to 8c7b316e.
• With that, the address is invalid.

On a slim chance that the exchange/wallet is miswritten to accept such address:
Since it's only the checksum part that's wrong, the output should still be sent to the address with the correct checksum, thus, to his own address ending with "R".
That's because Bitcoin P2PKH outputs aren't actually addresses but "scriptPubkey" or "locking script" which is in the first part of the decoded data above.

It's a different scenario if he edited one character that's not part of the checksum instead since it would be sent to another address. (only if a buggy wallet allows it)
There's a 1 out of 32bit chance (4-Bytes) that it will be valid to any wallets, that's 1 out of 4,294,967,296 (2^32).