Depends on the breadth of systems being targeted. If we exclude exotics (which have their own very vertical software and optimizations) it's really remarkable how uniform current platforms are. Everything from the ARM in a tablet to the 16 core desktop will have a pre-fetcher, multilevel cache, and a huge cost for missing. Simple things like grouping the frequently modified data together in a single allocation (like std:::vector) and then unifying those into more complex data structures by indexing into those vectors (maybe) can yield huge speedups across a wide range of hardware.
Even the 2000 core GPU in the same desktop will have similar concerns, even if not identical, and will often benefit from the same sort of thinking. As always, code and measure. People who have done so will tell you, it can be done, and it's not really hard.
As an exercise, name the systems where arranging data to not sit across a 64 byte boundary would be a horrible thing. Odds are if you're realistically targeting such a platform, being general purpose isn't a big deal.
I'm not talking about hand tuned assembly, I'm talking about being aware of your data layout and what data is hot, accessed together, and so on. Those things ARE a big deal and are commonly doable, even if they are commonly ignored. The famous case where Bjarne S had an associate demo a simple random data insertion/random deletion using a vector vs a list is simple but instructive.
Older systems and complexity theory might favor the list, but the vector beat it badly on modern hardware simply because the hot data is all together in a vector.
For all others it might not matter so much how the compiler and the OS handle memory allocations and the like, and it may be more useful to focus on the program structure instead of the implementation on the CPU.
With a cache miss costing 200 cycles (more or less) and a trip to L2 being more expensive than computing a square root, our choices with regard to memory layout are possibly MORE crucial now to getting decent economy and performance out of the machines we have today.
Research says this is one of many factors that taken together almost explain the "pay gap" away. It's not politically popular when research goes down this road though, or when anyone brings it up.
Size isn't the only thing, locality of reference is just as big or bigger and languages like C/C++ allow a programmer to think about and control such things. With everything being powered by batteries now being efficient isn't something we want to always just throw more hardware at, although such a phone might be more resistant to bending.
For me auto makes the code more readable and maintainable while retaining strong type safety; the type is retained and enforced, it's just determined by the compiler. Having both class and struct on the other hand always struck me as a pointless idea. Having no explicit return type default to int but no explicit argument default to void - also silly. But auto being re-purposed I'm OK with.
.... if the attacker knows the password hash that is not a dictionary attack.
The classic dictionary attack is to retrieve the list of password hashes and backwards compute to try and match common passwords to the known hashes, thus rendering a list of known passwords to use. The accounts are then compromised. Calling a modified brute force attack a dictionary attack is also common but a bastardization of the real thing.
Maybe you are thinking of a brute force attack? I don't see how a rate limit on the server is going to change the computation of a hash for comparison on the attackers machine.
Are you sure? A classic dictionary attack would hash all the words in the dictionary (or common password list) and then taking the known hash of the password, look up which common word computes to the same hash with the same (known) algorithm and salt.
Unless the firmware is copied to RAM at boot time and executes from RAM, and the dongle allows the added functionality to now be copied, maybe in that case it would be a circumvention of copyright protection.
I had a similar experience in the South China Sea a while back, the dive was fine but then inbound hurricane made getting back in the boat a chore; I got some really good bruises out of that one.
Except that only exceptional people are capable of performing many of the tasks that can't be effectively automated, so we are left with 99 people who are essentially incapable (or unwilling) to work and 1 guy who has to work like a horse to keep all the robots greased.
I doubt it - I suspect the CC merely has no way to reenter deauth without outside intervention; you'd probably need a non-malicious version of Rickmote to re-deauth it and have it ready to set up again.
"The MOS Technology "Agnus", usually called Agnus is an integrated circuit in the custom chipset of the Commodore Amiga computer. The Agnus, Denise and Paula chips collectively formed the OCS and ECS chipsets." - source
It's the chip that does memory access, fat agnus allows 1mb to be used for video and so forth, original agnus allowed access to 512k. I actually had to pull the old agnus out and insert the upgrade part in the 1980s.
I have an A2000 from back in the day, before the clones won the clone wars. Also a floppy based version of Dragons Lair for it. The Amiga was a wonderful machine.
Slashdot Mirror
Early detonation or disabling of the payload would probably still be useful .....
Depends on the breadth of systems being targeted. If we exclude exotics (which have their own very vertical software and optimizations) it's really remarkable how uniform current platforms are. Everything from the ARM in a tablet to the 16 core desktop will have a pre-fetcher, multilevel cache, and a huge cost for missing. Simple things like grouping the frequently modified data together in a single allocation (like std:::vector) and then unifying those into more complex data structures by indexing into those vectors (maybe) can yield huge speedups across a wide range of hardware.
Even the 2000 core GPU in the same desktop will have similar concerns, even if not identical, and will often benefit from the same sort of thinking. As always, code and measure. People who have done so will tell you, it can be done, and it's not really hard.
As an exercise, name the systems where arranging data to not sit across a 64 byte boundary would be a horrible thing. Odds are if you're realistically targeting such a platform, being general purpose isn't a big deal.
I'm not talking about hand tuned assembly, I'm talking about being aware of your data layout and what data is hot, accessed together, and so on. Those things ARE a big deal and are commonly doable, even if they are commonly ignored. The famous case where Bjarne S had an associate demo a simple random data insertion/random deletion using a vector vs a list is simple but instructive.
Older systems and complexity theory might favor the list, but the vector beat it badly on modern hardware simply because the hot data is all together in a vector.
For all others it might not matter so much how the compiler and the OS handle memory allocations and the like, and it may be more useful to focus on the program structure instead of the implementation on the CPU.
With a cache miss costing 200 cycles (more or less) and a trip to L2 being more expensive than computing a square root, our choices with regard to memory layout are possibly MORE crucial now to getting decent economy and performance out of the machines we have today.
More about the pitfalls of not managing your hot data.
Research says this is one of many factors that taken together almost explain the "pay gap" away. It's not politically popular when research goes down this road though, or when anyone brings it up.
More than 19 out of 20 people killed on the job in America are men - are we interested in squaring that up as well?
And a cache miss costs ~200 clock cycles.
Size isn't the only thing, locality of reference is just as big or bigger and languages like C/C++ allow a programmer to think about and control such things. With everything being powered by batteries now being efficient isn't something we want to always just throw more hardware at, although such a phone might be more resistant to bending.
Meanwhile I can put 500 miles worth of fuel in my car on almost any corner of the city in about 4 minutes.
For me auto makes the code more readable and maintainable while retaining strong type safety; the type is retained and enforced, it's just determined by the compiler. Having both class and struct on the other hand always struck me as a pointless idea. Having no explicit return type default to int but no explicit argument default to void - also silly. But auto being re-purposed I'm OK with.
How would you assign a lambda to a variable without auto?
.... if the attacker knows the password hash that is not a dictionary attack.
The classic dictionary attack is to retrieve the list of password hashes and backwards compute to try and match common passwords to the known hashes, thus rendering a list of known passwords to use. The accounts are then compromised. Calling a modified brute force attack a dictionary attack is also common but a bastardization of the real thing.
Maybe you are thinking of a brute force attack? I don't see how a rate limit on the server is going to change the computation of a hash for comparison on the attackers machine.
Are you sure? A classic dictionary attack would hash all the words in the dictionary (or common password list) and then taking the known hash of the password, look up which common word computes to the same hash with the same (known) algorithm and salt.
I don't see how that would work here.
Maybe you are thinking of a brute force attack?
Unless the firmware is copied to RAM at boot time and executes from RAM, and the dongle allows the added functionality to now be copied, maybe in that case it would be a circumvention of copyright protection.
Right - I was thinking Cairo
Was Chicago DOS or NT based? I forget.
Well if it's running Java then I am impressed. Then again maybe the GC was running for the duration of the storm, and not even Java could sink it.
I had a similar experience in the South China Sea a while back, the dive was fine but then inbound hurricane made getting back in the boat a chore; I got some really good bruises out of that one.
Except that only exceptional people are capable of performing many of the tasks that can't be effectively automated, so we are left with 99 people who are essentially incapable (or unwilling) to work and 1 guy who has to work like a horse to keep all the robots greased.
I read that RFID'd, and then I spent about 60 seconds wondering what those guys I Redmond had been up to. Then I calmed down and reread it.
I doubt it - I suspect the CC merely has no way to reenter deauth without outside intervention; you'd probably need a non-malicious version of Rickmote to re-deauth it and have it ready to set up again.
"The MOS Technology "Agnus", usually called Agnus is an integrated circuit in the custom chipset of the Commodore Amiga computer. The Agnus, Denise and Paula chips collectively formed the OCS and ECS chipsets." - source
It's the chip that does memory access, fat agnus allows 1mb to be used for video and so forth, original agnus allowed access to 512k. I actually had to pull the old agnus out and insert the upgrade part in the 1980s.
Yeah mine has 3mb and a couple SCSI drives, and fat aggie.
I have an A2000 from back in the day, before the clones won the clone wars. Also a floppy based version of Dragons Lair for it. The Amiga was a wonderful machine.