Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I hacked my car

programmingwithstyle.com

Post reply on HN
Print view View original

31–40 of 142 posts

Re: I hacked my car

#31

Post by LightG »

drukenemo wrote: post #24
geraldwhen wrote: post #22

I would be shocked if Hyundai wasn’t outsourcing most of its software development to the lowest bidder. Any company that believes its core business isn’t software will not pay for software developers.

I’m not so sure. Hyundai/KIA are entering aggressively the EV market in the west. I have an Ioniq 5 and its software, although not bug-free is incredibly nice to use. The touch screen is very responsive too. I would be shocked if they are not taking software development seriously. The car is basically software on wheels.

Agreed based on test drives. Hyundai are at the top of my EV list. Congrats on the car. Looking to pick one up inside 12 months.

Re: I hacked my car

#33

Post by someweirdperson »

Youden wrote: post #15

Wow, this series of posts is awesome! I have a Kia EV6 and just finding the OBD-II PIDs is a massive pain in the arse. Kia is actually required by EU law to disclose them (Art. 61 EU regulation 2018/858 [0]) but refused to do so even when I wrote to them. Need to follow that up with a complaint to the Spanish type approval authority (which approved the EV6)... Writing custom software looks like a really promising alt…

PIDs according to J1979? The vehicle itself discloses them in the PIDs dividable by 0x20, where each bit indicates the availability of one of the next 32 PIDs. Each PID is described in great detail by SAE, too, no manufacturer specific information needed for interpretation.

Anything that is not J1979 but purely manufacturer defined though, is a different story, and making that available is the main reason for the existance of the regulation.

Re: I hacked my car

#34

Post by TheRealDunkirk »

I worry that embarrassing cases like this are going to cause global corporations to call for the ban of general purpose computers for the public. I mean, look at all they’ve done. We’re at a tipping point with the right to repair movement, but John Deere still hasn’t lost yet.

Re: I hacked my car

#35

Post by sneak »

> The logs turned out to be a treasure trove of information on how the IVI works under the hood.

I hope that one was intentional; I chuckled.

Re: I hacked my car

#36

Post by TheRealDunkirk »

geraldwhen wrote: post #22

I would be shocked if Hyundai wasn’t outsourcing most of its software development to the lowest bidder. Any company that believes its core business isn’t software will not pay for software developers.

I would love some insight on the internal process. If the place is anything like mine, this would have been the result of years of planning, months of meetings, endless spreadsheet checklists, and committee reviews, with an internal group, but staffed with mostly outsourced programmers.

Re: I hacked my car

#37

Post by Youden »

someweirdperson wrote: post #33
Youden wrote: post #15

Wow, this series of posts is awesome! I have a Kia EV6 and just finding the OBD-II PIDs is a massive pain in the arse. Kia is actually required by EU law to disclose them (Art. 61 EU regulation 2018/858 [0]) but refused to do so even when I wrote to them. Need to follow that up with a complaint to the Spanish type approval authority (which approved the EV6)... Writing custom software looks like a really promising alt…

PIDs according to J1979? The vehicle itself discloses them in the PIDs dividable by 0x20, where each bit indicates the availability of one of the next 32 PIDs. Each PID is described in great detail by SAE, too, no manufacturer specific information needed for interpretation. Anything that is not J1979 but purely manufacturer defined though, is a different story, and making that available is the main reason for the exi…

Unfortunately for EVs most of the interesting stuff isn't standardised. If it was, life would be much easier.

Re: I hacked my car

#38

Post by twawaaay »

Most development at very large companies happens by hordes of people who call themselves developers but do not care about development and barely understand anything they are doing. Most coding happens by copying and pasting from Stack* and then restarting the application hundreds of times and tinkering with the code mindlessly until it happens to work. Anything besides getting the "happy path" (sic!) to work is a secondary concern.

Add to it that most developers from Asia do not really expect or care about privacy and are super quick to drop any quality standards to meet deadlines. And the management that likewise does not value quality besides things that can be easily seen and typically does not tolerate any delays for anything that is not absolutely necessary.

I worked for a well known, huge Korean company. When I was there I learned they shipped a mass produced device with a telnet server with a simple default password. This wasn't done for any evil purpose -- the development team decided this would improve their ability to debug any production problems they might face. They were not trusting their own code and were looking for a quick and easy solution to deal with inevitable deluge of support tickets.

Re: I hacked my car

#39

Post by spockz »

tialaramex wrote: post #13

One of the things I remember being discussed on m.d.s.policy not so long ago was making a registry (maybe handled by IANA) for example private keys. Turns out Peter Gutmann did the heavy lifting (thank you Peter) to turn that from idle discussion into a draft document: https://datatracker.ietf.org/doc/draft-gutmann-testkeys/ From the point of view of m.d.s.policy the main idea is to require CAs to reject these keys i…

We actually do this in our internal framework. All secrets (passwords, key material, etc) that we have in documentation and example projects are blacklisted for production in the framework itself and applications refuse to start.

Re: I hacked my car

#40

Post by aaomidi »

tialaramex wrote: post #13

One of the things I remember being discussed on m.d.s.policy not so long ago was making a registry (maybe handled by IANA) for example private keys. Turns out Peter Gutmann did the heavy lifting (thank you Peter) to turn that from idle discussion into a draft document: https://datatracker.ietf.org/doc/draft-gutmann-testkeys/ From the point of view of m.d.s.policy the main idea is to require CAs to reject these keys i…

For what it’s worth, if a private key related to a certificate is exposed and then revoked. That private key is effectively retroactively banned from that CA in its entirety.
Post reply on HN