The Market Ticker
Commentary on The Capital Markets- Category [Technology]
Logging in or registering will improve your experience here
Main Navigation
Full-Text Search & Archives

Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.


The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.

Considering sending spam? Read this first.

2020-02-13 07:00 by Karl Denninger
in Technology , 108 references
[Comments enabled]  

I told you so.

Chinese tech giant Huawei can reportedly access the networks it helped build that are being used by mobile phones around the world. It's been using backdoors intended for law enforcement for over a decade, The Wall Street Journal reported Tuesday, citing US officials. The details were disclosed to the UK and Germany at the end of 2019 after the US had noticed access since 2009 across 4G equipment, according to the report.

Big shock.

Tell me how you evade this for anything that has closed source?

How do you prove that there's no extra key somewhere in the system that allows someone to get in and "tap" anything flowing through said device, especially if you have built in the tapping facility for the use of "lawful" purposes by the government?

Once a facility is there it can be used and, unless assiduously protected, abused.  What's to prevent the abuse?  Only source access and the people skilled enough to analyze it, along with the time to do so.

Let's not forget that Huawei was founded by someone with strong CCP and PLA ties.  Never mind that the CCP and PLA basically control everything in China, since it's a communist nation.  We conveniently forget this when we want our 50 cent/hour labor force, but it's a fact.  Oh by the way, the firm's full of nepotism too; the CEO's daughter is the deputy chair and CFO.

When subsidized by a malevolent government of course you can sell at a cheaper price.  That makes it very attractive, doesn't it?

It also makes it dangerous.

View this entry with comments (opens new window)

2020-01-21 07:00 by Karl Denninger
in Technology , 86 references
[Comments enabled]  

If you have one of these and put it in a drawer somewhere, not using it for a while, you should probably know that it has a lithium battery in it.  This is why you can unplug it from a controller, take it to a unit and include it there.  Incidentally this is a very nice feature that those "fancy pants" controllers lack, and it also obviates most (but not all) of the security implications of including something over the Net that has a security key (which was the rage over Z-Shave, if you remember.)

What is also apparently the case, and is not obvious at all, is that this battery is actually more than just a backup.  That is, when discharged, or if it fails, the stick gets very, very "wonky."  It appears, specifically, that the RF section is using that power -- perhaps what it wants to draw is more than the USB supply can reliably provide on a peak basis.

In any event if it's low on power -- but not out; it is still working when unplugged and will light up, for example -- you may well find that it will not respond to some commands and appears to not send or receive data either!  That is, you can tell it to "add a node", it will acknowledge the command but never then returns the next frame telling your controller that it is ready to proceed.

I've seen reports around the web that these things sometimes get "screwed" and do odd stuff.  I believe this is what's going on.  If the battery is not actually damaged -- that is, it's just discharged -- leaving it connected to USB power overnight is sufficient to restore it to health.

However, if it's actually dead then you're in trouble because that battery isn't exactly user-serviceable.  There may be, in that case, exactly nothing you can do other than replace the stick, which is a huge hassle since you then have to reconfigure your entire Z-Wave network including all security keys for devices that are running in secure mode, because the Network ID will change.

As near as I can determine when this happens the stick itself is not dead.  There are people claiming there are firmware problems in certain releases; I think what they're running into is exactly this, and the older firmware (of course) correlates with an older, more-likely to be worn out battery.

So if you run into this -- and it's been sitting unplugged for a while -- plug it into a USB port and let it sit overnight.

You might get a pleasant surprise.

View this entry with comments (opens new window)

2020-01-20 07:00 by Karl Denninger
in Technology , 211 references
[Comments enabled]  

Peter Schiff has claimed that he has lost all of his Bitcon.

No, he claims he did NOT forget his password -- rather, his wallet has been corrupted in some way and while he has the correct password, it doesn't work and can't be fixed.

This is one of the big problems with encrypted systems -- they're encrypted you idiot!

Take a GELI encrypted disk.  It has a password (and an optional key file.)  But on the front of the disk is also a block of data that is necessary for the password to work.  If that block is damaged -- even by one bit in the wrong place being a "0" where it should be a "1" (or vice-versa) the password is useless.

There's nothing you can do in such an instance.  For this reason you must know what the potential "gotchas" are in this regard and you must take steps to mitigate that risk (e.g. by copying the file elsewhere on some sort of basis so if it gets damaged you can at least get some of the contents (as of some given date) back.

This is, fundamentally, the same reason you make backups.  When I used to run MCS before it was an Internet company we did, among other things, computer and cabling installations.  We would occasionally get calls from someone who was either a client or wanted to be one with a tale of woe about how their disk was unreadable and they had their entire company on that machine.

They either had no backup at all or had never verified that the backups could be restored.

In virtually every such case some and sometimes all of the data involved was just flat gone.

There was nothing I or anyone else could do about it at that point.  I was brutally honest with folks that called with that sort of problem -- I was happy to, on a billed-hour basis, come and try to "save the day" -- but the odds were terrible, frequently 100:1 against that I'd be able to get all the data back, and every hour spent trying was one we were going to get paid for, with a retainer up front.

Why a retainer -- in good funds -- up front?  Because a good part of the time when that happens to a business the firm fails and your invoice is toilet paper.

Yeah, it's that bad.

Oh well.

Did you learn anything from this experience Peter?

If so what was it?

View this entry with comments (opens new window)

2018-12-03 09:43 by Karl Denninger
in Technology , 242 references
[Comments enabled]  

Someone -- or more like a few someones -- have screwed the pooch.

IPv6, which is the "new" generation of Internet protocol, is an undeniable good thing.  Among other things it almost-certainly resolves any issues about address exhaustion, since it's a 128 bit space, with 64 bits being "local" and the other 64 bits (by convention, but not necessity) being "global."

This literally collapses the routing table for the Internet to "one entry per internet provider" in terms of address space, which is an undeniable good thing.

However, this presumes it all works as designed. And it's not.

About a month ago there began an intermittent issue where connections over IPv6, but not IPv4, to the same place would often wind up extremely slow or time out entirely.  My first-blush belief was that I had uncovered a bug somewhere in the routing stack of my gateway or local gear, and I spent quite a bit of time chasing that premise.  I got nowhere.

The issue was persistent with both Windows 10 and Unix clients -- and indeed, also with Android phones.  That's three operating systems of varying vintages and patch levels.  Hmmmm.....

Having more or less eliminated that I thought perhaps my ISP at home was responsible -- Cox.

But then, just today, I ran into the exact same connection lockup on ToS's "Trader TV" streaming video while on XFinity in Michigan.  Different provider, different brand cable modem, different brand and model of WiFi gateway.


Now I'm starting to think there's something else afoot -- maybe some intentional pollution in the ICMP space, along with inadequate (or no!) filtering in the provider space and inter-provider space to control malicious nonsense.

See, IPv6 requires a whole host of ICMP messages that flow between points in the normal course of operation.  Filter them all out at your gateway and bad things happen --- like terrible performance, or worse, no addressing at all.  But one has to wonder whether the ISP folks have appropriately filtered their networks at the edges to prevent malicious injection of these frames from hackers.

If not you could quite-easily "target" exchange points and routers inside an ISP infrastructure and severely constrict the pipes on an intermittent and damn hard to isolate basis.  

Which, incidentally, matches exactly the behavior I've been seeing.

I can't prove this is what's going on because I have no means to see "inside" a provider's network and the frames in question don't appear to be getting all the way to my end on either end.  But the lockups that it produces, specifically on ToS' "Trader TV", are nasty -- you not only lose the video but if you try to close and re-open the stream you lose the entire application streaming data feed too and are forced to go to the OS, kill the process and restart it.

The latter behavior may be a Windows 10 thing, as when I run into this on my Unix machines it tends to produce an aborted connection eventually, and my software retries that and recovers.  Slowly.

In any event on IPv4 it never happens, but then again IPv4 doesn't use ICMP for the sort of control functionality that IPv6 does.  One therefore has to wonder..... is there a little global game going on here and there that amounts to moderately low-level harassment in the ISP infrastructure -- but which has as its root a lack of appropriate edge-level -- and interchange level -- filtering to prevent it?

Years ago ports 138 and 139 were abused mightily to hack into people's Windows machines, since SMB and Netbios run on them and the original protocol -- which, incidentally, even modern Windows machines will answer to unless turned off -- were notoriously insecure.  Microsoft, for its part, dumped a deuce in the upper tank on this in that turning off V1 will also turn off the "network browse" functionality, which they never reimplemented "cleanly" on V2 and V3 (which are both more-secure.)  Thus many home users and more than a few business ones have it on because it's nice to be able to "see" resources like file storage in a "browser" format.

But in turn nearly all consumer ISPs block those ports from end users because if they're open it can be trivially easy to break into user's computers.

One has to wonder -- is something similar in the IPv6 space going on now, but instead of stealing things the outcome is basically harassment and severe degradation of performance?


View this entry with comments (opens new window)

2018-06-06 16:23 by Karl Denninger
in Technology , 110 references
[Comments enabled]  

Nope, nope and nope.

Quick demo of the lock support in the HomeDaemon-MCP app including immediate notification of all changes (and why/how) along with a demonstration of the 100% effective prevention of the so-called Z-Shave hack from working.

Simply put it is entirely under the controller's choice whether it permits high-power keying for S0 nodes.  For those controllers that have no batteries and no detachable RF stick, which is a design choice, there's not a lot of option.

But for those who follow best practice that has been in place since the very first Z-Wave networks you're 100% immune to this attack unless you insist and intentionally shut off the protection -- even in a world where S2 adoption becomes commonplace (which certainly isn't today but will become more-so over time.)

HomeDaemon-MCP is available for the entity that wishes to make a huge dent in the market with a highly-secure, very fast and fully-capable automation, security and monitoring appliance, whether for embedded sale (e.g. in the homebuilding industry) or as a stand-alone offering.  Look to the right and email me for more information.

View this entry with comments (opens new window)