"These are typical mistakes in implementation, and this system has nothing to safeguard against them."
My point is that they did _not_ demonstrate the latter in any way. For the Bluetooth attacks, checking your buffer sizes properly is the safeguard. Looking at the code or analyzing the behaviour of the badge is the only way you can figure out if they've safeguarded against those.
The article states, "The vulnerabilities of Bluetooth technology have also been well documented."
The published vulnerabilities have been in particular implementations rather than inherent to Bluetooth in particular. Many IP stacks 10 years ago had similar buffer overflow vulnerabilities. Buffer overflows are common in an impressive variety of code.
Perhaps I'm just a bit over-sensitive, but I guess I see this as comparable to saying "The vulnerabilities of web server technology have been well documented" when what's really meant is that the vulnerabilities in, say, Microsoft's BackOffice have been documented.
I believe somebody reading their article would get the mistaken impression that the Bluetooth vulnerabilities are somehow inherent, rather than merely common mistakes. I'd prefer a phrasing like, "Many Bluetooth implementations have been shown to have significant vulnerabilities, and the use of potentially long-distance wireless communications makes any vulnerabilities easier to exploit."
The phrasing they chose makes it sound like there are guaranteed to be vulnerabilities. Pointing to implementation flaws and implying that they are protocol flaws sounds like FUD. To be clear, I think that Bluetooth in a badge like this is a ridiculous idea - even if the protocol were perfectly implemented, you could probably create a "proxy badge" and effectively extend the range - the potential intruder walks up with a special badge, his cohort points a bluesniper rifle at a legitimate badge, and the challenge/response sequence is simply proxied across the link.