
Tractor Hacking: Documentary About Farmers Fighting for the Right to Repair - goodmachine
https://motherboard.vice.com/en_us/article/pamkqn/watch-tractor-hacking-john-deere-right-to-repair-documentary
======
SteveGerencser
I own a small farm and work in tech. We are struggling with this issue right
now as we look at the options for a new tractor vs an older serviceable model.
While many of the larger corporate farms are content to buy new equipment
every 10 years, those of us at the small end of the scale have begun a push to
keep older equipment up and running.

My tractor is from 1996, my hay baler from the early 70s and my hay cutter is
even older. These all work just fine even if a little slow. The challenge of
not being able to work on my equipment currently outweighs the marginal speed
gains I would see on a farm our size. The same goes for nearly all of my
neighbors.

The last "new" tractor in the local area was bought a couple years ago by one
of the older guys who was buying the last tractor he will ever own and he
thought it would be nice to have a top of the line, new, tractor just once.

~~~
anubisresources
What do you grow? Hay mainly? Acreage?

~~~
SteveGerencser
We grow hay to feed our beef cattle on about 100 acres +/\- a bit. But all
around us are plenty of farms growing small farm (under 500 acres) or row
crops/beans etc.

We were having this very discussion today when picking up some hay to help us
get through till spring with a guy that cuts about 500 acres of hay 3 times a
year. He just keeps rebuilding his equipment rather than get sucked into the
new stuff he can't work on.

This is becoming another huge issue that affects smaller farms more than it
affects larger corporate type farms. When a piece of equipment goes down it's
needed back in service in hours to days, not the potential weeks that hauling
it to a repair depot can cause.

~~~
anubisresources
You weren't kidding about the small farm! The dealers in your area can't do
field repairs?

------
pdelbarba
I work in the embedded field and this drives me nuts. I personally feel that
companies should be required to go one step further and be compelled to
release their embedded keys and source code for any product that they no
longer provide complete support for.

The embedded field is strange because the lock-in is generally on the side of
the hardware design and tooling. Nobody is going to try to clone a tractor
because they have the source code for it. They also need the CAD drawings,
machine paths, tooling, supply chain, etc... Yet just about every company in
the space feels that their code is absolutely sacred above all else. Just
about everything you own running embedded software that has some update
functionality has a bootloader containing cryptographic keys such that the
firmware patches/images cannot even be disassembled. For a few devices like
routers, some toys, a couple handheld radios and the like, people have been
able to modify them through exploits that cause firmware dumps from the uC's
memory but otherwise it's typically prohibitively time intensive to rewrite
new firmware from scratch without having access to the device schematics (and
even then). Worse, just about all these devices have some access to JTAG ports
such that you could easily program them yourself if you wanted to and had
something useful to flash them with. I've run into so many products I use on a
regular basis with bugs or simple but badly needed features that I could have
easily fixed/hacked in with access to the source code but alas, I cannot.

~~~
rhizome
_I personally feel that companies should be required to go one step further
and be compelled to release their embedded keys and source code for any
product that they no longer provide complete support for._

Sounds great, but it's something the abandonware[1] scene has been fighting
for over the past 20 years, to no avail.

1\.
[https://en.wikipedia.org/wiki/Abandonware](https://en.wikipedia.org/wiki/Abandonware)

~~~
Slansitartop
It's a good idea, so people should keep fighting for it, even if it takes more
than 20 years.

------
LeonM
As a software engineer with an embedded systems background this kind of OEM
behavior driver me up the wall.

I've had OEM's:

\- refusing to provide interface specs of a device of which we just ordered
hundreds of units. (But hey, here is the binary windows (!) driver for this
embedded device)

\- refusing to provide the calculation method of a checksum value their device
returned.

\- Stopping software development (tooling, firmware, drivers) on embedded
products, even when there are known issues.

\- Dropping support on a device, even when hundreds of them are still being
used in the field.

It's not just tractors, its everywhere.

From a business standpoint, it's just so dangerous to work with hardware
vendors who don't offer implementation details or source code. If they drop
support or stop existing, you're screwed...

~~~
nas
As a former farmer (roughly 4000 acres of dryland farming in Canada) and an
engineer who also did embedded control system development, I would like to add
some of my concerns.

For new ag machinery, embedded control systems are absolutely essential for
the machine to do its job. The ECU on the engine is generally reliable and
have long life. The other stuff, I'm highly dubious of the long-term
maintainability of it. On our farm, we ran a lot of older equipment and did a
lot of repairs ourselves. For new equipment, that will be near impossible as
the electronic control systems are black boxes. Even the cabling is
complicated and is generally not documented. After the machine gets a decade
or two old, good luck fixing it.

I suppose you could just drive the machine in the junk pile. However, when a
new combine harvester is costing around 3/4 of a million USD, that seems a bit
wasteful. I don't know what the solution is though. The farmers buying new
equipment don't care so much, their resale value is not suffering too badly.
The manufacturers are looking for ways to sell new equipment and adding more
features via electronic controls is a relatively cheap way to enhance the
product.

Most farmers say they don't want all these new electronics on their machines.
When Deere announced their S700 series combines, they had a video bragging
about all the new improvements:

[https://youtu.be/l5xJOoNyLoU](https://youtu.be/l5xJOoNyLoU)

If you study it, you will notice that most of the new features are due to
software changes or to electronic control systems. Little of what the machine
actually does to harvest the grain has changed (metal parts, etc). This
automation features are nice when they work but are a disaster when something
goes wrong. The operator will have trouble to determine what the machine is
doing (never mind trying to figure out how to fix it).

However, even though many farmers say they don't want it, the new machines are
selling well. So, maybe you could argue the market is working. To me, it feels
like there could be some externalization of costs going on. These new machines
are very much less valuable as they get older vs the previous era of farm
equipment. I guess the same thing has happened to automobiles. You can take a
car from the 1940s and fix it up into perfect condition. If you take a 2017
car loaded with electronics, would you have any hope of fixing it to new
condition in 50 years from now?

~~~
dsfyu404ed
It took ~30yr for good, fairly cost effective aftermarket, fairly generalized
ECUs and transmission controllers for automotive applications to come about.

The same will probably happen to tractors and whatnot. Since the cost side of
the equation is far different for business and the problem has already been
solved in the automotive space so it may happen quicker once it starts
happening.

~~~
davidzweig
I do embedded work. Making an open-source, aftermarket electronics for
tractors, with standard interfaces.. that sounds fun.

~~~
sli
You might like tinkering with something like the Macchina[1].

[https://www.macchina.cc/](https://www.macchina.cc/)

------
emcrazyone
Companies generally don't want you in the software for safety reasons. While
true there is intellectual property around the guidance and swath generating
algorithms, companies hate lawsuits. Lawsuits tie up resources, can cause stop
shipments, generally lost profits, and tarnish the brand. Look at the Chrysler
Jeep news...

You hack or change software on a vehicle and cause the auto-guidance to run
over and kill someone or you circumvent a safety check in software unbeknownst
to you due to your software changes and a spinny sharp thing that should have
stopped doesn't and hurts or mames you or calibration changes cause engine to
to over-heat and burn up and generally the company is held responsible for it.

As much time is spent testing software as is writing software. All our testing
is there to make sure the software works as expected. Millions are spent on
test equipment and millions of hours and man hours are spent making sure
software works as expected.

I happen to work for a major agricultural company and I'm a lead software
architect for their guidance + autonomous vehicles + precision farming
embedded devices. We are one of John Deere's major competitors.

~~~
mindslight
This is indeed one of the specific instantiations of the generic single-actor
control-delusion that has always been with us, but has been greatly
exacerbated by the rise of software. And I've no doubt that it's enough to
keep the engineers' cognitive dissonance stoked - "It is difficult to get a
man to understand something, when his salary depends upon his not
understanding it" plus a bit of ego stroking from the implication that being
able to work on this particular code is _really special_.

But it's utterly fallacious. It's quite clear that if certain changes result
in different behavior, then whomever made those specific changes is
responsible for the resulting behavior. About the only leg the argument can
stand on is if the code is so sloppy that someone attempting to make a simple
change tickles a bug somewhere else, but enabling such lack of quality to
persist is the exact wrong approach for a safety-critical system!

Furthermore, regardless of its actual merit, this is precisely the kind of
Schelling point collusion that is in the collective interest to bust up.
"Selling" someone a piece of capital equipment that is deliberately designed
to prevent its own servicing is plainly fraudulent.

~~~
vvanders
Except that tractors _are_ more dangerous than your car/appliance/whatever.

You'd be amazed the amount of carnage running a brushhog at 1000rpm will do
when it was designed at 540rpm. They will happily throw the 3-4 foot blade
right though 1/2in steel up to 300-400ft in whatever direction the wind takes
them.

When that process is controlled by software all it takes is flipping the wrong
high order bit in the PTO controller. On a manual tractor it's very clear when
the PTO lever is in 1000rpm vs 540rpm(and usually on a separate lever from
engagement) vs an opaque software stack.

~~~
nightski
What is your point? I have a relative that lost his arm to a combine. There
was no lawsuit, he did not seek damages. Farmers are well aware of how
dangerous this equipment is.

~~~
vvanders
The point is I don't think allowing the modification of software in what is
essentially a factory on wheels is a safe thing to do.

When we bought our '81 Ford there was a ton of bodge jobs and half-assed
repairs(that helped us talk down the price) that I could easily verify by
visual inspection. I knew because I could see them that they weren't
inherently dangerous. Software doesn't have the same analogy in this space.

~~~
M_Bakhtiari
> The point is I don't think allowing the modification of software in what is
> essentially a factory on wheels is a safe thing to do.

Someone has to do it. What makes John Deere's embedded software engineers more
qualified to write software for a factory on wheels than the embedded software
engineers working directly for the farms?

Especially when we can't even check the former group's work.

~~~
emcrazyone
"Someone has to do it. What makes John Deere's embedded software engineers
more qualified..."

Simple, John Deere, probably like us, has spent more testing the software than
you could ever do on your own.

You can't judge complex software just by looking at it. It must be tested.
People who fail to understand this wind up making these uneducated comments.
Go study ISO26262 and the MTB calculations required to pass it and maybe
you'll change your tune.

Tested software runs on real vehicles and simulators at large companies, as I
stated, running into the multi-million dollar price range. There is zero
amount of code inspection the general public can do that would give the same
assurances you get through testing.

Bottom line: just looking at code is not enough. You must test it. This is
unit tests, simulations, field tests, harsh temperature, vibration, power
cycle, high side/low side power distribution, code coverage, etc... None of
this is possible by you inspecting code.

------
igor47
I'm "excited" about the day that I'll be forced to choose between getting a
life-saving medical device implanted, or instead throwing a hissy fit about
getting the source code to something that's going in my body. I hope we can
figure this shit out with tractors instead...

~~~
anotherevan
That's already happening.

[https://youtu.be/5XDTQLa3NjE](https://youtu.be/5XDTQLa3NjE)

[https://youtu.be/8wPAHu_zYDw](https://youtu.be/8wPAHu_zYDw)

------
EvanAnderson
I've done contract work for a manufacturer of electronic control systems for
excavation and mining equipment. They've aggressively implemented DRM in their
new products to support renting time-limited and geofenced access to optional
features. Their revenue models for the newest generation of equipment are
based in large part on the recurring revenue stream enabled by DRM.

------
dancek
There was an article about these John Deere hacking farmers a year ago, and
this is a follow-up. There was good discussion on HN back then:
[https://news.ycombinator.com/item?id=13925994](https://news.ycombinator.com/item?id=13925994)

------
AdieuToLogic
A similar situation exists for consumer grade WiFi routers in the US. For
about a year now, it's well-nigh impossible to flash routers with DD-WRT,
OpenWRT, and friends due to the new FCC conditions manufacturers paid^H^H^H^H
lobbied to get put in place.

~~~
vuln
You've peaked my interest. Has then been new legislation that has enabled
router manufacturers lock down their hardware to a point an end-user cannot
change it? All three organizations you name are open source and community
driven. They cannot possibly write or port their firmware to every platform.

~~~
plasticchris
Parent likely refers to the 5ghz dfs rules, see
[https://arstechnica.com/information-
technology/2015/09/fcc-o...](https://arstechnica.com/information-
technology/2015/09/fcc-open-source-router-software-is-still-legal-under-
certain-conditions/)

~~~
AdieuToLogic
I wish that were the case, but alas it is not. The article you link was
unfortunately an optimistic interpretation of what not yet known to come[0].

0 - [https://www.wired.com/2016/03/way-go-fcc-now-
manufacturers-l...](https://www.wired.com/2016/03/way-go-fcc-now-
manufacturers-locking-routers/)

------
tyingq
This story comes up quite often. It seems an opportunity for someone to launch
a farm equipment business that makes it's margin on the initial sale instead
of the service.

Even if it's just refurbished pre-drm tractors.

------
akshayB
This practice is pretty much rampant across all industries ranging from
cellphones to luxury cars. One simple answer is big companies just want to
extend their profits. Another reasons is they want their distributors or
dealerships or middleman to thrive as well without which their business may
get stagnant.

~~~
kevin_b_er
Because copyright and software can be used to perform a backdoor attack to
seize ownership of physical objects from you. You are looking at a full-on
attack on the concept of _ownership_. You own nothing: It is licensed to you
at the whims of the true owners.

Why wouldn't corporations, which are sociopathic "persons" defined exclusively
by their avarice not want to do so? It is more profitable to prevent repair.
It more profitable to force you into buying more.

------
bitmapbrother
According to the video lawyers from Microsoft and Apple showed up at the
legislature to voice their objections to the Right To Repair bill. Interesting
that these 2 companies would be so anti-consumer.

~~~
dfg0987098x7
What's so interesting about it, are you surprised?

Apple have been fighting the ability to run your own code on the device since
day one.

This is part of the business model of the "app store" purchase model and not
very surprising.

I'm sure even you have heard that Microsoft have been anti-consumer once or
twice over the years.

------
tomohawk
What if there was a law that any device containing embedded software would
have to either be (a) open source, with source code and docs freely available,
or (b) closed source, with source code and docs in escrow in the event that
the manufacturer ceases support, at which time the code and docs would
immediately become open source?

------
jaclaz
A similar/related thread:

[https://news.ycombinator.com/item?id=14074894](https://news.ycombinator.com/item?id=14074894)

Risking to cite myself:

[https://news.ycombinator.com/item?id=14077327](https://news.ycombinator.com/item?id=14077327)

------
ktta
This is only going to get worse. A company called Blue River Technologies,
which hopes to automate weeding was acquired by John Deere(the company being
discussed in the article). Their software is obviously more complex than
simple firmware which can be 'hacked' by the average joe.

If this weeding systems is profitable and becomes popular, these farmers are
screwed.

Here's[1] a nice longread on that company. It's a bit fluffy, but I recommend
it.

[1]: [https://www.bloomberg.com/news/features/2018-01-11/this-
army...](https://www.bloomberg.com/news/features/2018-01-11/this-army-of-ai-
robots-will-feed-the-world)

------
wmf
Is there any farm equipment (from China perhaps) that isn't DRMed? In addition
to discussing the responsibilities of vendors, maybe we can also discuss the
responsibility of customers to understand what they're buying.

~~~
userbinator
_from China perhaps_

In this case their general lack of effort around security (see the whole IoT
mess) may be a _good_ thing, as it means any DRM is more hackable.

The flipside of that is the firmware may also be buggier, but then again,
you're also more likely to be able to fix those bugs due to the hackability.
The old Douglas Adams quote comes to mind: "The major difference between a
thing that might go wrong and a thing that cannot possibly go wrong is that
when a thing that cannot possibly go wrong goes wrong it usually turns out to
be impossible to get at and repair."

------
InitialLastName
I'm involved in the design of embedded systems for a relatively consumer
market, and I've looked into making my company's designs more accessible to
modification/software manipulation. There are a few (sometimes major) costs to
allowing the modification of software that people tend to ignore in this
discussion:

\- Support: If you want to make your product more accessible to repair, you
need to provide support for that. This costs developer time (making the code
nice enough to be externally visible, maybe putting together an SDK, making
sure any actual secret sauce or anti-counterfeiting systems are blocked off),
customer support time (you WILL get calls when somebody buys a used system
with modified firmware that doesn't work), and increases the hardware costs
(want to provide a JTAG port? that's PCB space and BOM cost).

\- Brand reflection: We've all seen how much of a ripple the wrong person
having a bad experience with a product can have on the market. Say somebody
buys a modified Initech Widget (tm) that has a bug or burns some other
expensive equipment that it has to work with. That person complains on their
friendly local social media network that Initech Widgets have a habit of (say)
turning off furnaces in the middle of winter so the user's pipes freeze.
Suddenly Initech is dealing with a media ____storm because they allowed
modification of their software, which brings us to...

\- Liability. What happens if somebody modifies the software in my product and
somebody dies, burns down their house, or ( __* forbid) makes it possible to
cause harmful interference and the FCC finds out? How do I prove to that user
's (or the FCC's) lawyers that I shouldn't have to pay the damages? Let's
assume that, as in the case of tractors or mobile baseband modems (which seem
to get brought up a lot in this case) that software is a FUNDAMENTAL part of
ensuring the safety/compliance of the unit.

Every time I've been through that calculus, the answer at the end has been, "I
should do everything in my power to prevent the firmware of my devices from
being modified".

I can understand and sympathize with the arguments in the other direction, and
as a consumer I'm both qualified and interested in modifying the software on
my widgets, but it would take a lot of change in the way our society works
before most companies will put themselves at risk by supporting or even
allowing it for their products.

------
drunkencarolina
A low tech alternative, depending on one's needs could be draft horses. My
wife's family worked teams of belgians for about 80% of their 400-acre farm.

[https://www.motherearthnews.com/homesteading-and-
livestock/f...](https://www.motherearthnews.com/homesteading-and-
livestock/farming-with-horses-zmaz87jazgoe)

