Unlocking any car from X brand in most of the world
https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/White one is harder to tell obviously, but the shape of the mirror looks the same, and you can see the top of the dash has a chamfered shape that looks an awful lot like this pic: https://media.ed.edmunds-media.com/toyota/rav4/2022/oem/2022...
Posting a video demo probably isn't a great idea for this kind of thing. I'm sure some sicko could have figured this out just from the sound the locks make.
I'm assuming he means AWD.
What does this mean?
I’m not saying physical keys are not needed, but a nice digital solution is one of the things I really wish I had a Tesla. I wish the other car manufacturers would actually invest in good mobile experiences, they’re all such ass.
You will need an online account with obscure terms of service to use the car, won't be able to repair yourself, your data being sold, etc.
Evil.
I.e. a Wiki where you supply Make/Model/Year, receive instructions on which fuse to pull, which box to remove or disconnect.
Right now this information is so scattered across the web, disorganized, and full of errors. Sometimes buried in YouTube videos. Even LLMs cannot provide accurate info and you need to do laborious research.
Somebody make this happen.
You realise that in the EU cars have a SIM in, and an emergency button? This is since 2018, see: 112 eCall regulation.
I've been telling people that 2006 is peak car for at least 5 years and almost everyone thinks I'm crazy but I just get more convinced ever year.
It's really an indictment of the sorry state of modern web design, where everything is punted client-side and APIs are exposed. Ooh... it's "rich" content... so what.
They didn't have these types of issues doing logic server-side in CRUD apps 20 years ago. Unauthenticated users got the boot. It was easier to secure.
Guys were doing the same shit in JSP and ASP or even Perl CGI in the 00s and these issues were nonexistent.
Makes you reflect on how, most of the time we rely on a baseline trust placed in most of the people around us.
Daybreak red for offensive action is a better trained model of Sol 5.6 for offensive action.
I highly doubt that modern car ignition locks are not also just sending a start signal via the CANBus. If they had a physical wire to trigger engine start it seems like that would make hotwiring the car easier, since I believe that is how older cars worked?
I've heard so many horror stories starting like this.
That's a funny perspective from a hacker. From the other side I'd be incredibly annoyed if my application server was legitimately resolving path directions like "..%2F". That's the kind of "feature" that's been responsible for some of the worst compromises recently. I'd include both *sshole and log4j in that category.
Car ignitions, actually starting a car a driving it away, are a totally different thing.
A cursory glance seems to suggest it’s right and it took less than 2 mins to both ask and check its answer, which is a little scary.
[1] https://github.com/ide/lexy/blob/main/docs/vehicle-status-an...
I do understand that selling your customers' data is lucrative, but of all the car makers, not a single one thinks there's a market for an alternative?!! I don't understand.
I'm also slightly worried about HN's "solution": buy cars old enough not to be enshittified. Sure, I get the instinct, but there's a limit on how long that'll work. Much better would be to be politically engaged and work for a better future where this shit is illegal.
In the past few years, we'd found ways to remotely control vehicles from Honda, Acura, Nissan, Infiniti, Hyundai, Genesis, Ford, Porsche, Kia, and Subaru, but we'd never found a vulnerability that enabled remote access to either an Automaker #1 or Automaker #2 vehicle.
IMO the practical solution to this problem - because telling companies "just do security better" works as much as telling fat people "just eat less" - would be some kind of central registry of car parts. This was already implemented in iPhones back in the day that if a repair wasn't signed off by Apple, you couldn't install a new part to your iPhone. I imagine that if the government had a similar thing but for cars, then thieves would stop stealing cars because each stolen part would eventually be flagged somewhere and the end customer would be upset, never coming back.
I say "government" because companies cannot be trusted to make a simple interface "log in -> enter part number and car license plate -> ready to install". I assume that outside of the US the "log into government website" part is already solved in one way or another. On the privacy side, it really shouldn't be controversial, assuming that people are already used to the VIN having a repair history tied to it.
It's not that difficult. If your security is bad, somebody finds and tells you. Then you have five options: (a) attempt to prosecute them, (b) thank them for their volunteer work and tell them to fuck off, (c) give them some loose pocket change for their help, (d) actually pay them a real bounty, (e) offer to hire them. ~0% pick E, ~10% pick D. The people who can help them literally come to their door with hard proof of their ability to help, voluntarily, and 90% of the industry snubs their nose at the very people who can take advantage of bad security. This problem is entirely self-inflicted.
- Never hard-code credentials (especially in front-end exposed code)
- Never share credentials between environments (especially between prod and non-prod)
And that first rule, in particular, you can (and should) very easily enforce with static analysis tools. If they had just made it harder to shoot themselves in the foot, with basic checks like that, this hack would probably not have been possible.
Is it so hard to just offer said hackers a boatload of cash to switch sides?
Also worried in 50 years reviving old cars would be tough because some servers were down. Maybe a maker goes under and stops signing their parts?
Sure it could be implemented intelligently instead though. But maybe better to ensure all have superb education and employment opportunities at wonderful wages. (Prob cop out that one can say about any solution)
I disagree. There are quite a few talented security engineers out there that aren't employed. For some of them it's because they don't have impressive resumes or don't market themselves as such; let's assume that's on them.
But the other reason there's not enough security engineers is companies don't consider security essential. I have worked at some big companies. All of them failed to implement basic security best practices. If there were any red teamers on staff, they only focused on one or two areas of the company. The reason is simple: paying for security doesn't generate revenue or increase your stock price. So business leaders don't care if it's insecure, so hiring managers don't hire security engineers.
Of course, this means the security is going to be a shit-show and there is financial incentive to delay improving things for as long as possible; the recent discussions about "cyber-attack insurance" in response to the attack against retailer fridges sort of epitomises the problem: even when the nightmare scenario happens the suits refuse to see that the root cause of the problem was the application of Standard Business Practices(TM).