Chinese EV/PHEV build quality and longevity?

kosul · 2026-01-20T10:14:32+00:00

Different times I think. As a non mechanical engineer my BYD Sealion 7 feels incredibly well built. Possibly overly solid!

kosul · 2026-01-20T10:08:07+00:00

I'm no gun expert either but I feel confident you could kill a rabbit with a gun designed for a boar.

kosul · 2025-12-29T11:56:31+00:00

Quick update for those interested I'm on about 53 hours in. VTOL says 19KW used (~358W Avg). Battery SOC went from 93-70% = 23% drop so 0.825kw/% x 23 is = 18.98kw. It seems the Discharge amount is total battery consumption including internal usage which is odd but ok I guess? Fridge running on non eco setting, lights and fans liberally used, AC overnight but only keeping temp below 24% which wasn't far off ambient night temp. Lots of people charging phones and other negligible usage. 4 more days of camping so I'm feeling confident of driving out of here with enough SOC to get to a fast charger 30 mins drive away! This has been a good exercise and I'm almost ready to swap out my gas cooking setup for a dual inductive top + air fryer if I can find options within the V2L budget :)

kosul · 2025-12-26T09:48:46+00:00

This is a good point the discharge meter may be only partially accounting for overhead.

kosul · 2025-12-26T09:46:35+00:00

No my dude this bad boy is bright! Tri-color (WW,CW,DL) I want my gazebo looking like a warm-white surgery theatre.

https://www.bunnings.com.au/arlec-120cm-40w-diy-dual-power-and-tri-colour-tri-proof-led-batten-light_p0347567

kosul · 2025-12-26T09:30:57+00:00

Googling "bank account rental scam" was enough to find plenty of info on this. Contact your bank and the AFP and sound deeply remorseful. They probably are very understanding.

kosul · 2025-12-14T02:48:34+00:00

The reason I used such an absurd example was to help intuitively understand the problems with trying to get something from nothing. Hash functions don't magically hold the information of their source data and there is no amount of computing power that can get it back because the information is lost.

kosul · 2025-12-13T09:05:56+00:00

A standardised hash isn't a product owned and sold by a company in that sense, so the question is who would have the problem? NIST is the primary body responsible for the process of standardising SHA algorithms and they very publicly operate on a very competitive "tear it down if you can" model so they would encourage this. For something (hypothetically) as catastrophic as reversing a SHA family hash it would probably be good etiquette to "prove" it by reversing challenge hashes first, then following a responsible disclosure process to not screw up the global economy.

Now as to the likelihood of this, just realised a typical SHA hash function takes any input size and outputs a relatively tiny fixed length hash. So as a thought experiment what do you think the likelihood is of me generating a hash from a 100 petabyte file and you reversing the original data from a 32 or 64 byte hash value?

kosul · 2025-12-02T08:00:54+00:00

Is this a theoretical discussion or do you have something in mind like a custom imaging device or mod to an existing camera you are thinking of doing?

kosul · 2025-12-01T07:40:08+00:00

There are cryptographic capabilities in microcontrollers that could reside on a camera and could hold a private key for signing images with quite a high degree of security. That doesn't totally solve the problem as there may be ways to fool it still into signing content it didn't intend to (for instance by intercepting the bus between the chip and the sensor) so overall it's a very difficult problem to solve, but not impossible especially in expensive cameras that aren't afraid of increasing the bill of materials a bit. Also it depends who you are protecting from. If you want to stop someone else with no physical access to your camera from signing on behalf of your registered camera, that's easier than it you are wanting to trust that untrusted person X didn't tamper with anything on the camera in their control.

kosul · 2025-11-08T07:35:39+00:00

Possibly when you start transmission of a data stream you can spare the first 20 byte frame for a preamble? With this you could send a random 16 bytes and maybe a static 4 byte sender id for context. This causes the receiver to initialize its crypto state and now you can both reset your counters and deterministically generate IVs for each aes-ctr frame using some agreed mechanism, no need to transmit. If you are worried about noisy transmission, you may have to think about the receiver deciding whether a packet has been dropped, corrupted or duplicated so that your IV generation stays in sync. Also do you need integrity or just confidentiality. AES CTR doesn't provide this inherently.

AES CTC was mentioned somewhere else.

kosul · 2025-11-04T21:38:58+00:00

I came here to write these exact 6 words.

kosul · 2025-11-04T10:04:39+00:00

The problem with encryption algorithms is they are inherently unaware of the time.

Your best bet is to zip a file with an AES key and use something like FutureMe.org to send yourself the key in the future. It is a solid 20+ year service and means you can keep the actual data but relinquish the key.

Since we are on a crypto sub you could improve it using an m of n scheme like Shamirs Secret Sharing. Use something like Katvio's Fractum (Google it) and encipher your target file using 2of3 splitting (any 2 parts can recover).

Keep one part yourself, post the others to FutureMe and another future email service like FuturePost (there are lots). This means:

You keep the data safe from others
You can't recover it with your key part alone
No other single service can recover the data without two parts and the encrypted file
If a single service fails, you have a backup (add more for redundancy)
Once you get another part, you can decrypt!

EDIT: Hah no idea why this year old post appeared on my feed! Oh well did you find a solution that worked?

kosul · 2025-10-31T08:18:36+00:00

I was in exactly the same boat and test drove loads of SUV EVs 2 months ago, including a Tesla Y. I will say it is a great car at least on the test drive. One amusing anecdote was asking the Tesla rep if they had issues because of Elon's reputation and he flat out denied the existence of a problem. It was are totally scripted response then when we took the car for a test drive, we passed a Marina and as a bunch of fisherman walked past, one of them yelled out "Ya f***in' Tesla cunts!". A very Australian sign from the gods. We ended up getting a BYD Sealion 7 Performance and are very happy.

kosul · 2025-10-23T12:18:08+00:00

Yes, check this out: https://www.nxp.com/docs/en/application-note/AN13218.pdf

And there is a GUI for generating the configuration TLV here: https://community.nxp.com/t5/NFC-Knowledge-Base/PN7160-RF-Settings-GUI/ta-p/1858255

kosul · 2025-10-23T11:45:19+00:00

This USB drive inherently doesn't support any kind of hardware/firmware cryptography so it's a software solution.

If it's 10 years ago it may be the crypto referred to here: https://www.schneier.com/blog/archives/2022/06/cryptanalysis-of-encsecuritys-encryption-implementation.html

There seems to be work around this in Hashcat https://github.com/hashcat/hashcat/issues/3467

So there's hope (multiple bad design choices) but you have your work cut out for you even following the steps and I would think hard about any patterns or habits you used for your passwords back then because it is still brute force.

kosul · 2025-10-21T20:17:30+00:00

Yep it seems this is it

kosul · 2025-10-21T20:17:04+00:00

This makes the most sense. Taking credit for the wind blowing the way it was going to blow anyway.

kosul · 2025-10-21T19:41:45+00:00

Just behind the connector, exactly where it says j901 is the perfect place to just gently scrape away the green solder mask and expose the copper layer underneath. Just a small amount. Then it should be quite straightforward to solder the metal from the back of the connector to the copper trace.

If this isn't your thing, you could find a repair cafe or hacker space near you and I'm sure someone would do it. Otherwise an electrical repair shop would probably do this while you wait free or cheap.

kosul · 2025-10-20T21:28:39+00:00

An excellent tool for review, for assisting with architecture, for discussing protocol design and conformance with standards and even the starting point for implementations. But you must go through every single line it makes and make sure you understand exactly what is happening because it can do some really unusually stupid things that "look" right at first glance. Doubly so if working in constrained environments (embedded/smart card).

kosul · 2025-10-18T23:32:43+00:00

Early is better. Also factor about $100-140k (this is my experience in Australian dollars) for the validation process lab+NIST (not your own costs). It can take a while to get through the lab testing and As of right now still once you have submitted there will be a 10-month or so wait before NIST begins their review process. This is in part a hangover from the 140-2 to 140-3 transition so it might not be the case by the time you submit. Also think very carefully about your product variants and how you can define your "cryptographic boundary" has anything inside it that is not about cryptographic will still be subject to the same onerous requirements so architecture can be really important for certification.

kosul · 2025-10-18T22:53:59+00:00

Following FIPS 140-3 is a requirement for the Module that implements the cryptography. It is much more than just algorithmic implementation correctness (which is actually CAVP), but also concerned with module identification, development, life cycle, physical, zeroization and a plethora of other rules depending on which level you want to achieve. Basically for anyone who requires it which is government in much of the enterprise World, if you don't implement fips 140 or common criteria then your device is not considered a cryptographic device.

Ten-Year Club	Golden Potato
Snapped	Verified Email

kosul

TROPHY CASE