OKX SDK

The okwallet-core component contains the AesEncrypt and AesDecrypt functions which use the encryption key that is hardcoded at `audit/okwallet-core/util/util.go:267`: ```GO var AesHardKey = common.MD5("1697773335922") // AesEncrypt AES 加密数据 func AesEncrypt(message, key string) (string, error) { if len(message) == 0 { return "", fmt.Errorf("message is empty") } if len(key) == 0 { key = AesHardKey } return common.Encrypt(message, key) } ``` No function calls towards these functions have been observed within the provided codebase. If this code snippet is not actively used, there are no security issues. **However, if this code is being used in other parts of the client’s software, this potentially poses a serious security problem.** ***Note:*** The reason this issue is undetermined is that we have only partial code. Although no reference to this hard coded secret was found in the code given to us, we can not conclude that code not shared with us did not use this hard-coded secret As such, the Severity is set as Informational, however it could be higher.

We identified a snippet of code that could allow an integer overflow if a sufficiently large integer is cast as a `uint32`. The snippet of code is found here: `bitcoin/brc20/util.go:15` ```Go func ConvertToUint32(v string) uint32 { i, _ := strconv.Atoi(v) return uint32(i) } ``` ***Note:*** This function is actively used in the codebase but it is not possible to determine if there is a real risk of an integer overflow in the client’s codebase, as we cannot establish the runtime values of the provided parameters. As such, the Severity is set as Informational, however it could be higher.

In the iOS app, we identified a snippet of code that potentially could free previously allocated memory. No concret memory manipulation risks (UAF) were identified in the client’s source code. The memory being free here (ptr) could be already freed in other calls, and ptr is not set to NULL (which is not a must in free).