Hacker News new | past | comments | ask | show | jobs | submit login

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



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...


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.


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; 
  }


Yap, agreed, that makes most sense.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: