Quickly dumping this here so it is documented, maybe I can do a PR for this at some point.
First though, thanks for this tool, has been quite useful a few times already!
I am running into the issue that functions like e.g. SQLite's sqliteAuthBadReturnCode:
static void sqliteAuthBadReturnCode(Parse *pParse){
sqlite3ErrorMsg(pParse, "authorizer malfunction");
pParse->rc = SQLITE_ERROR;
}might get inlined which confuses the matching algorithm. It reports a 1.0 confidence match with
the calling function sqlite3AuthCheck due to similar rare constant "authorizer malfunction"
int sqlite3AuthCheck(...)
[some code snipped]
if( rc==SQLITE_DENY ){
sqlite3ErrorMsg(pParse, "not authorized");
pParse->rc = SQLITE_AUTH;
}else if( rc!=SQLITE_OK && rc!=SQLITE_IGNORE ){
rc = SQLITE_DENY;
sqliteAuthBadReturnCode(pParse);
}
return rc;
}In this case the correct match is pretty obvious because the compiled function also references the string "not authorized" and is significantly longer. If you need a test case to reproduce this I might be able to create one, I can't share this specific binary publicly.
My suggestion would be:
Some heuristic that compares the function length to reduce the confidence of a really short source function being matched to a longer one simply due to one string match. Maybe some warning that this might be inlining (which is still valuable information and could be used for the heuristics that match based on callers/callees later too).
Quickly dumping this here so it is documented, maybe I can do a PR for this at some point.
First though, thanks for this tool, has been quite useful a few times already!
I am running into the issue that functions like e.g. SQLite's
sqliteAuthBadReturnCode:might get inlined which confuses the matching algorithm. It reports a 1.0 confidence match with
the calling function
sqlite3AuthCheckdue to similar rare constant "authorizer malfunction"In this case the correct match is pretty obvious because the compiled function also references the string "not authorized" and is significantly longer. If you need a test case to reproduce this I might be able to create one, I can't share this specific binary publicly.
My suggestion would be:
Some heuristic that compares the function length to reduce the confidence of a really short source function being matched to a longer one simply due to one string match. Maybe some warning that this might be inlining (which is still valuable information and could be used for the heuristics that match based on callers/callees later too).