Coverage feedback is one of the key mechanisms for improving the effectiveness of fuzzers by measuring and comparing the executed code regions while processing input data. In general, such guidance should always improve the performance of fuzzers to better find unexplored code regions. However, proprietary systems with uncommon I/O interfaces (e.g., UAV system, IoT devices, satellite firmware) require extensive engineering/porting efforts to apply coverage feedback support in developing their fuzzing platform. In this paper, we evaluate the detailed efficacy of coverage feedback in fuzzing based on 44 real-world bugs we found using OSS-Fuzz. Our analysis uncovered when and how code coverage information can be helpful, and our experiment demonstrates that although coverage guidance is always helpful to some extent, its effectiveness depends on various external factors. Therefore, such factors should be carefully considered for optimizing the cost and efficiency in designing the fuzzing architecture of proprietary systems.

SQL Injection is a well-known vulnerability that has persisted in web applications for decades. A widely held assumption among developers is that even when SQL Injection is present, hashing or encrypting sensitive data using SQL-provided cryptographic functions, such as sha256() or md5(), renders stolen data unrecoverable. This paper challenges that assumption directly. We demonstrate that invoking cryptographic functions within SQL statements does not protect plaintext credentials against an attacker who already has SQL Injection access, not because the hash functions are weak but because their plaintext arguments are transiently exposed in DBMS in-memory monitoring views before the hash function executes. We exploit this window using a technique that we call SQLSnoop, which repurposes built-in SQL looping constructs to poll the monitoring view at high frequency within a single injected statement. We demonstrate SQLSnoop against four major RDBMS platforms: MySQL, MSSQL, Oracle, and PostgreSQL. Systematic quantitative evaluation is conducted on MySQL, while feasibility on MSSQL, Oracle, and PostgreSQL is confirmed through working Proof-of-Concept implementations against each platform’s respective in-memory monitoring view. Our evaluation on MySQL shows attack success rates consistently above 90%, reaching 100% at 1.2 or more virtual CPU cores, and holding across all four Data Manipulation Language operations. The key practical implication is that SQL-layer hashing is fundamentally insufficient as a defense against SQL Injection, and sensitive data must be hashed at the application layer before the SQL statement is constructed.