News for hackers. Stuff that matters.
Re:Starlink terminal revision 4: overview and tests by sneak on Thursday February 29, 2024 @10:39AM (#39550795)
A faraday cage with a hole only big enough for an ethernet cable would almost certainly still block enough wifi that the signal would only be detectable for a few meters. Probably not very much would leak through the cable.

It would be dwarfed by the emanations from the, you know, space transmitter co-located with it. Locating the dish isn’t the issue, the proposal was using fiber to make the dish (detectable) and the operator (vulnerable) separated by distance.

Re:Starlink terminal revision 4: overview and tests by throwaway-571 on Thursday February 29, 2024 @11:23AM (#39551434)
They seemed to say that a special software hack was required to block the wifi, so i was wondering why the obvious physical hacks were not worth it.
Re:Starlink terminal revision 4: overview and tests by morphle on Thursday February 29, 2024 @11:45AM (#39551783)
There is more to it.

For example, do you trust SpaceX to not relay your location to your enemy? Do you want to broadcast your identity at all if there can be a man-in-the-middle-attack? A dozen other reasons....

Re:Starlink terminal revision 4: overview and tests by lxgr on Thursday February 29, 2024 @12:35PM (#39552427)
If you don't, should you be using a highly directional (Starlink achieves the capacity it does through spatial reuse allowed by directional antennas on both ends, so the satellites do need to know where you are pretty precisely), proprietary-hardware-requiring, inherently authenticated (for billing purposes), and generally very civilian focused satellite service?

A military service would probably use wider beams coming from the satellite, as well as different encryption (making it impossible to distinguish which terminal is being transmitted to on which beam and not using correlatable identifiers on unencrypted protocol layers at all).

Using civilian communications technology like cell phones has been a bad idea, as evidenced in the same conflict.

Re:Starlink terminal revision 4: overview and tests by morphle on Thursday February 29, 2024 @12:45PM (#39552540)
If you don't trust the software or the server, you can reflash the firmware and deploy the hardware in your own way, similar like we do with OpenWRT.

Use Starlink dishes as phased array point to point links across 500 km without the v2 Satellites?

There are 200 Ukrainian drone startups alone, many more in other countries. They all hack firmware. Hacker News readers should not be surprised.

Re:Starlink terminal revision 4: overview and tests by lxgr on Thursday February 29, 2024 @12:49PM (#39552583)
The problem isn't the firmware, it's the protocol.

If the protocol requires you to reveal your precise location to the network (so that satellite beams can correctly target you), how would you get around that using your own open firmware/hardware?

The same goes for authentication using (potentially) long-term stable or even public identifiers, as is the case for e.g. the IMSI with GSM (not sure if later 3GPP generations finally fixed that): A GSM network won't let you attach without revealing your IMSI over the radio interface at least once. You can spoof it, but then you won't get any service.

> Use Starlink dishes as phased array point to point links across 500 km without the v2 Satellites?

That's a completely different scenario than the one we're talking about here ("why can't military users relatively easily put some distance between the Starlink terminal and its users in a warzone?"), and one which I'd assume the military to have existing solutions for.

Re:Starlink terminal revision 4: overview and tests by morphle on Thursday February 29, 2024 @12:59PM (#39552712)
I was indeed referring to different scenario's at the same time