Mirror-bot/AnyPS5
1
0 Fork 0
mirror of https://github.com/boykopovar/AnyPS5.git synced 2026-11-06 13:30:00 +00:00
Code Issues Projects Releases Activity
Files
b8efa6292ae69dfdebbeffcc869b66ddbb8739fc
AnyPS5/docs/dev/debt/libSceLibreSsl.md
T

30 KiB
Raw Blame History

libSceLibreSsl technical debt

Functional

  • SSL_select_next_proto (libSceLibreSsl) follows LibreSSL 3.4.1 ssl_lib.c, which validates neither list: a zero-length entry is negotiated, no overlap returns supported + 1 with the unchecked length byte supported[0], read even for an empty supported list, and each pair of entries with equal length bytes is compared over that many bytes, past the end of a truncated list. Firmware 13.42 host-PC evidence of libSceLibreSsl.sprx (0xda6d0) reports the same status, pointer and length for 700,000 valid pairs and for the six unvalidated cases. Null outputs, a null supported list and a null peer list with a non-zero length throw, where the module faults; nothing is measured on a console.
  • GENERAL_NAME_free and GENERAL_NAMES_free (libSceLibreSsl) - release all nine GENERAL_NAME choices and STACK_OF(GENERAL_NAME) using the guest allocator, following LibreSSL 2.5.4 v3_genn.c and its ASN.1 free dispatcher. ASN1_STRING and dynamically allocated OID contents are wiped before freeing; NDEF strings and static OIDs retain their borrowed memory. Nested X509_NAME entries and cached data are freed as in 2.5.4. Guest allocator tests check owned/borrowed memory and disposal of nested allocations. PS5 native module behavior and malformed-memory failure cases are not verified; negative owned data lengths throw rather than risk out-of-bounds memory erasure.

Unknown function info

  • libSceLibreSsl pending exports - 231 named callable exports are listed in the PS5 3.20 export table and were cross-checked against the same module in PS5 firmware 13.60. Their signatures and behaviour are unverified; the declarations use the no-parameter unknown-signature convention and throw through NotImplemented_nid_no_patch.

  • MD4, MD5, SHA1, SHA224, SHA256, SHA384 and SHA512 Init/Update/Final and SHA256 (libSceLibreSsl) - signatures and context layouts follow the LibreSSL headers, and buffering and Final follow its sources; nothing is checked on the console. Null contexts, null input with a nonzero length, null digest buffers in the 32-bit Final functions and a buffered byte count that is not below the block size, which LibreSSL does not check, throw. SHA-384 and SHA-512 initialization retains the block buffer, following LibreSSL 2.5.4 sha512.c

  • DES_set_key, DES_ecb_encrypt, DES_set_odd_parity (libSceLibreSsl) - the 128-byte DES_key_schedule holds the 8-byte key followed by zeros instead of LibreSSL's precomputed subkeys, so a title reading its contents sees different bytes; DES_ecb_encrypt derives the subkeys through mbedtls on each call. Not compared with the console. Results follow LibreSSL des_key.c and des.c: DES_set_key skips the parity and weak-key checks and returns 0, as it does while DES_check_key is 0 (that variable is not in the PS5 export inventory), a nonzero enc encrypts, and DES_set_odd_parity sets each byte's low bit for odd parity. Null pointers throw where LibreSSL faults

  • X509_verify_cert_error_string - no console call is verified. The 64-bit argument, low-32-bit lookup, messages and shared numeric fallback follow LibreSSL 2.5.4, the version identified in published firmware 13.40 measurements. Console modifications and other firmware versions remain unverified. Unknown-code results share an overwritten static buffer and are not safe for concurrent use, as in that release; code 1 and codes above 54 use the numeric fallback.

  • CRYPTO_num_locks, CRYPTO_set_locking_callback, CRYPTO_set_add_lock_callback, CRYPTO_THREADID_set_callback, CRYPTO_THREADID_set_numeric (libSceLibreSsl) - the locking, add-lock and thread id callbacks are stored but never called: LibreSSL calls them from CRYPTO_lock, CRYPTO_add_lock and CRYPTO_THREADID_current, which the module does not export, around its own shared state. Nothing is checked on the console. Results follow LibreSSL 2.5.4, the version in the firmware 13.40 measurements: 41 locks, the first non-null thread id callback is kept and later ones return 0, and CRYPTO_THREADID_set_numeric clears the 16-byte {ptr, val} structure; a null structure throws, as LibreSSL writes through it unchecked

  • RAND_add, RAND_bytes, RAND_status, RAND_load_file, RAND_file_name, CRYPTO_malloc, CRYPTO_free, CRYPTO_set_mem_functions (libSceLibreSsl) - follow LibreSSL's rand_lib.c, randfile.c and malloc-wrapper.c, which are the same in 2.6.5 (3.4.3 linked); nothing is checked on the console. RAND_bytes reads host entropy and CRYPTO_malloc and CRYPTO_free use the guest heap. CRYPTO_malloc returns null for a size of zero or less, as LibreSSL 2.5.4 to 3.4 do; later versions take a size_t size and call malloc. A null buffer with a positive length throws

  • AES_set_encrypt_key, AES_set_decrypt_key, AES_encrypt, AES_decrypt, AES_ecb_encrypt, AES_cbc_encrypt, AES_cfb128_encrypt, AES_ctr128_encrypt (libSceLibreSsl) - follow LibreSSL's aes.h and mode code. Nothing is checked on the console. Key setup follows LibreSSL 2.5.4's aes_core.c, the version the X509_verify_cert_error_string entry names: a null pointer returns -1 and a key length other than 128, 192 or 256 bits returns -2 before the key is written, and only the 44, 52 or 60 words the key length needs are written. The AES_KEY schedule uses that file's generic C layout (big-endian words, rounds 10, 12 or 14). The 2.5.4 amd64 build uses aes-x86_64 instead, which copies the key bytes without swapping, so each word is byte-reversed compared with the C layout (OpenSSL 3.0.13's x86-64 code gives the same schedules byte-reversed); the console's build options are unknown, so a schedule the title reads or fills is unverified. CTR leaves the last keystream block in ecount_buf even at a block boundary. Null pointers in the cipher and mode functions, other rounds values and a CFB or CTR position outside 0-15 throw

  • ERR_get_error, ERR_peek_error, ERR_clear_error, ERR_remove_thread_state have no console execution verification. Memory BIO and CMAC failures publish to this queue. The 16-slot calling-thread queue retains 15 codes following LibreSSL err.c and err.h. Firmware 13.42 module comparisons on a PC matched libSceLibreSsl3 queue ordering and overflow for 0-20 publications; whether the two firmware libraries share a queue was not tested. Explicit thread IDs throw because guest thread identity mapping is unverified; null clears the calling thread. File/line metadata is stored by the native producer helper but no guest export exposes it.

  • OCSP_response_status_str, OCSP_cert_status_str and OCSP_crl_reason_str (libSceLibreSsl) - the module's strings are not measured on the console. The tables follow LibreSSL ocsp_prn.c, unchanged from revision 1.8 (2015) to 1.12 (2025), with codes from ocsp.h; the argument is a 64-bit long and every value not in a table returns (UNKNOWN)

  • SSL_get_ex_new_index, SSL_CTX_get_ex_new_index, SSL_get_ex_data_X509_STORE_CTX_idx and CRYPTO_cleanup_all_ex_data (libSceLibreSsl) - unverified on a PS5. The stored argl, argp and callbacks are never called, because no export creates an SSL or SSL_CTX and SSL_get_ex_data/SSL_set_ex_data still throw. Index numbering follows LibreSSL 2.5.4's ex_data.c, ssl_lib.c and ssl_cert.c: per class from 0, the verify-callback index allocated once and kept across CRYPTO_cleanup_all_ex_data, which restarts every class at 0.

  • EVP digest and HMAC functions (libSceLibreSsl) - follow LibreSSL 2.5.4's digest.c and hmac.c. They and the EVP_MD, EVP_MD_CTX and HMAC_CTX layouts behave the same up to 3.4.1, so this holds for 2.5.4 (the firmware 13.40 measurements) and for 2.7 or later (its SSL_get0_param export). Nothing is checked on the console. sign and verify in the EVP_MD tables are null as RSA_sign and RSA_verify still throw, failures add nothing to the error queue, and a failed allocation leaves the context without a digest, where LibreSSL keeps it. An ENGINE, an EVP_PKEY_CTX, a null context, EVP_DigestInit_ex without a type on a context that has a digest, and an update or final without a digest throw

  • SSL_CIPHER_get_bits, SSL_CIPHER_get_name and SSL_CIPHER_get_version - the 88-byte guest cipher layout and these calls are not console-verified. They follow LibreSSL 2.5.4 ssl.h and ssl_ciph.c, matching the version in published firmware 13.40 measurements. Console modifications and other firmware layouts remain unverified. Protocol labels use the full 64-bit cipher ID, not the protocol flags; TLS 1.2 ciphers still report TLSv1/SSLv3, as in that release.

  • sk_num, sk_value, sk_pop, sk_pop_free (libSceLibreSsl) - the 32-byte _STACK layout (num, data, sorted, num_alloc, comp) and the results follow LibreSSL 2.5.4 stack.h and stack.c, the version identified in published firmware 13.40 measurements; nothing is checked on the console. sk_pop_free releases the element array and the stack with the guest free, as the module would through libc. No export of this module creates a stack yet, so only stacks the caller builds reach them. A null element array that LibreSSL would read through, and a null free function with a non-null element, throw where LibreSSL faults

  • RSA_flags, RSA_size (libSceLibreSsl) - nothing is checked on the console. Layouts and results follow LibreSSL 2.5.4 rsa.h, rsa_crpt.c and bn_lib.c, the version in the firmware 13.40 measurements. No export of this module creates a key yet, so only keys the caller builds reach them. RSA_size counts the modulus bytes from its top word, as BN_num_bytes, so a zero top word is not skipped. A null method, a null key or modulus, and a positive word count with null words, which LibreSSL dereferences, throw, as do a negative word count and a bit count that overflows int

  • X509_STORE_CTX_get_error, X509_STORE_CTX_set_error, X509_STORE_CTX_get_error_depth, X509_STORE_CTX_get_current_cert, X509_STORE_CTX_get_chain (libSceLibreSsl) - the 240-byte X509_STORE_CTX layout and the results follow LibreSSL 2.5.4 x509_vfy.h and x509_vfy.c, the version identified in published firmware 13.40 measurements; nothing is checked on the console. No export of this module creates or fills a context yet, so only contexts the caller builds reach them. A null context, which LibreSSL dereferences, throws

  • X509_STORE_CTX_get_ex_data, X509_STORE_CTX_get1_chain (libSceLibreSsl) - unverified on a PS5, and no export of this module sets ex_data or builds a chain yet. A chain whose count is negative or above its allocation, or that holds a null certificate, throws before copying; LibreSSL 2.5.4 overruns or dereferences it. Otherwise both follow its x509_vfy.c: entry idx of the ex_data stack as CRYPTO_get_ex_data reads it, and a chain copied as sk_dup copies it, raising each certificate's references (X509 offset 28) by one.

  • UI_set_result (libSceLibreSsl) - unverified on a PS5, and no export of this module creates a UI or UI_STRING yet. The "You must type in %d to %d characters" text LibreSSL 2.5.4 attaches to the size errors is not kept, because the error queue holds codes only. A null UI or result, or null boolean characters that must be compared, throws; LibreSSL dereferences them. The rest follows its ui_lib.c over the 40-byte UI and 64-byte UI_STRING of ui_locl.h: a result outside the bounds sets UI_FLAG_REDOABLE and queues UI_R_RESULT_TOO_SMALL or UI_R_RESULT_TOO_LARGE.

  • PKCS12_PBE_add, SSL_load_error_strings (libSceLibreSsl) - unverified on a PS5; each returns without an observable effect and queues no error. SSL_load_error_strings builds no string table, because ERR_error_string and ERR_error_string_n throw (ssl_err.c); the tables are needed once a string lookup exists. PKCS12_PBE_add is empty in LibreSSL 2.5.4 (p12_crpt.c).

  • EVP_PKEY_type (libSceLibreSsl) - follows the method table of LibreSSL 2.5.4 ameth_lib.c built without GOST and with no engine (every ENGINE_ export throws): RSA (6) and its alias 19 give 6, the DSA types 66, 67, 70, 113 and 116 give 116, DH (28), EC (408), HMAC (855) and CMAC (894) give themselves, and every other type, the GOST types 811, 815, 946 and 947 included, gives 0. These results match firmware 13.42's module run natively on a PC for every type from -1000 to 5000 and the int extremes; nothing is checked on the console

  • EVP_CIPHER_CTX_init, EVP_CIPHER_CTX_new, EVP_CIPHER_CTX_set_padding (libSceLibreSsl) - nothing is checked on the console. The 168-byte EVP_CIPHER_CTX layout and the results follow LibreSSL 2.5.4 evp.h and evp_enc.c, the version in the firmware 13.40 measurements, which also measured EVP_CIPHER_CTX_init clearing 168 bytes. EVP_CIPHER_CTX_new allocates through the guest calloc as the module would through libc. A null context, which LibreSSL dereferences, throws

Functional

  • Error publication is integrated with memory BIO and CMAC cipher errors. The digest, low-level AES, allocator/RAND, DES, BIGNUM and EVP/HMAC implementations require separate error-publication integration. LibreSslPutError_nid_no_patch(int library, int function, int reason, const char* file, int line) has C linkage and the native host calling convention, accepts upstream numeric fields and publishes to the calling thread's queue. Three-argument source calls default file/line to null/zero. It stores file/line without taking ownership; producers must supply a filename with static lifetime. Guest ERR entry points use APS5_VABI. Unsupported producer exports continue throwing; the local tests publish through this helper.

  • CMAC and AES-CBC descriptors have no PS5 equivalence verification. Signatures, the 88-byte cipher method and 168-byte cipher context follow LibreSSL 3.4.1; the console version remains unknown. AES cipher data uses Mbed TLS storage instead of LibreSSL's private key schedule. Guest-defined cipher methods run through guest-ABI callbacks. Other built-in cipher selectors and the general EVP cipher exports still throw. ENGINE-backed methods throw. Null contexts, null nonempty update buffers, null initialized-final length pointers, negative cipher dimensions and missing required callbacks throw where upstream dereferences unchecked pointers. Error metadata names host source locations.

  • BN_new, BN_free, BN_CTX_new, BN_CTX_free, BN_CTX_start, BN_CTX_end, BN_bin2bn, BN_bn2bin, BN_hex2bn, BN_num_bits, BN_set_word, BN_add_word, BN_sub_word, BN_mul and BN_mod_inverse (libSceLibreSsl) - the BIGNUM layout (24 bytes, 64-bit limbs, top, dmax, neg, flags) and the documented semantics follow the public LibreSSL 2.x API; the module's LibreSSL version is unknown and nothing is checked on the console. BN_CTX is opaque and only counts BN_CTX_start and BN_CTX_end, since BN_CTX_get is not implemented, and BN_mul and BN_mod_inverse ignore it. BN_mod_inverse treats a negative modulus by its magnitude and returns 0 for a modulus of 1, which is not compared with LibreSSL. BN_hex2bn rejects a string without a hex digit, such as -, which older LibreSSL versions accept. Null BIGNUM pointers, which LibreSSL does not check, throw. BN_print still throws because it needs a BIO.

  • Memory BIOs have no console execution verification. Firmware 13.42 module comparisons on a PC cover 1,048 sequences with stand-in allocators, including null/zero writes, callbacks and growth wiping. They support dispatching nonnegative writes to the method even with null source or zero length; LibreSSL 3.4.1 instead guards those calls. Negative public lengths retain that source's early return because the module report did not measure them. The 104-byte BIO, 80-byte method and 24-byte buffer use LP64 layouts. Allocator padding is zeroed rather than retaining the module allocator's fill. Other firmware and console imports remain unverified. CRYPTO ex-data, file, socket and SSL BIOs remain unsupported.

  • Memory BIO unchecked inputs throw for null method or raw line-buffer pointers, negative raw method write sizes, an overflowing raw line-buffer size, inconsistent read-only buffer lengths, and memory write lengths that overflow size_t. Upstream does not validate these inputs. An unrepresentable string length throws instead of narrowing into an unchecked write.

  • ERR string formatting is not console-verified. Firmware 13.42 modules run natively on a PC produced numeric-only strings before and after their loaders. Formatting, truncation and caller/static buffers matched with a standard-C snprintf stand-in; other firmware, console imports and concurrent static-buffer use remain unverified. Loading and freeing do not enable named strings or alter queued errors. Historical tables are generated only as regression-test inputs.

  • ASN1_INTEGER_get has no console verification for nonpositive lengths. It follows LibreSSL 2.5.4: valid integer types return zero without reading data when length is zero or negative; invalid types return -1 first. Later LibreSSL versions reject negative lengths through ASN1_INTEGER_get_int64; that later contract is not used for this library.

  • ASN1_INTEGER_get and ASN1_STRING_data/length/type/to_UTF8 are unverified on PS5. They follow LibreSSL 2.5.4, reported for firmware 13.40 in discussion #8981. These throw where 2.5.4 has undefined behaviour: a null structure passed to ASN1_STRING_data, ASN1_STRING_length or ASN1_STRING_type, a null conversion output, missing nonempty data, oversized converted output and unrepresentable signed integers. As in 2.5.4, ASN1_INTEGER_get(NULL) returns 0 and ASN1_STRING_to_UTF8 returns -1 for a null string, leaving the output alone; malformed input and allocation failure also return -1 and queue the ASN.1 error (129, 133, 134, 124, or 65, twice for a UTF8String copy). Conversion buffers come from the guest libc allocator.

  • SSL_alert_desc_string_long - Console execution and equivalence across other firmware revisions remain unverified. BunnyFl reports identical strings for 3,841 inputs across three runs against the firmware 13.42 module executed natively on a PC (comparison); this is not a console run. The mapping follows LibreSSL 2.5.4.

  • i2t_ASN1_OBJECT and the object table are unverified on PS5. The 956 objects and their search order are generated from LibreSSL 2.5.4 objects.txt and obj_mac.num with its objects.pl and obj_dat.pl, the version string the module holds; LibreSSL 2.7 adds NIDs 956-967, so its jurisdictionLocalityName, jurisdictionStateOrProvinceName and jurisdictionCountryName OIDs print by name there and numerically here. OBJ_obj2txt follows 2.5.4 obj_dat.c, and looks up objects added by OBJ_create before the table, as OBJ_obj2nid does. A negative buffer length, and a null buffer with a positive length, throw instead of being passed on as a size_t

  • OBJ_create and OBJ_cleanup are unverified on PS5. They follow LibreSSL 2.5.4 obj_dat.c and the a2d_ASN1_OBJECT parser of a_object.c, with its error codes and arcs past 64 bits: each object takes the next NID from 956, the latest object with an encoding wins, and OBJ_cleanup drops them all without resetting the NID counter. Added objects live in host memory, so an allocation failure throws instead of queuing ERR_R_MALLOC_FAILURE. OBJ_cleanup is never deferred: check_defer only fires for ciphers or digests with an added NID, which no export registers. Name lookups (OBJ_sn2nid, OBJ_ln2nid) of added objects are not kept, as no export reads them yet. A null OID text throws where LibreSSL faults

  • X509_STORE_new, X509_STORE_free and X509_STORE_set_flags are unverified on PS5. The 136-byte store, 64-byte verify parameters, 56-byte parameter identity, 32-byte stacks and the results follow LibreSSL 2.5.4 x509_lu.c and x509_vpm.c, the version in firmware 13.40 measurements. No export adds a certificate, CRL or policy object, so X509_STORE_free throws instead of freeing one and the object cache's comparator throws. A null store or verify parameters, and a null element array behind a positive count, throw where LibreSSL faults

  • X509_VERIFY_PARAM_set_hostflags and X509_VERIFY_PARAM_set1_ip_asc are unverified on PS5. They follow LibreSSL 2.5.4 x509_vpm.c and the a2i_ipadd parser of its v3_utl.c, unchanged in 2.7, the first release whose symbols include X509_VERIFY_PARAM_set1_host, which the module also exports; IPv4 parts are read with the guest sscanf as the module would. LibreSSL 2.8 appends a poisoned field to the parameter identity, which these layouts lack. A null address text, and null verify parameters or identity once an address is accepted, throw where LibreSSL faults

  • X509_LOOKUP_file and X509_STORE_add_lookup are unverified on PS5. The 80-byte method, the 32-byte lookup, the stack growth and the results follow LibreSSL 2.5.4 by_file.c, x509_lu.c and stack.c, unchanged in 2.7. The file method's ctrl, which loads PEM certificates and CRLs, throws: there is no certificate model. Callbacks of a guest-supplied method (new_item, shutdown, free) throw instead of being called, and a null store, method or listed lookup throws where LibreSSL faults

  • X509_VERIFY_PARAM_set1_host is unverified on PS5. It follows int_x509_param_set_hosts of LibreSSL 2.7, the first release with this export, and copies the name with the guest strndup. LibreSSL 2.8 also marks the parameters as poisoned when the call fails, through a field the 2.5.4 to 2.7 layout lacks, so a failed call leaves no mark. Null verify parameters or identity throw where LibreSSL faults

  • X509_EXTENSION_get_critical, X509_EXTENSION_get_data and X509_EXTENSION_get_object - signatures, null-input results, borrowed pointers and the signed critical > 0 rule follow LibreSSL 2.5.4 x509_v3.c. The 24-byte LP64 extension layout (object at 0, 32-bit critical at 8, data at 16) follows x509.h. Published firmware 13.40 measurements identify libSceLibreSsl as 2.5.4, but these getters and this layout have not been independently checked on a console. The getters do not validate or decode the referenced ASN.1 objects.

Reference in new issue View Git Blame Copy Permalink