4 ms·

Compromised toolchain/Underhanded C perhaps explains why whoever did this didn't take even the slightest bit of effort to compare against a hash.

• rdtsc 11y ago
  That was my first guess. Based on how password looked it could have been a multi-line split or some sort of other such trickery. A set of macros perhaps...
  • stordoff 11y ago
    That was my first thought on seeing the password: the string wasn't chosen per se; it was a string they could assemble (or block of memory reused) in a way that appears benign in a code review.
    • buserror 11y ago
      Actually, it's very likely the string was used for some other (valid) purpose and the pointer is being hijacked afterward -- it's VERY unlikely to appear as a singleton string constant anywhere. The password looks like what someone would put at the start of a function to trace stuff; and, there's very likely a macro that does that all over the software. Lets imagine what that might look like: #define TRACE(__f, ...) \ const char *tok="<<< " __f;\ printf(tok, __func__, __VA_ARGS__); u32 check_pass(const char *un, const char *tock) { u32 res = valid(un, tock); TRACE("(un='%s') = %u", __func__, un, tock); res += valid(un, tok); /* could look like a cut/paste blip... */ return res; }
      • rdtsc 11y ago
        Yap, agreed, that makes most sense.