[HN Gopher] I hacked my car
___________________________________________________________________
I hacked my car
Author : ytpete
Score : 481 points
Date : 2022-08-13 07:22 UTC (15 hours ago)
(HTM) web link (programmingwithstyle.com)
(TXT) w3m dump (programmingwithstyle.com)
| TheRealDunkirk wrote:
| 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.
| zaik wrote:
| Please don't give them ideas. Software freedom is already in a
| bad enough state.
| ThePhysicist wrote:
| That's why I try to never put any testing or development keys in
| repositories. From those keys sitting there it just takes one act
| of negligence for the keys to make it into a production
| environment. It's really frustrating that most people don't care
| about this at all. Even people forking my own projects would not
| listen when I told them to please just generate the keys
| dynamically (for which I included all necessary functionality in
| the software itself, easily accessible in CI and from the CLI via
| a simple make command), and instead just put dev keys smack in
| the repository [1]. And mind you those were some really "security
| minded" people from the CCC.
|
| 1: https://github.com/impfen/apps-
| inoeg/blob/main/tests/fixture...
| time0ut wrote:
| This. I always generate my keys or certs or whatever as part of
| my dev workflow scripts, configure the local environment to
| read these, and then gitignore the resulting files. This way it
| just works for the rest of team and the mechanisms are plainly
| visible in the repo.
|
| There are many ways to do this, but one that often fits what I
| am doing is to use terraform's TLS provider [0]. Terraform has
| become pretty ubiquitous for me. I am probably already using it
| to power other parts of my dev environment setup and teardown.
| Adding in a call to a little module that spits out a dynamic CA
| and certs signed by it is really easy.
|
| [0]
| https://registry.terraform.io/providers/hashicorp/tls/latest...
| sneak wrote:
| > _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.
| coverband wrote:
| This article confirms my insight that good programmers,
| especially those working in security, need to have a dose of OCD
| in them to be successful. ;-)
| heynowheynow wrote:
| Don't expect much from a manufacturer who until recently didn't
| use immobilizers.
| LightG wrote:
| Poor comment considering where they are now.
| alerighi wrote:
| Well is that a bad thing? Seriously, all they do is make
| extremely expensive to make a copy of the keys if you loose
| one. If they want to steal your car, they do it anyway,
| especially with modern cars that are less safe than older one.
| deepdriver wrote:
| The "Kia Boys" in Milwaukee stole almost 10,000 cars last year,
| mostly Kia and Hyundai models lacking immobilizers. That's 1
| car theft per 58 city residents, in a single year. This gonzo
| documentary on the phenomenon's worth watching:
|
| https://www.youtube.com/watch?v=fbTrLyqL_nw57
| tyingq wrote:
| Insane. And the cars in question have no immobilizer, so the
| process is just finding a 2021 or older Kia/Hyundai of a
| certain model, one with a physical key instead of a
| pushbutton. Then you just rip apart the steering column and
| turn the ignition cylinder. I was confused because a USB
| cable was involved, but it's apparently only because it
| slides nicely over the mechanism to help you turn it, as
| opposed to having to use needlenose pliers or similar.
|
| So there's no "hack" really, just destroying the lock
| cylinder.
|
| https://www.thedrive.com/news/how-thieves-are-stealing-
| hyund...
| sidewndr46 wrote:
| Insane? This is just what stealing a car was like in 1970.
| If you get the ignition to turn, you've stolen the car. If
| you're dependent on technology to stop vehicle theft,
| you've basically already lost. At the end of the criminals
| will just use a flatbed tow truck to steal the vehicle if
| it is worth enough.
|
| The "immobilizers" you're referring to are the bane of my
| existence from my perspective. Instead of getting cheap $5
| copies of my keys made, I have to pay something like $120
| to Ford to get copies made.
| deepdriver wrote:
| >At the end of the criminals will just use a flatbed tow
| truck to steal the vehicle if it is worth enough.
|
| Working-class teenagers in Milwaukee do not use flatbed
| tow trucks to steal cars.
|
| >The "immobilizers" you're referring to are the bane of
| my existence from my perspective. Instead of getting
| cheap $5 copies of my keys made, I have to pay something
| like $120 to Ford to get copies made.
|
| Ask anyone in Milwaukee whose car _hasn 't_ been stolen
| whether they regret having an immobilizer.
| sidewndr46 wrote:
| Sure, I concur that teens don't use flatbed tow trucks.
|
| But if as a society, the default has become that your car
| will be stolen then the society has collapsed. It's more
| like a bunch of competing warlords, with the most
| prominent one being the local government.
| deepdriver wrote:
| Yes, that's an accurate description of much of Milwaukee.
| staindk wrote:
| Thanks for the link - that's crazy. And awful.
|
| Wonder how true it is that you only get a couple of weeks in
| jail for stealing a car (in Milwaukee at least)...
| ReadTheLicense wrote:
| In what universe is 20+ years "recently"? Actually the Hyundai
| I had - with an immobilizer - was made in 1995 so 27 years. Is
| this American thing?
| stjohnswarts wrote:
| We had them that long too, just like card readers, we just
| didn't have laws requiring them. No Europe wasn't more
| advanced than Americans (and still aren't) but they did have
| better laws for the situation. So you can have that win I
| suppose.
| hnick wrote:
| It might be, my 15 year old Getz has one (I know because it
| plays up sometimes due to poor conductivity), but that was
| never released in the US.
| deepdriver wrote:
| Apparently some modern US Hyundai models don't have
| immobilizers:
|
| https://www.thedrive.com/news/how-thieves-are-stealing-
| hyund...
| cjg_ wrote:
| Immobilizers are mandatory in EU since 1998, so yes.
| [deleted]
| tpmx wrote:
| https://www.cbsnews.com/chicago/news/thefts-of-kias-and-
| hyun...
|
| Hyundai Motor America:
|
| _Immobilizers became standard on all vehicles produced after
| November 1, 2021._
| devonallie wrote:
| >> I have to wonder if they used that linked "RSA Encryption &
| Decryption Example with OpenSSL in C" tutorial...
|
| Makes me feel better about my own incompetencies. But also makes
| me scared for the future of safety in vehicles.
| johannes1234321 wrote:
| Well, for security code a common mantra is "don't invent it
| yourself" :)
| amelius wrote:
| Was that sample code GPL'ed?
| userbinator wrote:
| Once again, their insecurity is our freedom. One does wonder
| whether those who were asked to implement this "security" were
| not happy about doing so, and just decided to make the equivalent
| of a speed bump instead of a wall.
|
| I remember "carputers" were a somewhat common aftermarket mod in
| the early 2000s, mostly running a stripped-down 98 or XP on an
| SSD or memory card. The obvious difference being that you had
| full control of it from the start. Here's an example of someone
| doing so:
|
| http://www.avbrand.com/projects/carpc/
| cs702 wrote:
| I've heard of much worse security no-no's. The worst example I'm
| familar with is of a Fortune-500 corporate database with data for
| millions of private citizens exposed for _years_ on the public
| web over plain old http (not even https), without any password or
| public /private key protection, such that anyone anywhere with
| the right URL or IP address could access it.
|
| The big question, of course, is: Why haven't we had a security
| apocalypse? I imagine it must be because most software engineers
| are honest, and because the bad actors who have the skills and
| resources to pull it off (e.g., foreign government agencies) have
| a vested interest in maintaining the status quo.
|
| So, non-technical managers everywhere go on with their lives
| thinking their software infrastructure has been "secured,"
| without really knowing whether it's true. Consider that no
| executive or manager at Hyundai was aware until now that their
| vehicles have been using a previously published private key to
| update their software.
| paledot wrote:
| For my money, they're still not aware and wouldn't know what it
| meant if someone told them.
| lupire wrote:
| fmntf wrote:
| Kudos to the author! I did some research in my car a few years
| ago. Unfortunately, the update packages were properly signed. So
| I reversed the CAN traffic and replaced the infotainment ECU with
| my own reimplementation. I published my work and findings on
| medium thinking that nobody could notice them... I have got a job
| in the automotive industry instead.
| bri3d wrote:
| That's pretty cool! I wonder how properly they were really
| signed - there are _so many_ mistakes even in systems that at
| least don't use an example key off the Internet.
|
| The most common ones I know of are:
|
| * Out-of-bounds write issues allowing "signature was validated"
| flags to be overwritten in Flash memory, like
| https://github.com/jglim/UnsignedFlash
|
| * State machine mistakes, like
| https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md -
| allowing Flash to be written again after it was already
| written, without an erase first.
|
| * File format parsing mistakes, like those in a number of VW AG
| head units: https://github.com/jilleb/mib2-toolbox/issues/122
|
| * The use of RSA with E=3 and inadequate padding validation,
| like https://words.filippo.io/bleichenbacher-06-signature-
| forgery... .
|
| * Failure to understand the system boundaries, like in the
| second part of https://github.com/bri3d/simos18_sboot where
| "secret" data can be recovered by halting the system during a
| checksum process.
|
| * Hardware fault injection issues, as used in
| https://fahrplan.events.ccc.de/congress/2015/Fahrplan/system...
| .
|
| Fundamentally this is of course, a very hard problem, since in
| the "protect against firmware modification" case, the attacker
| has physical access. But, compared to the state of the art in
| mobile devices and game consoles, automotive stuff is still way
| behind.
| rasz wrote:
| Any reason for not linking to that medium post? Did the new
| employer politely ask you to take it down?
| navanchauhan wrote:
| They probably did not want to self-promote. Here is a link to
| their Medium articles: https://medium.com/@fmntf
| twawaaay wrote:
| 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.
| dang wrote:
| > most developers from Asia do not really expect or care about
| privacy and are super quick to drop any quality standards to
| meet deadlines
|
| You started a hellish, tedious flamewar with this. That's
| exactly what we're trying to avoid here.
|
| Please edit general putdowns, casual swipes, and flamebait out
| of your HN comments, and stick to what you can legitimately say
| from your own experience.
|
| https://news.ycombinator.com/newsguidelines.html
| sho_hn wrote:
| > 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.
|
| Having lived and worked in South Korea for 4 years, I can't
| confirm this to be true. My Korean colleages were no less
| diligent than the ones I now have in Germany, on average. It's
| true that pressure is high and projects are often run in an air
| of permanent crisis mode to keep the pressure up, though. If
| corners get cut the decision usually comes from above.
|
| I do systems engineering on operating systems and HMI for
| consumer electronics. In Korea it was for smart TVs and
| industrial equipment control, in Germany for cars.
| irogers wrote:
| Fwiw, this would fail Android's Compatibility Test Suite:
|
| https://android.googlesource.com/platform/cts/+/3ece5ae7a51d...
| twawaaay wrote:
| Not necessarily. There are various ways to conceal a
| listening service, for example through knocking protocol.
| VectorLock wrote:
| If you're implementing a knocking protocol, you probably
| know enough to change the default password.
| mistrial9 wrote:
| [deleted]
| rubicon33 wrote:
| How is this isolated to Asia? As a developer in the USA, I've
| seen prioritization of deadlines over quality in nearly every
| org I've worked at.
|
| We would probably all love to hand write encryption algorithms
| for data transfer, or beautiful animations on user
| interactions, or perfectly graceful fault handling, or 100%
| test coverage.
|
| The reality is that kind of work takes far longer than most
| employers are willing to wait. I doubt heavily that it's the
| engineers love of coding that is lacking, rather the employers
| patience.
| hef19898 wrote:
| The more an org talks about not cutting corners, as a rule of
| thumb, the more corner cutting is going on.
| aaaaaaaaaaab wrote:
| >We would probably all love to hand write encryption
| algorithms for data transfer
|
| Yikes. Funny that you mention this, because it's precisely
| the kind of thing that one would expect from this sort of
| "talent", and not from real engineers.
|
| No. One does not hand-write encryption algorithms, unless
| they are Daniel Bernstein or similar.
| headsupernova wrote:
| Amazing stuff here folks - this big brained developer just
| generalized a literal continent of billions of individual
| people and is the top comment on smart people site hacker news
| dot com
| dang wrote:
| Please don't react to a bad comment by breaking the site
| guidelines yourself. It just makes everything worse.
|
| Also, while I have you: can you please not use HN primarily
| for political/ideological arguments? It looks like that's
| what your account has been doing, and it's not the intended
| use of the site.
|
| https://news.ycombinator.com/newsguidelines.html
|
| https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme.
| ..
| jpoesen wrote:
| "most developers from Asia do not really expect or care about
| privacy"
|
| -> You did a casual racism there, unless you can back up your
| claim with non-anecdotal evidence.
| audessuscest wrote:
| He said clearly that he talks from experience. Do you want a
| peer-reviewed paper to back his claim?
| boruto wrote:
| There was post some years ago how teslas code is a mess. Do
| you attribute the quality of that code to blue eyed
| Europeans?
| aaaaaaaaaaab wrote:
| No, we attribute that to startup culture's cavalier
| attitude towards code quality.
|
| Asian cultures' have similarly cavalier attitude towards
| privacy.
|
| Noone said anything about races. Asia is a continent.
| acka wrote:
| Continents don't have cultures (and neither do
| ethnicities), people do. So what is your point again?
| aaaaaaaaaaab wrote:
| The point is that the statement "Asians value privacy
| less" doesn't talk about "Asians" as a racial group,
| rather, it merely observes that for whatever
| historical/cultural/sociological reasons, a particular
| group of people, whom happen to live in a certain area of
| the globe, might be less predisposed to raise concerns
| about the privacy implications of their software
| engineering practices.
|
| Thus the claim that the original comment was racist is
| false in my opinion.
|
| Another argument against this claim would be the fact
| that Asian software engineers (here "Asian" is used in
| the racial sense) raised in Western countries with a
| strong culture of privacy, seem to be just as privacy
| conscious as their Caucasian counterparts.
| jpoesen wrote:
| I get your point, and I should have said "you did a
| prejudice there" instead of "you did a casual racism",
| because the OP's opinion did not express systemic
| oppression or a belief that (in this case) 'Asians' are
| inferior as a whole to other ethnicities.
|
| Thank you for giving me the opportunity to correct
| myself.
|
| That said, both the original post and several comments,
| including this comment's parent, are equally prejudicial:
| attributing qualities to large groups of people based on
| location or ethnicity and solely relying on anecdotal
| evidence as opposed to controlled and peer-reviewed
| study.
|
| Case in point: are there any studies to back up the claim
| that 'Asian' folks raised in Western countries are more
| privacy conscious than their 'natively raised'
| counterparts?
| cdmckay wrote:
| I do if he's going to make a generalization about an entire
| continent of people
| SNosTrAnDbLe wrote:
| A datapoint of 1 is not really how I would characterize
| experience in a continent with literally thousands of large
| corporations.
| jpoesen wrote:
| And I clearly asked if he has non-anecdotal evidence to
| back up his claim.
| mistrial9 wrote:
| I lived in Hong Kong for a short while before that handover
| to the PRC. Daily, constant references to race were common;
| stories about people based on race were common; social and
| economic analysis in casual conversation based on race were
| ordinary.
| jpoesen wrote:
| I lived in West Africa for 5 years and experienced the
| same, coming from locals: prejudice against each other's
| tribal origins and prejudice against foreigners.
|
| But I fail to see how my and your experience are relevant
| to the way OP expressed himself re: 'Asian' behaviour?
| bloqs wrote:
| It's a largely accurate statement
| jpoesen wrote:
| Based on?
| boruto wrote:
| legionnairee wrote:
| Regional (Business) Cultural Norms
| jpoesen wrote:
| Interesting. Any research or other non-anecdotal sources
| you can point me to?
| Banana699 wrote:
| The 'S' in iot stands for security.
| havblue wrote:
| >If I could figure out all of the security measures of the
| firmware updates, I could modify an existing system image with my
| own backdoors, giving me full access to the IVI.
|
| I suppose if you brick your own computer the dealership probably
| won't realize that you were the one responsible. Just don't say,
| "yeah I cracked your ivi but after I modified the system image
| the car wouldn't start anymore...." Still, you might want the
| full warranty before attempting this step...
| tialaramex wrote:
| 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 in certificates for the Web PKI
| and encourage software to use these keys (rather than their own
| examples) in sample code. Basically when you build my-cool-
| website.example and copy paste the private key from an example
| into your certificate fetching code, the CA should say "Er, no,
| you need to actually choose your _own_ private key, that 's what
| the word private means" and this should happen when you copy-
| paste a high-rated Stack Overflow example, the provided sample
| code from the library you used etc. Ideally these would all be
| the same keys is the idea.
|
| It would also make sense for tools to care about these example
| keys e.g. GitHub could flag code that's checked in and has keys
| which are _not_ these examples since maybe you used real keys by
| mistake in your GitHub repo, meanwhile your build-for-production
| CI tools could reject keys which _are_ on the list because that
| means you forgot to pick actual keys for the real build.
| scosman wrote:
| I wonder if sample code using keys that don't look secure
| ("1111...") would lead to more or fewer incidents. Easier to
| guess, but more clear you're using guessable keys to the
| developer importing the code.
| spockz wrote:
| 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.
| oneepic wrote:
| Out of curiosity, do you have any tools/processes to avoid a
| situation like putting real secrets in new docs? Such as this
| popular story from 2017 [0]. And is there a way to automate
| publishing a test secret(s) to a doc and also send it to the
| blacklist?
|
| [0] https://www.reddit.com/r/cscareerquestions/comments/6ez8a
| g/a...
| spockz wrote:
| None other than peer reviews and habit. All our passphrases
| are something like "exampledatabasepassword" whereas in
| reality they are long tokens.
|
| Then, secrets from production are hard to extract and
| typically rotated (semi-continuously). So it would be very
| strange if that somehow ended in up in a developers paste
| buffer to add to the docs.
| aaomidi wrote:
| 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.
| teddyh wrote:
| > _https://datatracker.ietf.org/doc/draft-gutmann-testkeys/_
|
| I read the document hoping for an example Authorization: Bearer
| token auth, but was disappointed. Even more surprising was the
| lack of any ed25519 key; I would also have used this in my
| documentation.
| technion wrote:
| Bahaha, that second Google hit for that key was a joke I must
| have written a decade ago.
|
| https://snakeoil.cr.yp.to/submissions/Lolcipher%20Submission...
| alerighi wrote:
| They say that I'm against progress when I say that I'm contrary
| to all this new things that are adding to cars since they are
| dangerous. And this article proves my point of view, if who made
| the software used publicly available encryption keys (one that
| knows what it's doing knows that to generate them with openssl
| you take 1 second) how can that software be trusted?
|
| To me self-driving car and all that amount of stuff is simply
| dangerous, what if someone hacks a million of self-driving cars?
| What damage can he do? A disaster, worse than hacking a nuclear
| power plant... and I said coding standard for this kind of
| vehicle is not minimally comparable to the one of nuclear power
| plants. We are talking about people that till yesterday did
| program the offline car radio software that now are programming
| software that can take the control of the vehicle.
| AlotOfReading wrote:
| I've been involved with the software side at a few companies
| producing autonomous vehicles and took a look at SSG-39 to see
| how much better nuke standards are. They're pretty dang similar
| to automotive standards (UL4600, SOTIF, etc). The difference is
| in the regulatory environment and execution. Automotive
| software is _not_ well-regulated and most OEMs don 't think
| either the software or the people that produce it are worth
| investing in. I regularly have disagreements with systems folks
| about whether we should focus on actual sources of quality
| issues like memory safety or the checklist items that
| regulators are going to look at like whether the compiler is
| verified.
| [deleted]
| Aloha wrote:
| I wish I could do this with my UConnect device.
| altitudinous wrote:
| Outstanding blogs, really enjoyed reading them. Someone talented
| actually performing a hack, rare these days.
| Gordonjcp wrote:
| The thing that puts me off ever buying a new car - particularly
| an EV - is the insistence on loading it down with things like "In
| Vehicle Infotainment". I don't want that. I want an entirely
| gadget-free car.
| sircastor wrote:
| I worked on Infotainment for a number of years with an Automotive
| OEM. I've only ever heard insiders use the term IVI, so I'm
| curious if the author has some exposure to the industry.
|
| As for gaining access to the engineering, I'm interested that it
| was left in. We logged everything of course, but all of our
| engineering tools were removed during the build process.
| Essentially, our engineering mode was baked out.
| ocdtrekkie wrote:
| I assume they intend for some of it to be used by dealerships
| (like firmware updates), which usually aren't done OTA.
| sircastor wrote:
| Late model vehicles (I would say the past 3-5 years)
| definitely do system updates OTA, at least for vehicles that
| I worked on.
| Youden wrote:
| 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 alternative
| though, especially if the vehicle's cellular connection can be
| used. Hell, if the IVI uses the CAN bus, perhaps there's a
| reverse-engineerable list of PIDs.
|
| [0]: https://eur-lex.europa.eu/legal-
| content/EN/TXT/?uri=CELEX%3A...
| someweirdperson wrote:
| 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.
| Youden wrote:
| Unfortunately for EVs most of the interesting stuff isn't
| standardised. If it was, life would be much easier.
| someweirdperson wrote:
| Sorry, I missed that point about EV, I didn't expect OBD-Ii
| PIDs and EV in the same sentence.
| Youden wrote:
| To be fair, my use of the terminology might be completely
| wrong. By "PIDs", I mean in general the identifiers I
| send to the car to retrieve information.
| geraldwhen wrote:
| 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.
| sircastor wrote:
| I had a boss when I worked in Automotive who used to say "We're
| not a car company that makes software, we're a software company
| that makes cars"
| TheRealDunkirk wrote:
| 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.
| drukenemo wrote:
| 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.
| LightG wrote:
| 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.
| _whiteCaps_ wrote:
| Oh, so you put a deposit down a year ago? /s
|
| They're incredibly hard to buy right now, I've been on the
| waiting list for months.
| gameshot911 wrote:
| This guy is insanely skillful. Wow.
| gameshot911 wrote:
| And more than that - insanely perseverant and tenacious. A very
| powerful combination.
| dabigjhall wrote:
| This sort of idiocy is why I removed the modem from my Niro EV:
| https://www.kianiroforum.com/threads/how-to-remove-head-unit...
|
| (It is basically the same head unit, Kias/Hyundais share a lot of
| components.)
|
| IMO Kia makes great cars but I don't trust them with Internet
| security. Android device permanently connected to the Internet
| with unfettered access to the CAN bus of my car....no thank you.
| And even if it was relatively secure today, I doubt it will get
| security updates for the 10+ years I expect to have the car, if
| at all.
|
| I'm glad folks can now sign their own firmware to run on their
| own cars, but what else is vulnerable in these things?
|
| The car is amazing otherwise, and I'm glad Kia does not seem to
| use the modem for any anti-features, so the car is totally fine
| with removing it.
| londons_explore wrote:
| What would be the downside of Hyundai just making all the info in
| this blog post public info?
|
| They could start fostering an app ecosystem for their cars.
|
| And it would be an extra selling point for their cars (especially
| if there are apps that won't run in other cars).
|
| And it might even turn into a new revenue stream by building an
| app store.
| meibo wrote:
| There are some things you don't want to run apps on, even if
| they're sandboxed, which isn't the case here - I would count
| "computer in my car that can talk to the stuff that makes it
| go" as one of these things.
| EMIRELADERO wrote:
| And yet most cars run apps. Are you arguing that those not
| coming from/authorized by the manufacturer are less
| legitimate, or should not deserve the same treatment?
| lozenge wrote:
| That seems... incredibly obvious? If there's a software bug
| that is a safety risk, the regulatory agencies force the
| manufacturer to implement a recall at their own expense.
| That wouldn't be the case for third party software.
| teamonkey wrote:
| The garage can charge ridiculous amounts of money for trivial
| features and upgrades. Although the manufacturer may benefit
| from an App Store, the garage gets nothing.
|
| Toyota, for example, charges something like $150 for a single
| satnav maps update, although now CarPlay/Android Auto is a
| standard feature and has tanked that market.
| rasz wrote:
| GM charges for access to key cloning and module
| programming/pairing. Its not overly expensive (~$40 per
| module), but super annoying and bug infested (software
| crashing/failing/constantly updating).
|
| https://www.acdelcotds.com
|
| Afaik Ford has similar program where you pay one time fee for
| ability to reprogram modules remotely.
|
| Imo a good deal for consumers.
| mjg59 wrote:
| So uh the IVI system runs a wifi network and is also on a CAN bus
| that allows the doors to be unlocked
| (https://programmingwithstyle.com/posts/howihackedmycarpart3/)?
| This seems like a situation that might have bad outcomes.
|
| (To be fair I suspect the IVI isn't running unless power is
| turned on, which limits the number of real world threats, but it
| does potentially offer a new avenue for carjacking)
| kclay wrote:
| The Mac address part stood out to me, has something changed over
| the year that made changing Mac addresses more complex?
|
| Back in college our school had some limitations on the internal
| networks in our dorms. After doing my normal stuff (you know mega
| downloading,ftp, limewire etc) my net stopped working. Come to
| find out they had a bandwidth monitor and would just block you
| for some time if you used too much and had to contact tech
| support, even for simple things like window updates.
|
| Anyways, somehow I found out I could tweak some net configs in
| the registry. So here I randomly change some dword value to
| change my Mac address. I finally got back online and just forgot
| about it.
|
| A few days later I came back to my room after classes, my
| roommate told me the school officers raided the room trying to
| get on my PC. I went to the student dean's office and come to
| find out I took net access from I think the president and they
| tracked it to my PC ... Some luck I say lol .. Tech support said
| that there was no possible way I could change my Mac address
| after a bit back and forth I decided to just agree with him.
|
| O yeah and they had like a 200-300 page printout of irc chatlogs
| ,there was more stuff but I'll end it there.
|
| Needless to say my net access was blocked for a year even tho I
| had a work study job with the webdev department. It didn't stop
| me though, I ended up running a long cat5 cable from the dorm
| next door. Fun times.
| chmod775 wrote:
| > has something changed over the year that made changing Mac
| addresses more complex?
|
| It just depends on what the driver/hardware lets you do. Some
| drivers don't support changing it and some hardware/firmware
| may just be built in a way that doesn't make changing it
| (easily) possible. Not being able to change it may be more of a
| WiFi thing though. I've had the displeasure of dealing with one
| of those cards. Not sure if it was just the driver.
|
| The Linux Kernel driver for Intel Ethernet supports changing
| the MAC address, so there's an example of what that may look
| like:
| https://elixir.bootlin.com/linux/v5.19/source/drivers/net/et...
|
| That's already at the driver level though. There's a couple
| dozen other manufacturers with drivers in the Linux kernel, and
| their cards may work entirely differently.
|
| If however your hardware allows you to have sufficiently low
| level access, your MAC address can be whatever you want it to
| be. After all, if your device says "this is my MAC address",
| then that is its MAC address as far as anyone talking to it is
| concerned.
|
| If your card is a black box and is doing all the work
| internally (I think that'd be most cards?), then you're at the
| mercy of what it lets you do.
|
| At the other end of the spectrum you'd have programmable
| NICs/"FGPA with an Ethernet port".
| o_____________o wrote:
| Small shoutout to https://github.com/halo/LinkLiar
|
| > This is an intuitive macOS status menu application written
| in Swift to help you spoof the MAC addresses of your Wi-Fi
| and Ethernet interfaces.
| crote wrote:
| Network cards have a factory-configured MAC address, which is
| the default one the adapter will use. As you figured out, the
| operating system is usually able to override this MAC address-
| but it has to redo this every time it initializes the adapter.
| It'll still have its original MAC on a different system.
|
| However, in the article they did not have control over the
| operating system. So how do you change the MAC address then?
| Well, you change the factory-configured MAC built into the
| device - which requires using the factory configuration tool!
| [deleted]
___________________________________________________________________
(page generated 2022-08-13 23:01 UTC)