Earlier quoted context omitted.
It's syntactic sugar in the sense that arr[i] is just shorthand for *(arr+i) There's no abstraction or 'concept' of arrays there. You are literally just telling the compiler to take a certain pointer and move i steps ahead.
Isn't that the definition of an array? Chunk of contiguous memory plus a notion of how to subdivide it into equal parts?
Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
71–80 of 171 posts
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#72Earlier quoted context omitted.
> Most modern systems have a MMU to prevent the peripheral from DMAing to memory areas not specifically reserved for it, but given (certainly Android) systems run oldschool kernels hacked together by the last kind of crowd you want working on them it's probably not enabled or setup correctly. I'm not sure it's fair to assume iOS IOMMU isn't set up properly just because that's the case on many (most?) android phones.…
I didn't want to suggest that iOS is insecure because Android systems are. For Android we know most of them are hopeless, on iOS it's security by obscurity all the way with just a generally good "track record". Well, they patched something. Maybe they just patched the firmware image that is loaded onto the chipset on boot and there was no privilege escalation onto the iOS application processor. But if there was, the…
Huh? If criminals can “easily” inspect the patch, why can’t the public?
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#73C's lack of array size info strikes again: memcpy(current_wmm_ie, ie->data, ie->len); where "ie" points to data obtained from the net.
Programmer's mistake for not validating data, not the fault of C language mechanics. Yes it would be easier if , still gotta be careful. I've made plenty of these mistakes but never blamed the language.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#74Earlier quoted context omitted.
One theory I've seen bandied about related to GPU drivers is that it's harder for your competitors to notice you're infringing on their patents if you don't ship your source code.
This seems unlikely. (Or maybe that's the reason given, but it seems implausible to be true.) Competitors have more than enough know how to determine if you're infringing a patent, source or no source.
How do you figure? The detectability of infringement is a key factor in deciding whether to file a patent.
Regardless, copyright infringement might also be an issue.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#75Earlier quoted context omitted.
The drivers are probably pretty complicated and thus valuable IP.
I don't buy that. Every wifi chipset has working drivers; therefore there is little to no value in Broadcom's driver as "IP". Contrast that to the value of having a free driver that can receive security patches from anyone at any time .
Every existing Wi-Fi chipset has working drivers. A startup begins from scratch, which is one more barrier to entry.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#76Earlier quoted context omitted.
The drivers are probably pretty complicated and thus valuable IP.
I don't buy that. Every wifi chipset has working drivers; therefore there is little to no value in Broadcom's driver as "IP". Contrast that to the value of having a free driver that can receive security patches from anyone at any time .
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#77Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#78Earlier quoted context omitted.
I didn't want to suggest that iOS is insecure because Android systems are. For Android we know most of them are hopeless, on iOS it's security by obscurity all the way with just a generally good "track record". Well, they patched something. Maybe they just patched the firmware image that is loaded onto the chipset on boot and there was no privilege escalation onto the iOS application processor. But if there was, the…
> criminals can easily look at the patch to see what it was and exploit that while the public knows nothing. Huh? If criminals can “easily” inspect the patch, why can’t the public?
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#79Earlier quoted context omitted.
I didn't want to suggest that iOS is insecure because Android systems are. For Android we know most of them are hopeless, on iOS it's security by obscurity all the way with just a generally good "track record". Well, they patched something. Maybe they just patched the firmware image that is loaded onto the chipset on boot and there was no privilege escalation onto the iOS application processor. But if there was, the…
> criminals can easily look at the patch to see what it was and exploit that while the public knows nothing. Huh? If criminals can “easily” inspect the patch, why can’t the public?
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#80Earlier quoted context omitted.
Manufacturer: Device(S) BlackBerry: PRIV Fujitsu: F-01J General Mobile: GM5 Plus d, GM5 Plus, General Mobile 4G Dual, General Mobile 4G Gionee A1 Google: Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9 LGE: LG G6, V20, Stylo 2 V, GPAD 7.0 LTE Motorola: Moto Z, Moto Z Droid Oppo: CPH1613, CPH1605 Samsung: Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Ga…
Just a disclaimer, this isn't the complete list of devices that received the July 2017 update. I, for one, received it for my Moto G4 Play in Brazil. This list shows the models with a MAJORITY OF DEPLOYED DEVICES running a security update from the last two months.