tecepe has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<cyrozap>
rqou, felix_: If you're interested in high-end (i.e., LTE) baseband hacking, the one in the MT6735 in the BLU R1 HD uses a Cortex-R4 and its source code has been leaked on GitHub.
<cyrozap>
felix_: also, if you want to RE wifi firmware, the recent abgn/ac stuff from Mediatek has a good GPL'd driver and very small firmware (~100k)
<rqou>
in the past Ralink/Mediatek wifi chips had crappy performance
<rqou>
there are too many crazy german hackers named felix :P
<cyrozap>
Apparently, he's not the same felix (thanks, /whois)
<cyrozap>
rqou: But anyways, that video I just posted is where I got this info from.
<cyrozap>
I mean, the stuff about the WiFi
<rqou>
i think i've seen the slide deck
<rqou>
at one point or another
<cyrozap>
No idea if performance is good
<rqou>
interesting thing re: FCC is that wifi bands overlap ham radio bands
<rqou>
so technically as long as I ID I can test whatever I want
<rqou>
except encryption
<cyrozap>
rqou: Or you could just keep your power low enough on any other band and no one will care :P
<rqou>
but I want to be that asshole using HT40 on 2.4GHz :P
<cyrozap>
By "low enough" I mean ~1mW or less and keep the devices right next to each other
<cyrozap>
HT40 on 2.4GHz isn't any good anyways because of the interference
<whitequark>
rqou: huh?
<whitequark>
aren't all WiFi bands ISM anyway?
<cyrozap>
rqou: I do OTA digital TV broadcasting with my bladeRF every so often and its output is low enough that it has incredible difficulty going through walls.
<whitequark>
and can't you do whatever the fuck you want on ISM bands as long as it's quiet enough?
<rqou>
i thought FCC Part 15 said that modifying transmitters is not allowed?
<cyrozap>
whitequark: Technically you still need a license, but yeah, just stay quiet and no one will bother you.
<whitequark>
huh
<rqou>
you can also build up to five devices of a particular design for personal use
<cyrozap>
whitequark: Sorry, I meant you need to certify your device
<rqou>
but i don't know of hacking firmware is included in that
<whitequark>
rqou: interesting
tecepe has joined ##openfpga
<rqou>
operating under FCC part 97 ham radio rules also allows stupid tricks like using channel -1
<rqou>
because the ham and ISM bands don't completely align
<rqou>
interestingly the JP-only channel 14 is still forbidden
<cyrozap>
rqou: The big things you don't want to interfere with are military/weather radar
<rqou>
you don't want your 5G WiFi making huge laserbeams appear on the local airport's weather radar? :P
<cyrozap>
Stay away from those and the likelihood of getting a letter/visit from the FCC party van are very small
<rqou>
whitequark: iirc HK actually has much stricter radio regulations but much more lax enforcement
<rqou>
aka no enforcement at all
<whitequark>
wonder if I could make a radar in the ISM part of the 5G band
<rqou>
i'm pretty sure hobbyists have done that
<whitequark>
there was like a single guy who made a SAR
<whitequark>
pretty advanced stuff imo
<cr1901_modern>
SAR?
<rqou>
synthetic aperture radar
<rqou>
*insert math here* :P
<rqou>
overall i'm quite disappointed how we don't have more harmonized band plans
<rqou>
the chaos of figuring out which frequencies are legal in which region is kinda silly
<whitequark>
yeah we need worldgov
<rqou>
i thought that was called the united states :P
<whitequark>
no thats the worldhell
<cr1901_modern>
Is there a difference?
<azonenberg>
whitequark: i am very interested in one day making a radar in a ham/ism band
<azonenberg>
i was thinking 5 or 10 ghz
<rqou>
er, according to arrl's chart pulse emissions are not allowed in 10ghz
<rqou>
i don't know if that will matter or not
<whitequark>
mmmhm
<whitequark>
maybe in extremely distant future
<azonenberg>
rqou: i forget if there's an ISM band there or not
<azonenberg>
You might also be able to cheat by making the pulses morse with your callsign or something :p
<azonenberg>
But 5G is an ISM band so you could avoid all the ham regs that way
<azonenberg>
if you stay w/i ISM power limits
<rqou>
wikipedia says there's no ism band at 10ghz
<rqou>
there is one at 5.8
<rqou>
there are ham bands in both
<rqou>
the 5.8ghz ham band does allow pulse emissions
<azonenberg>
oh interesting
<azonenberg>
So you could even do it in the ham bands if you could figure out a way to ID
<rqou>
probably
<rqou>
of all the 1GHz+ bands, only 10g doesn't allow pulse
<rqou>
i wonder why?
<azonenberg>
Alternating long and short pulses with your callsign in morse would probably be OK
<azonenberg>
Very curious
<rqou>
in general the ham band mode restrictions seem to be very curious legacy baggage
<rqou>
e.g. the arrl chart has a range in the 220mhz band labeled "Fixed digital message forwarding systems only"
<rqou>
50mhz and 144mhz have tiny CW-only ranges
<rqou>
there's also the weird channelized 5.3mhz band
<azonenberg>
rqou: the main ones that make sense are limiting bands w/ ionospheric propagation capability to higher class licenses
<azonenberg>
just b/c if you screw up you take out a lot more users
<rqou>
sure, but I don't really see the point of the split between "RTTY and data" vs "phone an image"
<rqou>
tl;dr he experiments with running 6khz ssb instead of the normal 3khz
<azonenberg>
i mean it'd be a bit of an a-holeish move if you were to transmit CD quality phone emissions with like 40 kHz b/w :p
<azonenberg>
Regardless of whether technically legal
<rqou>
sure, but that's covered by various good practice/don't be a dick provisions
<azonenberg>
i thought there was a clause in 97 saying that you couldn't use more bandwidth or power than reasonably necessary to accomplish a given communication though
<azonenberg>
so that might imply a de facto b/w limit
<rqou>
yes, so the guy argues that if you consider that the given communication is to send 6khz of audio bw, then you need 6khz ssb to do that
<rqou>
if you define the given communication to be only 3khz, then you only need 3khz
<rqou>
so you can really be an a-hole and fill an entire HF band with OFDM carriers
<azonenberg>
Lol
<rqou>
the HF bands are so narrow that you can probably even design a radio that floods multiple bands at once :P
<azonenberg>
So speaking of broadband stuff
<azonenberg>
I would love to build a wide b/w SDR for the ham bands
<azonenberg>
Something that can, for example, monitor the entire 2m band at once
<azonenberg>
with flags set on half a dozen local repeaters
<rqou>
doesn't that exist already?
<azonenberg>
and rather than scanning, actually mix the audio together
<azonenberg>
So it sounds like i have two radios in the room
<azonenberg>
then if i hear something i want to pay attention to on one or the other, just turn down the volume on one channel
<rqou>
wouldn't one of the problems with this be higher noise?
<azonenberg>
Dont know
<azonenberg>
I feel like you could probably reject noise pretty well if you had tone squelch
<azonenberg>
Speaking of which, if you had a good buffer
<azonenberg>
you could also do ex-post-facto tone squelch
<azonenberg>
basically add 100ms or so of latency to the signal and open the squelch as soon as the tone starts
<azonenberg>
even if it takes you 100ms to lock to it
<rqou>
trolling: the only reason this can't exist is because the old farts don't like computers :P
<azonenberg>
i think you're a lot less likely to notice a small lag in the signal than you are to notice the beginning of a signal getting chopped off
<azonenberg>
Which is what happens with TSQ now
<azonenberg>
since the squelch stays shut during the sync period
<rqou>
huh i never noticed that since i don't really operate at all :P
<azonenberg>
Another example of something you could do that might be useful (but would require a LOT more signal processing, probably a PC vs a HT - not a problem for HF bands that are typically big and not super mobile due to the antenna)
<azonenberg>
Simultaneously RX on say a HF band, local VHF repeater, and UHF simplex
<azonenberg>
silently
<azonenberg>
with speech recognition looking for your callsign in phone, plus some DSP looking for your call in morse
<azonenberg>
and if present, automatically open the squelch for that channel
<azonenberg>
or make a beep, or something
<rqou>
so one of my infinite pet projects is to duct tape the tegra x1 module thing along with a ham radio
<azonenberg>
kinda like an IRC highlight
<rqou>
that's probably powerful enough
<azonenberg>
while lurking in a dozen channels
<azonenberg>
could be quite useful esp in an emcom situation where you have a lot of different organizations you might be trying to keep tabs on
<rqou>
the reason i obtained the em7355 wwan module was actually to pair it with a tegra x1
<rqou>
but then i discovered that the pcie m.2 keying didn't match
<rqou>
and i haven't gotten around to spinning the adapter board yet
<rqou>
because the em7355 also gives you gps
<rqou>
offtopic: somebody should RE the tegra early boot code
<rqou>
the jetson tx1 is completely unfused so you actually can alter the early boot code
sharebrained has quit [Ping timeout: 260 seconds]
<rqou>
offtopic: is there a good debugger for linux that is well-suited for RE?
<rqou>
e.g. a linux clone of ollydbg?
m_w has joined ##openfpga
<whitequark>
lol
<whitequark>
expecting linux to have an usable debugger. so cute
<digshadow>
azonenberg: interesting
digshadow has quit [Ping timeout: 265 seconds]
sharebrained has joined ##openfpga
digshadow has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
<digshadow>
pointfree: hmm interesting. Have you used it / like it?
<pointfree>
digshadow: I haven't used it much yet. I discovered it recently.
<pointfree>
rqou: It looks like edb itself won't run on ARM, but debugging ARM executables (and others) should work because it now plugs into capstone.
<rqou>
oh interesting
<rqou>
that's all i really wanted anyways
<rqou>
just need to potentially duct tape in support for gdbserver
<rqou>
digshadow: C64 SID got vectorized? when?
<rqou>
i'm aware it was decapped a while back
massi has joined ##openfpga
<rqou>
didn't realize there was a full vector
Bike has quit [Quit: cyst]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
massi has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 244 seconds]
scrts has joined ##openfpga
<felix_>
cyrozap: no, thats not me; haven't made a talk at the big ccc conference yet
<felix_>
cyrozap: the lte chip i was poking was some qualcomm one which has an arm core and two hexagon cores
<felix_>
i also have some mediatek ac wlan card here, but it's 2x2 mimo only and iirc they don't have 3x3 mimo ones
<azonenberg>
i had to add some ignore properties for it to not think my antikernel repo was 98% kicad
<azonenberg>
b/c the graph is weighted by kB of each file type
<rqou>
i don't really care what this repo is detected as
<rqou>
"config files" isn't a really useful category
<azonenberg>
and kicad files were big vs source :p
<azonenberg>
yeah
<rqou>
anyways, i finally stopped procrastinating on my "how to configure postfix" article
<rqou>
it's already got 3k words
<rqou>
and it still hasn't started explaining in detail how stuff works in my configs
<rqou>
email is ridiculously hard
<azonenberg>
lol does it need to be?
<azonenberg>
like, not the current tools/protocols
<azonenberg>
is there an inherent reason why sending textual messages to a user is difficult?
<rqou>
yes, because exchange and lotus notes exist :P :P
<azonenberg>
among other things, i think we should remove the whole thing of relaying SMTP in a "mail v2" system
<azonenberg>
messages should be buffered clientside if the server is unreachable
<azonenberg>
and sent directly to the target user's mail server
<azonenberg>
We don't live in the dark ages where you'd go onlnie for an hour a day to move traffic
<azonenberg>
even if you're mobile, your mail server is likely online 24/7
<rqou>
but mail v2 still needs to have an x.400 bridge just for exchange :P :P
<azonenberg>
no, exchange needs to implement support for it :p
<azonenberg>
So rather than me connecting to some random smtp server my ISP runs, which later pushes stuff to gmail
<azonenberg>
i should just connect directly to incoming.gmail.com
<rqou>
like how they added smtp? i heard exchange basically still thinks in terms of x.400 internally
<azonenberg>
And the message should be signed with a certificate that proves it was sent from azonenberg@example.com
<rqou>
we haven't even gotten this part figured out for web pki, let alone email :P
<azonenberg>
(rather than me using user/pass login to the clientside mail server)
<azonenberg>
It's quite straightforward, i think
<azonenberg>
recipient's server verifies mail signature against my public key it has cached
<azonenberg>
If this is the first time i've sent mail to that domain recently, it asks my domain's mail server for my key
<azonenberg>
via a HTTPS GET request or something well defined, that returns a public signing cert
<rqou>
in theory this should be simple
<azonenberg>
If the message was signed by that cert, it trusts that I indeed originated the message and thus it's not spam
<rqou>
but what about silly footguns that appear everywhere
<azonenberg>
The sig doesnt even have to cover message content
<rqou>
like e.g. my email address has a "right-to-left embedding" in it :P
<azonenberg>
rqou: it's a sequence of bytes
<rqou>
this doesn't solve the phishing problem
<azonenberg>
in utf-8 or something
<azonenberg>
phishing is a human problem, not a protocol problem
<azonenberg>
i can phish someone by smoke signals
<azonenberg>
or do you mean email addresses that look identical but arent?
<rqou>
iirc there was some weird way that the bidi algorithm interacted with dots such that you could make fake file extensions
<rqou>
i presume you can use that to fake tlds as well
<azonenberg>
you could solve that *specific* issue by requiring the entire email be either rtl or ltr
<azonenberg>
the entire address*
<azonenberg>
But in general i think it's better solved by atuhenticating the user
<azonenberg>
not the address string
<rqou>
but then you can't have <something in hebrew>@latin-name.il
<azonenberg>
by means of pgp or something
<rqou>
authenticating users is even harder than authenticating addresses, isn't it?
<azonenberg>
So, there's a couple of problems
<azonenberg>
#1: verify the message came from a valid user at the sending domain (really only useful for anti-spam, like smtp auth now)
<azonenberg>
This can be solved by having a client cert that the sender's mail server supplies to anyone who asks
<azonenberg>
and signing outbound messages with it
<azonenberg>
So an incoming server will discard as spam anything not sent by a valid cert, you can then have blacklists of certs or domains that are known spammy
<azonenberg>
#2: verifying the message came from a specific user
<rqou>
how does this interact with the typical email monkey wrenches of mailing lists and forwarders?
<azonenberg>
Forwarder: strip existing sig, forwarding server re-signs with a cert of its own
<azonenberg>
after patching the source address
<azonenberg>
ditto for a mailing list, it re-signs the message with the listserv's signature
<azonenberg>
the goal here is not to auth the message to a specific account
<azonenberg>
only to auth that it came from someone that domain declared is a valid user
<azonenberg>
you can then decide via blacklists to trust that domain to make that declaration or not
<rqou>
i thought patching the source address was unpopular because (reasons I haven't fully researched)