dji4321234

Mostly they’re used to enable illegal RF parameters in Europe (FCC hack); DJI disabled strict geofencing in most of the “west” several years ago and that was also enforced in the drone anyway.

Root for these RCs has been available under the guise of “FCC hack” for a really long time now; different groups have different exploits (it’s DJI so there are plenty) that work on different firmware versions.

This would almost surely work there too, though.

Western state agencies and mid-tier bootleg spyware vendors are neutral at best and antagonists overall. At best, bootleg spyware vendors drop exploits which agencies can reverse and use for their own purposes. But in general, these vendors bring unwanted attention and burn exploits which the state agencies would like to use. These are not part of a global conspiracy, they are competing groups with the same goals.

Walksnail is not 802.11 based. If anything it is loosely 802.16 based. Likewise DJI OcuSync is more like LTE than anything else.

802.11 is not a good fit for FPV video and trying to use it has held non-proprietary-Chinese video systems back quite a lot.

The IOMMU on Apple Silicon only supports 16K pages. The page allocator on Linux only supports unified page sizes. Ergo, to make both IOMMU mappings and userland software work, everything needs to have 16K pages (on OSX, this isn't an issue, because XNU supports mapping both 4k and 16k pages).

It's not really non-standard so much as it is new-standard or different-standard. Aarch64 officially supports 4K, 16K, and 64K pages. This flexibility in the aarch64 ABI means that most compilers already produce 64K aligned load segments for aarch64, so it's not a huge deal except for software that works at a low level and makes assumptions about mmap (for example).

The main software that's truly affected beyond just needing recompilation or tweaks is x86/x86-64 emulation software, since x86 is pretty tightly coupled to 4k pages.

> arranging it so that DJI "just seems to never be able to" hire any security experts

They're foot-nuking themselves this way, as well. Due to their poor security, DJI are also easily compromised by Western interests and collect a ton of data about Chinese drone operations. I suppose someone could argue they decided that this is worth the cost of the operation, etc., but it seems... odd.

> hire product managers from a pool trained on CCP-sponsored university programs and industry media sources, that have those product managers parroting "useful" beliefs like "more analytics is always better."

The CCP don't need to do any work to make this happen. I totally agree that they benefit, thus my "indistinguishable from malware" comment. But this is how product management works worldwide. Maybe the modern obsession with product telemetry has been a years-long deep intelligence op, but I think it's easier to attribute to standard corporate behavior.

I wasn't exactly going for "DJI is great" - it's kind of funny that's how it came off.

My points were:

* DJI's use of Secneo on Android isn't hiding a "sendAllYourPhotosToTheCCPServerNow" function. This seems obvious but I've seen this take everywhere.

* However, DJI's apps are loaded with telemetry that's indistinguishable from malware. They ARE full of shady things.

* I wouldn't run a DJI app on my own phone.

* I would use a standalone DJI remote for most low to medium assurance applications, because while the shadiness remains in many ways, the threat model is easy to understand and boundaries are pretty easy to draw.

Overall what I'd say about DJI is that they seem to be earnestly trying to make their features work at face value.

That is, if you opt out of data collection, they seem to be earnestly _trying_ to disable data collection. Unfortunately their apps are a spaghetti monster disaster and it's very difficult for them to get things right, so DJI frequently introduce new features or libraries which contain telemetry they've forgotten to disable. In my experience they do this more often in consumer apps than enterprise apps. I think they might actually have some kind of automated testing or audit applied to their enterprise apps.

Whether this is a conspiracy to introduce subtle surveillance bugs or simple hardware-company-making-software incompetence is of course an exercise left to the reader's paranoia level.

Anyway, I just use DJI RCs and forget network credentials. This limits the DJI bug/malice blast radius surface area to an acceptable range to me, and that's the advice I'd give others, too.

No; this functionality is actually accomplished in a reasonable way, with a local database stored on the drone and checked by the drone's flight control software, and exemptions granted by uploading a signed payload to the drone detailing an unlock region and timeframe.

It's also worth noting that these restrictions aren't government imposed in countries besides China, and aren't government-linked besides a request-based "please make this location a no fly zone" process - DJI basically just exported a Chinese concept with hope of building goodwill internationally, and the no-fly zones were invented by DJI from public land use data. That's why other drones don't have no-fly zones but are still allowed for sale, there are frequent mismatches between DJI no-fly zones and real no-fly zones (both false positive and false negative), and why DJI disabled their own no-fly zone feature in much of Europe earlier this year (European mandated no-fly rules passed the responsibility to the consumer instead).

There's nothing.

Skydio exited the consumer market. Their drones had good autonomy and flight characteristics. However, they struggled with wireless link quality due to the use of consumer WiFi, and had much older, inferior camera sensors compared to even contemporary DJI drones. They were also ridiculously loud and inefficient. Their enterprise drones are comically expensive and loaded with nickel-and-dime cloud features.

Parrot drones struggle with the same issues as Skydio (Skydio actually used a Parrot remote controller for their consumer drones), plus their autonomy isn't nearly as good as even Skydio's, the overall drone behavior is "clunky" (slow boot times, slow connection times, non-responsive flight controls), and even basic flight is more challenging.

The main issues plaguing US consumer drones are imaging sensors and wireless link. LTE and other well-suited long range wireless technologies capable of handling speed differential between the station and access point are locked in a vault of patents. Imaging sensors are legendarily impossible to acquire in low to moderate quantities and image sensor parameters are carefully locked behind a billion levels of NDA (thus why even the Raspberry Pi camera is full of DRM).