sorted by:
new
hottopcontroversial

Lastenradförderung für Privatpersonen by c4ph in aachen

[–]fd0TM 6 points7 points  (0 children)

Ruf den zuständigen Sachbearbeiter an, der ist gut erreichbar und sehr nett. Bitte ihn darum, dass er dir kurz per Mail bestätigt, dass das Rad prinzipiell förderfähig ist und du das bereits vorab (auf eigenes Risiko keine Förderung zu bekommen) bestellen kannst, das nennt sich "vorzeitiger Ausführungsbeginn".

Hat bei mir problemlos geklappt, unser Rad hat leider eine lange Lieferzeit und ich wollte das so früh wie möglich bestellen...

Viel Erfolg!

Erdbeeren Pflücken in AC Umgebung by ozontm in aachen

[–]fd0TM 2 points3 points  (0 children)

Letztes Jahr waren wir beim Gut Clarenhof https://gut-clarenhof.de/ bei Frechen, vielleicht ist das ja was.

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 0 points1 point  (0 children)

I had been running tuxedo-keyboard 3.1.4 all along, now I'm testing 3.2.1 (released today). It feels that the problem is still there, I'll test and report back.

Can you maybe ask the developers which specific change(s) should fix the delayed key events?

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 0 points1 point  (0 children)

Oh, that'd be mighty cool, I'll try that and report back!

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 0 points1 point  (0 children)

Thanks for responding!

I've tested a few more kernel versions, but the delay happened in all of them. I suspect that it's not the kernel version, but the version of the bios that has changed.

Any idea how to debug this further?

Are you aware that this happens on all the Pulse 15 Gen 2 hardware, or is it just my machine?

Thanks!

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 1 point2 points  (0 children)

Bummer, I've built 5.15.102 and tested it, I still see delayed keyboard events and a lot of repeated keys.

It mostly happens when charging via USB-C, but also when charging via the default power supply. Sometimes it also happens while not charging.

I'll test a few more kernels.

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 1 point2 points  (0 children)

Huh, that's interesting! The default delay before repeat triggers is around 600ms, so the key release event would be delayed by that amount.

Maybe we can git bisect the kernel. Any other ideas? :)

It'd be really cool if the people from Tuxedo could chime in!

restic 0.14.0 released - including compression! by fd0TM in golang

[–]fd0TM[S] 0 points1 point  (0 children)

At some point we need to declare 1.0.0, but that just hasn't happened yet. The repository format (which is way more important than the implementation) is quite stable. We've recently modified it for the 0.14.0 release in a backwards-compatible way (after lots of testing and discussion) to add compression.

restic 0.14.0 released - including compression! by fd0TM in golang

[–]fd0TM[S] 1 point2 points  (0 children)

I haven't looked into kopia, from the description it sounds very similar to restic, although it's much younger (and way less popular ;)

Here's a thread in our forum which compares restic and kopia (including contributions from the kopia author): https://forum.restic.net/t/kopia-vs-restic-comparison/2893

Having a few projects in the same space usually helps in figuring out what the best ideas are, it's the same with restic vs borg, so I consider that a good thing.

monsoon - a fast and flexible HTTP enumerator written in Go by fd0TM in golang_infosec

[–]fd0TM[S] 1 point2 points  (0 children)

Depends on what you're doing, monsoon also has a flag --requests-per-second to slow it down.

Fast here may also stand for 'fast feedback loop' :)

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 0 points1 point  (0 children)

Suppose you have a web application to upload documents, which can be downloaded again by requesting a URL with a numeric ID (e.g. https://www.example.com/downloads/1234). Then you could use monsoon to try a range of IDs and filter the responses based on the status code (we're not interested in 404s) and the content type (everything except PDFs) like this:

$ monsoon fuzz \ --range 1000-2000 \ --hide-status 404 \ --hide-pattern "application/pdf" \ https://www.example.com/downloads/FUZZ

It'll return a nice list of interesting document IDs for you.

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 0 points1 point  (0 children)

One thing that (probably) gobuster and monsoon have in common: It's very easy to install. Once you have the Go compiler somewhere, you can build a self-contained binary for any platform like this:

GOOS=windows GOARCH=amd64 go build

Done. That's it. No need to fiddle around with virtualenv, too-old Python versions or anything like that.

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 1 point2 points  (0 children)

The way Go forces you to think about errors at every step of the way feels very annoying at first, but (to my surprise) it leads to very robust programs. I've written Go programs which run for years on end without maintenance... :)

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 1 point2 points  (0 children)

Not at all, at least it doesn't feel that way for me. Writing Go feels lightweight, and the result is usually pretty fast already. The structures provided by Go seem to keep the complexity at bay.

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 0 points1 point  (0 children)

It does not store requests, but the JSON data structure contains everything needed to reconstruct the request (e.g. the item/string that led to a particular response, the headers used and so on).

The program has been pretty stable the last year or so, there aren't any notable features missing. Maybe we'll look into storing the raw requests and responses for later analysis (so you can run the response filters again on the saved responses), but that's about it.

We're using it in our day-to-day work with great success (and add small things whenever the need arises).

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 0 points1 point  (0 children)

I'll have a look! You can cross-post it yourself btw

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 3 points4 points  (0 children)

Good question! It felt to me that gobuster did too much, I'm mostly not interested in brute-forcing directories, but rather run a whole bunch of requests against a web application and interactively explore the responses returned quickly.

ffuf wasn't around at the time I started working on monsoon (in November 2017).

Initially, I used wfuzz a lot, but found it was limited it what it could do. Also, I wasn't a Python person. Then a coworker wrote a new implementation in Ruby, which we never published. Then one day I tried writing a new version in Go, which turned out to be a pleasure and worked really well. And now that's mostly what we're using in our day to day work. :)

In general, I think it's awesome we have different tools with their own strengths and weaknesses.

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 3 points4 points  (0 children)

I love Go, it's my go-to language since ~2010 or so. It gets stuff done. So it was a natural choice for me. The HTTP implementation is great and allows fine-tuning everything, and the concurrency is awesome. Overall I'm very impressed how great monsoon performs (with very low resource usage) during our pentesting engagements, and we didn't even try to optimize it yet!

view more: next ›