ticoombs

joined 2 years ago
 

A nice in-depth article on game hacking

[–] ticoombs@reddthat.com 7 points 1 month ago

I'll be posting some of them which I find are interesting!

 

My talk explores the trajectory of iOS spyware from the initial discovery of Pegasus in 2016 to the latest cases in 2024.

The talk will start with an analysis how exploits, infection vectors and methods of commercial spyware on iOS have changed over time.

The second section of the talk is all about advances in detection methods and the forensic sources which are available to discover commercial spyware. This talk will also include a Case Study about the discovery and analysis of BlastPass (one of the latest NSO Exploits).

The third part will discuss technical challenges and limitations of the detections methods and data sources.

Finally, I will conclude the talk with open research topics and suggestions what Apple or we could technically do to make the detection of commercial spyware better.

The commercial spyware landscape on iOS has evolved significantly since the discovery of Pegasus in 2016. In this talk, we’ll explore that evolution through four main areas:

  1. Spyware Evolution (2016-2024): By analyzing key exploits, tactics, techniques, and procedures (TTPs), infection vectors, and indicators of compromise (IOCs), we’ll trace how spyware has advanced in sophistication, highlighting changes that have led to today’s complex threats.
  2. Advancements in Detection: As spyware has grown more sophisticated, so too have detection capabilities. We’ll review the main actors, public organizations and tools that have shaped spyware detection. This part will also include a case study on my discovery and analysis of a sample NSO‘s BlastPass Exploit chain.
  3. Current and Future Challenges: Looking forward, we’ll examine the pressing challenges in spyware detection and speculate on how commercial spyware might evolve in response to new security measures and technologies.
  4. Recommendations for Research and Detections: Finally, I’ll offer recommendations for advancing research and detection methods and capabilities to combat commercial spyware.

Attendees will gain a comprehensive view of the past, present, and future of spyware on iOS, along with actionable strategies for future research and collaboration.

Licensed to the public under http://creativecommons.org/licenses/by/4.0

33
submitted 1 month ago* (last edited 1 month ago) by ticoombs@reddthat.com to c/techsploits@reddthat.com
 

We present fatal security flaws in the HALFLOOP-24 encryption algorithm, which is used by the US military and NATO. HALFLOOP-24 was meant to safeguard the automatic link establishment protocol in high frequency radio, but our research demonstrates that merely two hours of intercepted radio traffic are sufficient to recover the secret key. In the talk, we start with the fundamentals of symmetric key cryptography before going into the details of high frequency radio, HALFLOOP-24, and the foundation of our attack.

High frequency (HF) radio, also known as shortwave radio, is commonly used by the military, other government agencies and industries that need highly robust long-distance communication without any external infrastructures. HF radio uses frequencies between 3 and 30 MHz. These frequencies enable skywave propagation, where the radio signals are reflected by electrically charged particles in the upper atmosphere. While this effect enables communication across very large distances, historically, it required trained and experienced operators to establish a radio link.

This dependence on operators was reduced by the introduction of the automatic link establishment (ALE) protocol. In a nutshell, an ALE-enabled radio establishes a link to another radio by selecting a suitable frequency according to a propagation model and then transmitting a call frame. If the frequency is good, the other radio receives the frame and the two radios perform a handshake to set up a link. The encryption of these ALE frames is known as linking protection. It is primarily meant to protect unauthorized users from establishing links with radios in a network or interfering with established links. Additionally, encryption of ALE frames also protects the network from certain types of traffic analysis, which is the analysis of operating data such as network structure, frequencies, callsigns and schedules. The first ALE standard did not specify a cipher, but specified how to integrate a stream cipher with ALE. Later standards introduced the 56-bit key Lattice/SoDark cipher, which is now recommended to be replaced with HALFLOOP whenever possible.

HALFLOOP, which is standardized in US standard MIL-STD-188-14D since 2017, is essentially a downscaled version of the Advanced Encryption Standard (AES), which effectively is the most used encryption algorithm today. While this downscaling led to many strong components in HALFLOOP, a fatal flaw in the handling of the so-called tweak enables devastating attacks. In a nutshell, by applying a technique known as differential cryptanalysis, an attacker can skip large parts of the encryption process. In turn, this makes it possible to extract the used secret key and hence enables an attacker to break the confidentiality of the ALE handshake messages and also makes an efficient denial-of-service attack possible.

These attacks are described in the two research papers, Breaking HALFLOOP-24 and Destroying HALFLOOP-24. They were initiated by the presentation of the Cryptanalysis of the SoDark Cipher, the predecessor of HALFLOOP.

Licensed to the public under http://creativecommons.org/licenses/by/4.0

[–] ticoombs@reddthat.com 12 points 2 months ago

Thank you for the update and it's good to hear your upcoming plans. Being one of those people in Australia (Reddthat) it will be good to see if it actually works as it's designed too!
I'd love to save $7/m to not have a server dedicated to batching the federation traffic 😅

When you lay out the timelines for 0.19.3 onwards no time at all has gone by, and having to deal with the issues after .3 has certainly not been fun as an admin. (And I'm only a small server compared!)
Being such a huge player in our Lemmyverse, thanks for taking the time to plan this out as I know how much testing has been done to get us this far.

It's always a nice experience chatting to the LW team!
Hope your updates go smoothly!

20
submitted 2 months ago* (last edited 2 months ago) by ticoombs@reddthat.com to c/techsploits@reddthat.com
 

Read the whole thread, great look at the original Pentium and some pretty pictures to match!

[–] ticoombs@reddthat.com 2 points 3 months ago

I too would love to know what your experiencing (so I can fix it!)

 

A nice in-depth post on the hardware too!

 

when someone opens up the hard drive of a redbox unit, they can pull a file which has a complete list of titles ever rented, and the email addresses of the people who rented them, and where and when

[–] ticoombs@reddthat.com 1 points 4 months ago* (last edited 4 months ago)

Article says the initial compromise of the non-airgapped systems is an unknown vector. So how they got into the organisation(s) in the first place is still a mystery

[–] ticoombs@reddthat.com 15 points 5 months ago

This is sso support as the client. So you could use any backend that supports the oauth backend (I assume, didn't look at it yet).

So you could use a forgejo instance, immediately making your git hosting instance a social platform, if you wanted.
Or use something as self hostable like hydra.

Or you can use the social platforms that already exist such as Google or Microsoft. Allowing faster onboarding to joining the fediverse. While allowing the issues that come with user creation to be passed onto a bigger player who already does verification. All of these features are up for your instance to decide on.
The best part, if you don't agree with what your instance decides on, you can migrate to one that has a policy that coincides with your values.

Hope that gives you an idea behind why this feature is warranted.

[–] ticoombs@reddthat.com 3 points 7 months ago

Yeah that's why I included the other "main posts"... Their technical details really didn't say anything technical

[–] ticoombs@reddthat.com 1 points 7 months ago

Ah. I see you too enjoy the debian approach

[–] ticoombs@reddthat.com 2 points 8 months ago (1 children)

Oh I was wrong, after further reading this looks to be a lot better than what I was thinking.

I must have been thinking about another methodology of attempted privacy over a dataset.

[–] ticoombs@reddthat.com 4 points 8 months ago (3 children)

Before I start reading, if this has anything to do with differential privacy, I'm going to be disappointed.

[–] ticoombs@reddthat.com 2 points 8 months ago

2nd best reporting in.

[–] ticoombs@reddthat.com 3 points 8 months ago* (last edited 8 months ago)

A faster db. Just the regular performance benefits, https://www.postgresql.org/about/news/postgresql-16-released-2715/

Also, Lemmy is built against v16 (now) so at some point it will eventually no longer JustWork

view more: next ›