Notices by q3k :blobcatcoffee: (q3k@social.hackerspace.pl)

I don't know if this is CVE-2024-41585, but this is how I've been getting code exec on my DrayTek Vigor 167 for custom firmware [1] research:

https://gist.github.com/q3k/46f75dd78b653369640efaa2295f7ecd

I wouldn't say post-auth code execution on a device you own is a security vulnerability (good network hardware vendors just ship this as a feature), so I never bothered publishing this before.

This is so trivial I'm sure dozens of other people have been using this, too.

[1] - https://github.com/q3k/vraytekdigor .

✅ Attend a legal hearing about train hacking
✅ Wait for defense attorney stuck in train for hours because of a railway incident
✅ Get in a road collision on the way back from the court (we're fine)

certainly one of the most days

I'd attach Newag's logo to this post for illustrative purposes, but we don't want to be sued for that too. Instead I'm attaching a symbolic representation of their logo as drawn from my memory.

The hearing will take place in the 22nd Department of Intellectual Property at Czerniakowska 100 in Warsaw. To those interested are invited to observe on site as audience members, you can refer to the hearing number XXII GW 493/24. Of course, the hearing will be in Polish.

We would like to take this opportunity to thank everyone for the massive support we've received so far - especially to the Security Research Legal Defense Fund and other organizations that we're slowly organizing a crowdfunding campaign to cover our legal costs. But even more so, we'd like to thank each and every one of you who keeps reminding us that we're fighting the good fight. Finally, we want to especially thank our attorney, Zbigniew Krüger, who represents us in this bonkers lawsuit.

Just two days left until the first hearing in Newag's lawsuit against us (Dragon Sector members) and SPS. It will take place on 28.08.2024 at 10:00. In case you've missed it, we're being accused of infringing upon Newag's intellectual property and unfair competition. This is, of course, bullshit and a great example of a SLAPP case.

And yes, it's 164 pages (plus likely thousands of pages of attachments). Part of it is of course the inherent verbosity of court paperwork, part of it is also the fact that they repeat everything for each defendant (and that's three of us + SPS), but a significant cause of it is also that the lawsuit is just pure babble. Is it a case of SLAPP? Maybe, definitely feels like one to me.

We will of course fight this, and we're nowhere near being intimidated.

I originally tried to make an itemized list of their nonsense, but I ended up with 18 bullet points of bullshit that still made zero sense. It would be disrespectful to others to have them read that.

So instead of that, here's a symbolic picture of the lawsuit as a whole: them quoting my own code to me as supposedly their IP. :)

Serious talk though.

I think NEWAG is upset at us because it turns out a bunch of nerds is significantly better at public speaking and PR than anyone in their company that's paid to be good at this stuff.

@sos @siguza Thanksfully this isn't a legal text ready to be ratified, it's the outline of a petition that, if it gathers enough votes, enables the proposers to engage in a bilateral dialog with the EU commission.

There's no sense in nitpicking wording at this stage, as the intent is quite clear, especially if you've been following the campaign all along.

(see https://citizens-initiative.europa.eu/how-it-works_en )

@obot50549535 This is surface mount (QFN; edit: actually DFN). You can just reflow it.

If you're very bored (and hate yourself the exact right amount to do this without optical magnication), you can also dead bug it :).

Also this thing runs at 1.7V - 5.5V Vcc. Bonkers.

It's finally happened! NEWAG IP Management just sued us for copyright infringement and unfair competition. This is a civil lawsuit in Warsaw, parallel to a criminal investigation that's happening in Cracow.

Of course, they got our postal addresses wrong (they could've just asked!) so we only just got a copy from the court, but hey, we now have 164 pages of content to dive into.

@wolf480pl ... if only there was a universally present, globally unique identifier that could be used to track network devices across bus swaps!

@artemist @wolf480pl What I would like (and I don't mean to sound like some kind of RETVRN TO DEVUAN freak) is the oldschool way of using kernel enumeration as a base (eth0, eth1, usb0, etc), and then pinning it statefully to MAC in userspace.

I know it's not great for us NixOS folks, but there we could just declaratively pin interface names to MAC via nixos-generate-config. Effectively the same behaviour.

Systemd predictable network interface names are awesome.

Not only I get easy to remember names like enp2s0f0u7u3c2 but I _also_ get to experience a machine not coming back up after reboot because a new (non-NIC!) PCIe card caused existing names to shuffle around.

@NanoRaptor Mosquitoes now vomit blood instead of sucking it.

I would like to thank Jia Tan for authoring the best CTF challenge of the past decade.

@sirocyl Set that as an env var, run the payload and win a mystery prize!

I have managed to extract a list of encoded strings within the liblzma/xz backdoor payload (5.6.1):

https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01

The code has a dictionary of strings that are encoded as a prefix trie, which helps to keep things stealthy. This is eg. then used to look up symbols, eg. bd_elf_lookup_hash(..., 0x2b0, ...) means bd_elf_lookup_hash(..., "__libc_stack_end", ...). This is also why it's slow :).

This should bring us one step closer to knowing what the binary payload does.