x2q

bchunk — konverter .bin/.cue-images til .iso og .wav på Linux og macOS

2026-04-22T00:00:00+00:00

TL;DR —</strong> bchunk</code></strong> — også kaldet binchunker</code></strong> — er et lille, gammelt Unix-kommandolinjeværktøj, der tager et .bin</code>/.cue</code>-par (et råt cd-image med et cue-sheet) og deler det op i en rigtig .iso</code>-fil til datasporet</strong> og én .wav</code>-fil pr. lydspor</strong>. Det er det rigtige værktøj, når et download eller arkiv har givet dig game.bin</code> + game.cue</code>, og du faktisk vil mounte datasporet</strong> eller brænde lydsporene</strong> igen. Installeres med apt install bchunk</code> på Debian/Ubuntu, brew install bchunk</code> på macOS eller bygges fra kilden på alt andet. Brug er bchunk [options] image.bin image.cue basename</code> — du får basename01.iso</code>, basename02.wav</code>, basename03.wav</code> osv.</p>

Hvad .bin/.cue er, og hvorfor du vil splitte det</h2> Et .bin</code>/.cue</code>-par er et råt, bit-nøjagtigt cd-image</strong> plus et klartekst-sheet, der beskriver sporenes layout. .bin</code> indeholder hver sektor af cd’en i rækkefølge — inklusive datasport (Mode 1 eller Mode 2), lydspor (rå Red Book PCM, 2352 bytes pr. sektor, intet filsystem) og pauserne imellem dem. .cue</code> fortæller, hvor hvert spor begynder, og hvilken type det er.</p> Formatet er standard-output for cd-ripning-værktøjer som cdrdao og for gamle spil-arkiver, fordi det bevarer alt</em> — pregaps, CD-TEXT, mixed-mode-cd’er, CD-DA-lyd. Det er også grunden til, at du ikke bare kan omdøbe game.bin</code> til game.iso</code> og mounte det: en mixed-mode-cd har ikke-filsystem-sektorer</strong> i starten, lydspor der slet ikke er filsystem, og per-sektor-headers, som ISO forventer fjernet.</p> bchunk</code> laver konverteringen rigtigt:</p> Datasport</strong> bliver til ISO 9660-filer (.iso</code>) — 2352-byte cd-sektorer bliver trimmet til 2048-byte ISO-sektorer, headers smidt væk.</li> Lydspor</strong> bliver til 16-bit stereo 44,1 kHz .wav</code>-filer, hver med en ordentlig WAV-header.</li> </ul> Derefter kan du mount -o loop</code> .iso</code>’en, afspille .wav</code>’erne eller fodre dem til en brænder.</p> Installation</h2> Debian / Ubuntu / Mint</h3> sudo apt install bchunk </code></pre> macOS (Homebrew)</h3> brew install bchunk </code></pre> Arch / Manjaro</h3> sudo pacman -S bchunk # eller fra AUR: yay -S bchunk </code></pre> Fedora / RHEL / CentOS</h3> bchunk</code> er ikke i standard-repoet; hent det fra RPMFusion eller byg fra kilden:</p> git clone https://github.com/hessu/bchunk.git cd bchunk make sudo cp bchunk /usr/local/bin/ </code></pre> Windows</h3> Brug WSL og apt install bchunk</code>. Der findes en gammel native port, men WSL er nemmere.</p> Grundlæggende brug</h2> bchunk game.bin game.cue game </code></pre> Output:</p> game01.iso # datasport, mountbart som ISO 9660 game02.wav # lydspor 1 game03.wav # lydspor 2 ... </code></pre> basename</code> (game</code> i eksemplet) er præfikset for hver output-fil. Spornumre starter ved 01</code>.</p> Nyttige options</h2> bchunk</code> har et lille, stabilt sæt flag — de fleste er der for at håndtere specifikke cd-særheder.</p> -v</code></strong> — verbose. Printer hvert spor, efterhånden som det behandles. Brug den første gang, du kører det, for at bekræfte, at du får det sporlayout, du forventer.</li> -w</code></strong> — skriv .wav</code>-filer (default). Eksplicit form.</li> -r</code></strong> — rå lydoutput i stedet for .wav</code>. Nyttigt hvis du piper ind i sox</code> eller ffmpeg</code> og ikke vil have et ekstra header-skrællende skridt.</li> -p</code></strong> — Psx/PlayStation-mode</strong>. Behandler Mode 2-sektorer mere løst — nødvendigt for mange PlayStation-cd-images, hvor cue-sheetet er upræcist.</li> -s</code></strong> — byt byte-rækkefølge på lydspor. Nødvendigt hvis .bin</code>’en er produceret af en ripper, der skrev little-endian-lyd, hvor bchunk</code> forventer big-endian (eller omvendt). Symptom: output-.wav</code> lyder som hvid støj.</li> -W</code></strong> — skriv .wav</code> med en verificeret (i stedet for beregnet) header-størrelse. Sjældent nødvendigt.</li> -E</code></strong> — brug de nøjagtige spor-grænser fra cue-sheetet i stedet for at prøve sig frem. Brug dette hvis lydspor lyder klippet i starten eller slutningen.</li> </ul> Mount af den resulterende .iso</h2> På Linux:</p> sudo mkdir /mnt/cd sudo mount -o loop game01.iso /mnt/cd ls /mnt/cd </code></pre> På macOS:</p> hdiutil attach game01.iso </code></pre> Almindelige faldgruber</h2> “Illegal or unsupported track type” eller tomt output</h3> Dit cue-sheet er malformet eller refererer til en .bin</code>-størrelse, der ikke matcher. Åbn .cue</code>’en i en teksteditor — den er klartekst — og tjek:</p> FILE "..."</code>-linjen peger på det rigtige .bin</code>-filnavn, case-sensitivt.</li> TRACK</code>-entries er nummereret sekventielt med typerne MODE1/2352</code>, MODE2/2352</code> eller AUDIO</code>.</li> Index-entries (INDEX 00</code>, INDEX 01</code>) er MM:SS:FF, hvor FF er frames (0–74).</li> </ul> Lydspor lyder som statisk</h3> Byte-rækkefølge-mismatch. Prøv igen med -s</code>:</p> bchunk -s game.bin game.cue game </code></pre> Enkelt .iso</code> er fin, men lydspor er stille eller afkortede</h3> Prøv -E</code> for at tvinge cue-sheet-eksakte grænser:</p> bchunk -E game.bin game.cue game </code></pre> PlayStation/PSX-image splitter ikke rent</h3> Brug -p</code>:</p> bchunk -p psx.bin psx.cue psx </code></pre> Det er den mest almindelige klage på fora — PSX-cues er næsten altid Mode 2, og bchunk</code> uden -p</code> er streng overfor dem.</p> Flere .bin</code>-filer refereret i cue-sheetet</h3> Nogle rippere producerer én .bin</code> pr. spor plus et samlende cue-sheet. bchunk</code> forventer én .bin</code> for hele skiven. Concatener dem først med cat track01.bin track02.bin ... > combined.bin</code> og peg et single-file-cue på combined.bin</code>.</p> Alternativer værd at kende</h2> cdemu</code></strong> — user-space cd-emulator til Linux. Kan mounte en .bin</code>/.cue</code> direkte uden at splitte. Nyttigt, hvis du bare vil læse</em> datasporet midlertidigt.</li> ecm-tools</code></strong> — andet format (.ecm</code>), men samme problemområde. Værd at kende, hvis du støder på det.</li> 7z</code> / p7zip</code></strong> — nyere 7-Zip-versioner kan liste og uddrage ISO 9660-datasport fra en rå .bin</code>, men kan ikke redde lyd som .wav</code>.</li> ffmpeg</code></strong> — hvis du vil have MP3 / FLAC / Opus i stedet for .wav</code>, pipe rå-outputtet: bchunk -r game.bin game.cue game && ffmpeg -f s16be -ar 44100 -ac 2 -i game02.raw game02.flac</code>.</li> </ul> Hvorfor det stadig er nyttigt i 2026</h2> Optisk-medie-imaging har været et løst problem i årtier, men .bin</code>/.cue</code> er stadig default-output fra cdrdao</code>, stadig det gamle arkiver er lagret som, og stadig det, der dukker op, når nogen rækker dig en cd-backup, der ikke er en ISO. bchunk</code> er et ~1.000-liniers C-program, skrevet i sen-1990’erne, der gør ét job korrekt og knap har ændret sig i tyve år. Det er i alle store distributioner, det kompilerer rent på moderne systemer, og det er det rigtige værktøj.</p> Hvis du prøver at redde data fra et gammelt cd-image: start her.</p>

binlist.net — hvordan et ferie-sideprojekt fra Fuerteventura blev til iinlist.com 2026-04-22T00:00:00+00:00 TL;DR —</strong> binlist.net</a> er en gratis HTTP-API</strong>, der tager de første 6–8 cifre af et kortnummer (BIN</strong> eller IIN</strong>) og returnerer udsteder-bank, land, kort-netværk (Visa, Mastercard osv.), korttype (debit/credit/prepaid) og kategori. Jeg startede den i august 2013 på ferie på Fuerteventura</strong>, fordi jeg skulle bruge BIN-opslag til et andet projekt, og alt der fandtes var enten betalingspligtigt, forældet eller bag en tvivlsom scraper. Det var mit første Go-projekt nogensinde</strong>, ramte 100.000 queries/dag</strong> inden for uger og krydsede 1 million queries/dag i 2015</strong>. Den er stadig online, stadig gratis, stadig curl</code>-venlig. Den kommercielle variant, iinlist.com</a>, er den, jeg medstiftede efter binlist.nets succes; det er samme idé med betalingsindustri-præcision</strong>, 8-cifret IIN-understøttelse</strong> (påkrævet af ISO/IEC 7812 siden 2022), ARDEF-baserede ranges</strong> og en SLA — bygget til banker, PSP’er, fraud-teams og issuere, der har brug for at behandle BIN-data som produktions-data.</p> BIN vs IIN — et grundkursus på én paragraf</h2> De første seks (historisk) eller otte (siden 2017, obligatorisk fra 2022) cifre af et kortnummer er Issuer Identification Number</strong> (IIN). Det gamle navn, stadig vidt brugt, er Bank Identification Number</strong> (BIN). Givet en BIN/IIN kan du afgøre:</p> Netværk</strong> — Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners.</li> Udsteder</strong> — banken eller fintech’en, der udstedte kortet.</li> Land</strong> — udstederens land, ikke nødvendigvis kortholderens, men en nyttig proxy for risiko-scoring, skatte-logik (EU/EØS moms-OSS) og brugeroplevelse (foretrukket sprog, lokale betalingsmetoder).</li> Type</strong> — debit, credit, prepaid, deferred debit, charge.</li> Kategori / produkt</strong> — Classic, Gold, Platinum, Business, Corporate osv. Nyttigt til acceptance-cost-routing (erhvervskort koster mere at modtage).</li> </ul> Alt dette er “følsomt” i den forstand, at udstedere ikke offentliggør fulde BIN-tabeller, og kort-netværkene betragter dem som proprietære. I praksis lækker BIN-ranges konstant — hver autorisation, netværket router, hver chargeback-dispute — og der er en hel bibranche omkring at holde rimeligt præcise BIN-tabeller.</p> Hvorfor jeg byggede binlist.net på ferie</h2> Sommer 2013. Playitas, sydlige Fuerteventura</strong> — resortet på Atlanterhavs-siden nede ved Gran Tarajal. Lejet lejlighed, lille balkon, kanariefuglevinden gør sit. Jeg havde en idé til et sideprojekt, der skulle slå kort op via BIN, og jeg ville ikke betale en betalings-leverandør €200/md for det. De eksisterende gratis muligheder var:</p> Wikipedias IIN-liste</strong> — rimelig præcis for velkendte netværk, elendig dækning for niche-udstedere, opdateret af frivillige, der ikke arbejder i payments.</li> Indsatte CSV’er på fora</strong> — anstændig dækning for US-udstedere, altid forældet.</li> Google Fusion Tables</strong> — udfaset af Google samme år.</li> Scrapere af merchant-bankers opslagsformer</strong> — ToS-overtrædende, skrøbelige.</li> </ul> Det jeg ville have, var curl http://example.com/40012345</code> der returnerer ren JSON. Så jeg byggede det.</p> Stakken (dengang)</h3> Det var mit første Go-projekt nogensinde</strong>. Jeg havde læst om Go et stykke tid og ville have en lille, velafgrænset undskyldning for at prøve det; en single-endpoint JSON-API over en in-memory BIN-tabel var perfekt. Ruby/Sinatra ville have været hurtigere at taste for mig, men jeg ville lære noget, og memory- og latency-karakteristikken af en Go-binary viste sig at være præcis det, en gratis-tier offentlig API havde brug for.</p> Go</strong> — en enkelt binary, net/http</code>, ingen framework. Hele serveren fyldte nogle hundrede linjer.</li> In-memory BIN-range-tabel</strong>, bygget ved boot fra en ~300 MB kilde-fil. Opslag var O(log n) over et sorteret slice.</li> Deployet på én Hetzner-VM</strong> fra dag ét (jeg overvejede kortvarigt Heroku, men Heroku’s gratis dyno-memory-grænser kunne ikke rumme en fuldt indlæst BIN-tabel).</li> JSON + XML + CSV</strong>-svarformater, fordi 2013.</li> Dataseed</strong> fra en kombination af offentlige Wikipedia-scrapes, den gamle “Mars Base”-CSV fra 2009 og et sæt ranges, jeg havde akkumuleret på arbejde.</li> </ul> Samlet build-tid på den balkon: en weekend — hvoraf cirka halvdelen var mig, der fandt ud af go build</code>, GOPATH</code> (Go-moduler fandtes ikke endnu) og hvordan interfaces virkede. Jeg købte domænet mandag morgen, deployede binaryen og tweetede om det.</p> Trafik-kurven</h3> Uge 1:</strong> et par hundrede queries/dag, mest mig, der testede.</li> Måned 1:</strong> ~100.000 queries/dag</strong>, efter udviklere på Stack Overflow og et par e-handels-fora fandt den.</li> I begyndelsen af 2015:</strong> krydsede 1 million queries/dag</strong> vedholdende, med spikes over 2M under flash-sale-events hos merchants, der kaldte den på hver checkout-page-load.</li> </ul> At skalere til det punkt kostede næsten ingenting, fordi Go’s single-binary-fodaftryk betød, at en ~€5/md VPS klarede det hele; flaskehalsen var længe NIC’en, ikke CPU eller memory.</p> 13 år senere</h3> binlist.net kører stadig. Den er blevet flyttet infrastruktur nogle gange — Hetzner-VM → Hetzner-flåde → en lille flåde bag Cloudflare — og dataseed’et er blevet opdateret løbende, men API-overfladen (og det meste af den oprindelige Go-kode) er den samme. I dag serverer den titusinder af millioner opslag pr. måned</strong>, gratis, uden API-nøgle, med en soft-rate-limit på anonyme kaldere for at holde den ærlig.</p> Den har ~2.000 Google-visninger/md</strong> for queries som “binlist”, “bin list bank identification number”, “list of bank identification numbers” — den samler stadig den lange hale af udviklere op, der skriver samme spørgsmål, jeg skrev i Google i 2013.</p> Hvorfor iinlist.com findes</h2> binlist.nets data er god nok til “hvilket land er dette kort fra”-beslutninger — risiko-scoring, valuta-præsentation, analytics. Den er ikke</strong> god nok til:</p> Acceptance-cost-routing</strong>, hvor du router erhvervskorts-transaktioner gennem en anden processor.</li> Interchange++-modellering</strong>, hvor margin-forskellen mellem Classic og Platinum Mastercard er rigtige penge.</li> Compliance</strong> — ISO/IEC 7812-migrationen fra 6-cifrede BIN’er til 8-cifrede IIN’er, obligatorisk fra 2022, brød en masse “jeg bruger bare de første seks cifre”-logik.</li> Co-badged kort</strong> (f.eks. Dankort + Visa Debit), hvor to netværk begge hævder kortet, og routing-beslutningen er forretningskritisk.</li> ARDEF-præcision</strong> — Visas Account Range Definition File er sandhedskilden; du vil virkelig have data afledt af ARDEF til noget, der kører i produktion.</li> </ul> iinlist.com løser det, kommercielt. Jeg medstiftede den med et lille team af folk, der kender payments-data professionelt. Det er produktet, som binlist.net er gratis-tier-annoncen for. Nogle af vores kunder er navne, du ville genkende; de fleste er ikke. De kommer alle til samme konklusion: BIN-data der er “stort set rigtige” koster mere i forkerte beslutninger, end præcise data koster i licens-gebyr</strong>.</p> Hvad iinlist.com specifikt er</h3> 8-cifret IIN-understøttelse</strong> på tværs af alle netværk.</li> Daglige opdateringer</strong> afledt af ARDEF + netværks-feeds + udsteder-annonceringer + intern verificering.</li> Rigere enrichment</strong>: korttype, produkt-kategori, udsteder-land, udsteder-branding, regulatoriske klassifikationer (commercial vs consumer, prepaid-flag osv.).</li> SLA og support</strong>. Du kan oprette en ticket, og den når faktisk et menneske.</li> On-prem / self-hosted</strong>-mulighed for kunder, hvis compliance ikke tillader “BIN-opslag som tredjeparts-API-kald i autorisations-stien”.</li> Prissætning</strong> der giver mening for både en startende fintech (månedlig plan) og en etableret acquirer (årlig, ubegrænset).</li> </ul> Kan jeg bare bruge binlist.net kommercielt?</h2> Du kan bruge binlist.net, som du vil; der er ingen gate. Men:</p> Ingen SLA, ingen oppetidsgaranti, ingen kontrakt. Det er et sideprojekt, der er blevet oppe i 13 år.</li> Rate-limits på anonym trafik træder i kraft ved produktions-volumen. Køb en licens fra iinlist.com, og problemet er løst.</li> Hvis din regulator spørger, hvor dine BIN-data kommer fra, er “en gratis API, min udvikler fandt” ikke det svar, du vil give.</li> </ul> Til hobby, demo eller prototype: binlist.net er perfekt. Til alt, hvor forkerte BIN-data bliver en KPI: iinlist.com.</p> Brug af binlist.net i dag</h2> $ curl -sH "Accept-Version: 3" https://lookup.binlist.net/45717360 { "number": { "length": 16, "luhn": true }, "scheme": "visa", "type": "debit", "brand": "Visa/Dankort", "country": { "numeric": "208", "alpha2": "DK", "name": "Denmark", "emoji": "🇩🇰", "currency": "DKK", "latitude": 56, "longitude": 10 }, "bank": { "name": "Jyske Bank A/S", "url": "www.jyskebank.dk", "phone": "+4589893300", "city": "Silkeborg" } } </code></pre> Accept-Version: 3</code></strong> — pin’er til API v3.</li> Anonym rate-limit</strong> — dokumenteret på siden, rigeligt til almindelig brug.</li> Ingen garantier</strong> — hvis svaret er forkert, indsend en rettelse på GitHub-repoet. Til kommercielle garantier: se iinlist.com.</li> </ul> Ofte stillede spørgsmål</h2> Er BIN-/IIN-data reguleret?</h3> BIN-ranges i sig selv er ikke persondata under GDPR — en BIN identificerer en udsteder, ikke en person. Kombination af en BIN med et fuldt kortnummer er en anden historie og falder under PCI-DSS.</p> Hvad ændrede sig med 8-cifret IIN-migrationen?</h3> ISO/IEC 7812 formaliserede 8-cifrede IIN’er i 2017 med en hård migrations-deadline i april 2022 for de store netværk. Hvis din kode stadig behandler kun de første seks cifre som udsteder-identifikatoren, fejlrouter du lydløst en voksende del af din trafik — moderne Visa- og Mastercard-udsteder-ranges er defineret ved 8 cifre.</p> Hvorfor ikke bare slå op på klient-siden?</h3> Det kan du, med en statisk liste i browseren. Men du accepterer et trade-off: friskhed (den statiske liste er forældet inden for uger) eller bundle-størrelse (den nuværende BIN-tabel er megabytes ukomprimeret). En server-side-API er det konventionelle svar.</p> Logger binlist.net de BIN’er, jeg slår op?</h3> Kun aggregeret analytics — nok til at opdage misbrug og rate-limite. Enkelte opslag er ikke knyttet til en bruger. iinlist.com har en strammere no-logging-holdning til kunder, hvor det betyder noget.</p> Er kildekoden open source?</h3> API-overfladen af binlist.net er på GitHub med retningslinjer for data-rettelser. Data-ingestion-pipelinen er ikke open source; den afhænger af netværks-feeds, der kræver licenser.</p> Er binlist.net og iinlist.com samme firma?</h3> Adskilte projekter, overlappende oprindelse, samme operatør på min side. binlist.net er en personlig gratis-tjeneste; iinlist.com er et kommercielt selskab med medstiftere og medarbejdere. De to er driftsmæssigt uafhængige, men deler institutionel viden om BIN-data, som ikke er nem at akkumulere fra bunden.</p> Tretten år inde</h2> Det, jeg finder mest interessant ved binlist.net, er ikke trafikken — det er den slags spørgsmål</strong>, udviklere stadig skriver ind i Google i 2026: “what is a bin list”, “bin number example”, “list of issuer identification numbers”. Det er nøjagtig de queries, jeg skrev i 2013 på balkonen i Playitas. Payments som industri fortsætter med at tilføje lag, men de grundlæggende spørgsmål ændrer sig ikke.</p> Hvis du sidder på en strand med en laptop, og du har en kløe til et sideprojekt, der klør din egen ryg: byg det — og prøv imens det sprog, du har haft lyst til at lære. Nogle gange viser det sig, at mange har samme kløe, og tretten år senere har du en nyttig ting at pege dem på og et arbejdende kendskab til Go.</p> Mit CM3588-projekt — 4-NVMe ARM64 hjemme-NAS på 10 W tomgang 2026-04-22T00:00:00+00:00 TL;DR —</strong> FriendlyElec CM3588 NAS Kit</a> er et RK3588-baseret compute-modul på en carrier-board med fire M.2 NVMe-pladser (PCIe 3.0 x1 hver)</strong>, 2,5 GbE</strong>, 2× HDMI ud</strong>, USB 3.0</strong> og en 8-kernet ARMv8-CPU (4× Cortex-A76 + 4× Cortex-A55). Fuldt lastet med fire NVMe-drev går den i tomgang på ca. 10 W</strong>, peaker omkring 20 W under tung I/O, og læser/skriver en NVMe på ca. 1 GB/s (bus-grænsen, ikke drevet). Min egen kører Debian på mainline-kernel, med ZFS på root, fire 2 TB NVMe-drev i en raidz2</code>-pool, Samba til LAN-shares og Tailscale til adgang uden for LAN. Den har erstattet en tower-PC med TrueNAS og skåret NAS-strømforbruget med ca. 60 W.</p> Hvorfor netop dette board</h2> Jeg havde kørt en tower-PC som hjemme-NAS i årevis: en brugt desktop, seks 3,5“-harddiske og en støjende blæser. Det virkede, men den trak 70–80 W tomgang og stod i et skab, der skulle have aktiv udluftning. Harddiskene var højlydte nok til, at jeg havde flyttet dem til det fjerneste hjørne af huset.</p> Tre ting, jeg ville have af en afløser:</p> Kun NVMe.</strong> Roterende harddiske er billigere pr. terabyte, men støjen, vibrationen og varmen er ikke værd for et hjemme-NAS på nogle få terabyte. 4× 2 TB NVMe er rigeligt.</li> ARM, for strømforbrugets skyld.</strong> Et x86-board med 4× PCIe-pladser forbundet til NVMe ville trække 30–40 W tomgang. ARM kan klare det på 10.</li> Mainline Linux, ikke en leverandør-fork.</strong> Jeg vil have apt-get dist-upgrade</code> til at virke, zfs</code> til at bygge fra DKMS mod en nyere kernel og ingen tre år gammel vendor-BSP.</li> </ol> CM3588 NAS Kit rammer alle tre.</p> Hardware</h2> SoC:</strong> Rockchip RK3588 (4× Cortex-A76 @ 2,4 GHz + 4× Cortex-A55 @ 1,8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.</li> RAM:</strong> 8 GB LPDDR4X på det modul, jeg købte. 16 GB- og 32 GB-varianter findes.</li> Lagring:</strong> 64 GB eMMC on-module til OS + 4× M.2 Key-M 2280-pladser, hver PCIe Gen 3 x1</strong> (altså ~1 GB/s pr. plads, ikke x4).</li> Netværk:</strong> 1× 2,5 GbE (Realtek RTL8125B).</li> USB:</strong> 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.</li> Video:</strong> 2× HDMI ud, 1× HDMI ind</strong> (RK3588’s capture-blok).</li> Strøm:</strong> 12 V barrel-jack. Et 60 W-strømforsyning er mere end nok.</li> </ul> Boardet er lille — ca. 10 × 10 cm — og passivt over SoC’en plus en lille blæser, der blæser hen over NVMe-drevene. Mit står fladt på en hylde uden kabinet.</p> NVMe-kompatibilitetsadvarsel</h3> Den ene ting, der er værd at vide: CM3588 NAS Kit er ikke kompatibelt med visse WD Blue SN580- og WD Black SN850-drev</strong> — linket flapper ved boot. Jeg bruger Samsung 990 EVO og Crucial P3 Plus; begge virker fint. Tjek FriendlyElecs wiki-kompatibilitetsliste før du køber NVMe-drev.</p> OS og filsystem</h2> Jeg kører Debian 13 (trixie)</strong> med mainline-kernel</strong> — RK3588-understøttelse er god nok fra 6.8 og frem til headless-brug. FriendlyElecs Debian-image virker ud af boksen, men jeg geninstallerer ovenpå for at få et rent Debian i stedet for deres BSP.</p> Root-filsystem:</strong> ext4</code> på eMMC.</li> Datapool:</strong> zfs</code> raidz2</code> på tværs af de fire NVMe-drev. Med 4× 2 TB giver raidz2</code> ~3,5 TB brugbart med to-disks-redundans. Ja, raidz2</code> på fire drev er konservativt; det betyder også, at et dobbelt-svigt ikke spiser poolen, og på NVMe er rebuilden hurtig nok til, at jeg ikke mister nattesøvn over det.</li> ZFS-modul:</strong> DKMS mod den kørende kernel. Bygger automatisk ved kernel-opgraderinger. Har virket uden manuel indgriben på tværs af tre kernel-bumps.</li> ARC-tuning:</strong> Loftet ved 2 GB. Det giver headroom på et 8 GB-system.</li> </ul> Gennemløbet er flaskehals-begrænset af 2,5 GbE til netværks-I/O (~280 MB/s vedholdende), længe før ZFS eller NVMe-drevene kommer på arbejde. Lokale operationer på poolen når omkring 2 GB/s samlet sekventiel læsning.</p> Tjenester</h2> Bevidst holdt simpelt:</p> Samba</strong> til SMB-shares til Mac’erne og Windows-boksen på LAN’et.</li> rsync + cron</strong> til natlige backups fra tre andre maskiner.</li> ZFS-snapshots</strong> hver time, opbevares en uge. zfs send</code> piper datasættet ugentligt til en offsite B2-bucket via zfs-autobackup</code> + rclone.</li> Tailscale</strong> til adgang uden for LAN. Ingen port-forwarding, ingen dyndns, ingen VPN-koncentrator. SSH og Samba rider begge på Tailscale-interfacet, når jeg er væk.</li> Cockpit</strong> til det lejlighedsvise “hvorfor larmer blæseren” dashboard-øjeblik.</li> </ul> Det er alt. Ingen Docker swarm, ingen Kubernetes, ingen dusin sidecar-containere. Boardet har ét job — serve filer på LAN’et og lade mig trække backups offsite — og det gør det i stilhed.</p> Strøm og støj</h2> Tomgang</strong> (alle fire NVMe opspundne, ingen trafik): ~10 W</strong> ved stikkontakten.</li> Travlt</strong> (NVMe-læsning mætter 2,5 GbE, ZFS-ARC varm): ~18–20 W</strong>.</li> Peak</strong> (scrub af hele poolen, alle kerner varme): ~25 W</strong>.</li> </ul> Sammenlignet med den 70–80 W-tower, den afløste, er strøm-ROI’en alene omkring 500 kWh/år</strong>, eller cirka 1.500 kr/år</strong> ved danske privat-takster. Boardet betalte sig selv tilbage på ca. et år.</p> Støj: i praksis uhørlig fra mere end en meters afstand. Blæseren er lille, og 80 % af tiden kører den knap nok.</p> Hvad virkede ikke, eller tog arbejde</h2> Vendor-kernel.</strong> FriendlyElecs leverede kernel er deres fork af 6.1 med RK-specifikke patches. Det virker til deres nøglefærdige NAS-image, men DKMS-ZFS-builds er bøvlede mod den. Skiftet til mainline løste det.</li> HDMI-capture.</strong> RK3588 har en hardware HDMI-input-blok. I mainline er den stadig eksperimentel. Jeg har en vag brugscase for den (trække signal fra en gammel enhed til arkivering), men har ikke fået det til at virke end-to-end. Parkeret indtil videre.</li> NPU.</strong> De 6 TOPS NPU er underudnyttet. Mainline har basal RKNPU-understøttelse, men til noget praktisk skal du stadig bruge FriendlyElecs rknn-toolkit2</code>. Ikke et problem for et NAS.</li> </ul> Ofte stillede spørgsmål</h2> Hvorfor ikke x86?</h3> En x86-mini-PC med 4× NVMe er ~2× tomgangsstrømmen og ~2× købsprisen (når du tæller kabinet, PSU og CPU med). Til et hjemme-NAS, hvor arbejdsbyrden er “serve filer” snarere end “kør 40 containere”, vinder ARM.</p> Hvorfor ikke Raspberry Pi 5?</h3> Pi 5 har én PCIe 2.0 x1-lane eksponeret via en HAT — du kan bolte en NVMe på, men kun én, med loft ved ~500 MB/s. CM3588 har fire lanes ved PCIe 3.0 direkte forbundet. En anden klasse af board.</p> Hvorfor ikke OpenMediaVault eller TrueNAS?</h3> Begge ville virke. Jeg foretrækker rent Debian + Samba + ZFS, fordi opgraderingsstien for Debian er velkendt for mig, og OMV/TrueNAS er et lag, jeg skulle lære på ny. Det afhænger af dig.</p> Hvorfor raidz2</code> på fire drev og ikke mirror + mirror</code>?</h3> Overvejet. mirror + mirror</code> giver hurtigere skriv og lettere udvidelse, men kun 4 TB brugbart fra 4× 2 TB — det samme som raidz2</code>. Med raidz2</code> kan to vilkårlige drev svigte; med stripede mirrors kan du miste to drev, men kun hvis de er i forskellige mirror-par. På fire drev er kapaciteten identisk, og raidz2</code> har den stærkere fejltolerance.</p> Kan den køre Plex / Jellyfin?</h3> Ja, og RK3588’s hardware H.265/VP9/AV1-decode-blok klarer det tunge arbejde. Jellyfin med rkmpp</code>-accelereret decoding håndterer 4K HEVC-transcodes på omkring 3× realtid. Jeg kører ingen af delene på denne boks — min Plex bor et andet sted — men det er realistisk.</p> Går den i suspend?</h3> Ikke pålideligt. Lad den stå tændt; tomgang er alligevel 10 W.</p> Hvad med støj og varme om sommeren?</h3> Passivt køleplade plus en lille blæser. I en dansk sommer (20–25 °C i rummet) topper den omkring 55 °C die-temperatur under en ZFS-scrub. Ingen throttling målt.</p> Dom</h2> Hvis du vil have et lydsvagt, strømbesparende, ren-NVMe-hjemme-NAS med nok PCIe til at betyde noget</strong> og er villig til at bruge en aften på Debian + ZFS, er CM3588 NAS Kit den bedste mulighed, jeg har fundet. Det er ikke det billigste — en brugt Optiplex er billigere på forhånd — men på tre års TCO inkl. strøm betaler det sig tydeligt tilbage.</p> RK3588 i sig selv er en overraskende kapabel SoC til homelab-arbejdsbyrder. Da mainline-kernel-understøttelsen landede, holdt jeg op med at behandle den som “en ARM-kuriositet” og begyndte at behandle den som default-svar på små altid-tændte servere.</p> To år inde er min blevet genstartet to gange (en gang for en kernel-opgradering, en gang fordi jeg flyttede hylden). Jeg ville købe den igen.</p> pdfcrack — gendan glemte PDF-kodeord på Linux og macOS (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> pdfcrack</code></strong> er et kommandolinjeværktøj, der gendanner user-kodeordet</strong> eller owner-kodeordet</strong> på en krypteret PDF via brute-force eller dictionary-angreb. Det er lille, skrevet i C, kører på Linux/macOS/WSL og håndterer enhver krypterings-profil, PDF har leveret — 40-bit RC4, 128-bit RC4, 128-bit AES, 256-bit AES (PDF 1.7 + 2.0). Det er single-threaded og kun CPU</strong>, så det er hurtigt på den svage gamle RC4-40-kryptering, men stadig langsommere, efterhånden som PDF’er bliver moderne. Installeres med apt install pdfcrack</code> (Debian/Ubuntu), brew install pdfcrack</code> (macOS) eller bygges fra kilden. Når pdfcrack</code> er for langsom, så skift til pdf2john</code> + hashcat</code></strong> på en GPU.</p> Dette indlæg antager, at du har autorisation til at gendanne kodeordet</strong> på PDF’en — dit eget dokument, en kundes eller en lovligt anskaffet fil. Angrib ikke PDF’er, du ikke ejer.</p> User-kodeord vs owner-kodeord</h2> PDF har to kodeord:</p> User-kodeord</strong> — kræves for at åbne og læse</strong> dokumentet.</li> Owner-kodeord</strong> — kræves for at fjerne begrænsninger</strong> (print, kopi, rediger) på et dokument, der åbner uden et user-kodeord.</li> </ul> Mange “beskyttede” PDF’er er kun owner-kodeord-begrænsede: de åbner fint, men print og kopi er deaktiveret af læseren. Dem er trivielt at låse op — qpdf --decrypt</code> eller et hvilket som helst pdftk</code>-lignende værktøj fjerner owner-only-restriktioner uden at skulle gætte noget. pdfcrack</code> er til det sværere tilfælde: en user-kodeord-beskyttet PDF, du slet ikke kan åbne</strong>.</p> Tjek hvilken du har med at gøre:</p> $ qpdf --show-encryption dokument.pdf R = 6 P = -3904 User password = Supplied password is owner password extract for accessibility: allowed extract for any purpose: not allowed print low resolution: allowed print high resolution: not allowed modify document assembly: not allowed modify forms: not allowed modify annotations: not allowed modify other: not allowed stream encryption method: AESv3 string encryption method: AESv3 file encryption method: AESv3 </code></pre> R = ...</code></strong> fortæller dig revisionen/profilen. R=2</code> = RC4-40, R=3</code> = RC4-128, R=4</code> = AES-128, R=5/6</code> = AES-256.</li> “Supplied password is owner password”</strong> + “User password = (tom)” betyder, du kan åbne den og bare skal fjerne restriktioner. Brug qpdf --decrypt --password='' input.pdf output.pdf</code>, og du er færdig.</li> </ul> Installation</h2> # Debian / Ubuntu / Mint / Kali sudo apt install pdfcrack # macOS (Homebrew) brew install pdfcrack # Arch / Manjaro sudo pacman -S pdfcrack # Fedora / RHEL sudo dnf install pdfcrack # Fra kilden wget https://sourceforge.net/projects/pdfcrack/files/latest/download -O pdfcrack.tar.gz tar xf pdfcrack.tar.gz && cd pdfcrack-* make sudo cp pdfcrack /usr/local/bin/ </code></pre> Benchmark</h2> $ pdfcrack -b Benchmark: Average Speed (calls / second): MD5: 1728972.6 MD5_50 (fast): 97879.3 MD5_50 (slow): 69167.0 RC4 (40, static): 606555.3 RC4 (40, no check): 598050.0 RC4 (128, no check): 590141.7 Benchmark: Average Speed (passwords / second): PDF (40, user): 453510.2 PDF (40, owner): 220250.0 PDF (40, owner, fast): 499995.0 PDF (128, user): 22000.0 PDF (128, owner): 10408.7 PDF (128, owner, fast): 22220.0 </code></pre> Oversat:</p> RC4-40</strong> (PDF 1.3, meget gammel) — ~450k kodeord/sek. Brute-force af et fuldt 8-tegns alfanumerisk space: ~1 uge på én core.</li> RC4-128 / AES-128</strong> — ~22k kodeord/sek. Brute-force bliver urealistisk over længde 6 med et hvilket som helst charset.</li> AES-256 (R=5/6)</strong> — endnu langsommere; pdfcrack</code> understøtter det, men reelt kun til dictionary-angreb mod små ordlister.</li> </ul> Har du brug for mere fart end det, så vil du bruge hashcat</code> på en GPU. Tal i bunden.</p> Dictionary-angreb</h2> pdfcrack -f dokument.pdf -w /usr/share/wordlists/rockyou.txt </code></pre> -f</code></strong> — målfil.</li> -w <fil></code></strong> — ordliste, én kandidat pr. linje.</li> Valgfri -o</code></strong> — angrib kun owner-kodeord (ignorer user-kodeord). Default er at prøve user-kodeord først.</li> Valgfri -u</code></strong> — angrib kun user-kodeord.</li> </ul> Har du kontekst — kodeordet er sandsynligvis et fornavn, et årstal, en projektkode — saml en mindre målrettet liste. Generiske lister er en lang skud, når du er forbi top ti tusind indgange.</p> Brute-force-angreb</h2> pdfcrack -f dokument.pdf -c 'abcdefghijklmnopqrstuvwxyz0123456789' -n 4 -m 8 </code></pre> -c <charset></code></strong> — tegnsæt at prøve. Default inkluderer et bredt ASCII-område.</li> -n <min></code></strong> — minimumslængde.</li> -m <max></code></strong> — maksimumslængde.</li> </ul> Juster -c</code> aggressivt. Ved du, at kodeordet er alt-lowercase, så giv det ikke uppercase. Ved du, det har et ciffer til sidst, så brug et mask-angreb (hashcat-territorium, ikke pdfcrack).</p> Genoptag et langt kørsel</h2> pdfcrack -f dokument.pdf -w rockyou.txt -s /tmp/state.sav </code></pre> -s</code> skriver periodiske save-filer; hvis du stopper pdfcrack og genstarter, så giv -l /tmp/state.sav</code> for at genoptage.</p> Hvornår du skal skifte til hashcat</h2> Til enhver moderne PDF (R=4, 5 eller 6 — altså AES-128 eller AES-256) bliver pdfcrack</code>s single-core-fart flaskehalsen. pdf2john</code> + hashcat</code> giver dig to til tre størrelsesordener mere throughput på en GPU.</p> Trin 1: træk hashen ud</h3> $ /usr/share/john/pdf2john.pl dokument.pdf > hash.txt </code></pre> (På Debian/Ubuntu: apt install john</code> leverer pdf2john.pl</code>.)</p> Trin 2: identificér hash-mode</h3> $ head -1 hash.txt dokument.pdf:$pdf$5*6*256*-1028*1*16*... </code></pre> Map de første to tal:</p> $pdf$1*2*...</code> → mode 10400</strong> (PDF 1.1–1.3, RC4-40, user)</li> $pdf$1*2*...</code> med owner-salt → mode 10410 / 10420</strong></li> $pdf$2*3*...</code> → mode 10500</strong> (PDF 1.4–1.6, RC4-128 / AES-128)</li> $pdf$5*5*...</code> → mode 10600</strong> (PDF 1.7 r=5, AES-256)</li> $pdf$5*6*...</code> → mode 10700</strong> (PDF 1.7 r=6 / PDF 2.0, AES-256 med PBKDF2)</li> </ul> Trin 3: kør hashcat</h3> hashcat -m 10700 hash.txt /sti/til/ordliste.txt </code></pre> På en enkelt moderne GPU (fx RTX 4090):</p> Mode 10400 (RC4-40):</strong> ~10 milliarder H/s — ethvert praktisk kodeord gendannes øjeblikkeligt.</li> Mode 10500 (RC4-128 / AES-128):</strong> ~100 millioner H/s.</li> Mode 10700 (AES-256, PBKDF2):</strong> ~50.000 H/s. Det er ved design — PBKDF2-iterationerne gør brute-force dyrt.</li> </ul> For mode 10700 betyder din angrebsstrategi mere end rå fart. Dictionary + regler + mask-angreb målrettet mod sandsynlige kodeord-mønstre er størrelsesordener mere produktive end udtømmende brute-force.</p> Almindelige faldgruber</h2> “Filen ser ud til at være krypteret, men jeg kan åbne den uden kodeord”</h3> Du ser på owner-only-restriktioner. Brug qpdf --decrypt input.pdf output.pdf</code> — ingen cracking nødvendigt.</p> pdfcrack kører, men finder aldrig noget</h3> Tre sandsynlige årsager:</p> Kodeordet er længere / mere komplekst, end dit charset × længde dækker.</strong> Øg -m</code> og/eller udvid -c</code>, eller skift til en dictionary.</li> Kodeordet indeholder ikke-ASCII-tegn.</strong> pdfcracks charset er ASCII som default; ikke-ASCII-user-kodeord i gamle PDF’er brugte varierende encodings (PDFDocEncoding, UTF-16). Prøv pdf2john</code> + hashcat, som håndterer encoding’en korrekt.</li> Det er AES-256 (R=6), og du er tålmodig.</strong> Se hastighedsnoterne ovenfor — kun realistisk med en dictionary.</li> </ol> “Only AES-256 is supported”-fejl eller lignende</h3> Din pdfcrack</code>-build er gammel. Ubuntu LTS leverer nogle gange en version, der ikke fuldt håndterer R=6. Byg fra kilden eller skift til pdf2john</code> + hashcat</code>.</p> PDF’en åbner, men print/kopi er blokeret</h3> Det er kun owner-kodeord-begrænset. qpdf --decrypt</code> uden at behøve et kodeord virker som regel:</p> qpdf --decrypt --password='' input.pdf output.pdf </code></pre> Defensiv pointe</h2> Til alt, du vil have til at forblive krypteret i 2026, brug AES-256 med en PDF 2.0 (R=6) kodeord</strong>. Det er profilen med PBKDF2-nøgle-afledning, der gør offline-angreb dyre på nuværende hardware.</p> Og som altid betyder kodeordets længde mere end noget andet. En 20-tegns tilfældig passphrase er brute-force-intraktabel mod enhver nuværende GPU. Et 6-tegns “smart substitutions”-kodeord er en kaffepause på en RTX 4090.</p> Ofte stillede spørgsmål</h2> Er pdfcrack stadig vedligeholdt?</h3> Opdateres langsomt. Kodebasen håndterer alle nuværende PDF-krypterings-profiler; det er bare ikke her, performance-arbejdet foregår længere (det er hashcat).</p> Bruger pdfcrack GPU?</h3> Nej. Kun CPU, single-threaded. Til GPU-arbejde, brug pdf2john</code> + hashcat</code>.</p> Kan pdfcrack gendanne dokumentet, hvis skaberen ryddede user-kodeordet, men beholdt owner-kodeordet?</h3> Ja — brug qpdf --decrypt</code> først; hvis det ikke fuldt dekrypterer, angriber pdfcrack -o</code> owner-kodeordet.</p> Lækker pdfcrack min PDF nogle steder?</h3> Nej. Den er lokal. Alt online-only (“crack min PDF på cloud-service-X.com”) indebærer at uploade filen, hvilket du ikke skal gøre for fortroligt materiale.</p> Hvad hvis jeg kun vagt husker kodeordet?</h3> Skriv ned, hvad du husker — sandsynlige ord, sandsynlige cifre, sandsynlig længde — og byg en målrettet ordliste eller et hashcat</code>-mask (-a 3 ?l?l?l?l?l?d?d?d?d</code>). Det slår enhver generisk liste.</p> Kan jeg gendanne tekst fra en AES-256-PDF uden kodeordet?</h3> Nej. AES-256 med PBKDF2 (R=6) er, så vidt offentlig kryptanalyse går, ikke brudt. Hvis kodeordet er stærkt og tabt, er indholdet tabt.</p> Opsummering</h2> Kun owner-kodeord?</strong> qpdf --decrypt</code>, ingen cracking nødvendigt.</li> User-kodeord-beskyttet, gammel (R=2/3)?</strong> pdfcrack</code> med en dictionary virker fint.</li> Moderne (R=4/5/6)?</strong> pdf2john</code> + hashcat</code> på en GPU, målrettet angreb.</li> Stærk 20-tegns tilfældig?</strong> Accepter tabet.</li> </ul> fcrackzip — gendan glemte zip-kodeord på Linux, macOS og Windows (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> fcrackzip</code></strong> er et gratis, open-source kommandolinjeværktøj til at gendanne kodeordet på en krypteret .zip</code>-fil. Det understøtter brute-force</strong> (over et bruger-defineret charset og længde) og dictionary</strong>-angreb, virker på Linux/macOS/WSL, og er det rigtige første værktøj, når du skal gendanne et glemt kodeord på en zip, du lovligt ejer. Det er kun hurtigt mod klassisk ZipCrypto</strong>-kryptering; til den nyere AES-256</strong>-zip-profil virker fcrackzip</code> ikke — så skal du bruge zip2john</code> + hashcat</code> i stedet. Installeres med apt install fcrackzip</code> (Debian/Ubuntu), brew install fcrackzip</code> (macOS) eller bygges fra kilden.</p> Dette indlæg går gennem de praktiske tilfælde. Det antager, at du har autorisation til at gendanne kodeordet</strong> — dine egne filer, en kundes, en CTF. Brug det ikke på zips, du ikke ejer.</p> Installation</h2> # Debian / Ubuntu / Mint / Kali sudo apt install fcrackzip # macOS (Homebrew) brew install fcrackzip # Arch / Manjaro sudo pacman -S fcrackzip # Windows # Brug WSL2 + Ubuntu og `apt install fcrackzip`. # En native .exe findes, men er gammel — WSL er simplere. # Fra kilden git clone https://github.com/hyc/fcrackzip.git cd fcrackzip && ./configure && make sudo cp fcrackzip /usr/local/bin/ </code></pre> Tjek først, hvilken kryptering din zip bruger</h2> fcrackzip</code> håndterer kun klassisk ZipCrypto</strong> (den originale, svage PKZIP-kryptering). Til moderne AES-128 / AES-256</strong>-zips (introduceret af WinZip 9 i 2003, nu default i nogle værktøjer) vil fcrackzip</code> lydløst fejle i at finde kodeordet, uanset hvor længe du lader det køre.</p> Hurtigste tjek med zipinfo</code>:</p> $ zipinfo -v arkiv.zip | head -40 </code></pre> Led efter WinZip AES encryption, strength 3</code> (= AES-256). Ser du det, så spring til hashcat-sektionen.</p> Eller med 7z</code>:</p> $ 7z l -slt arkiv.zip | grep -i 'method\|encrypted' Method = ZipCrypto Store ← fcrackzip virker Method = AES-256 Deflate ← fcrackzip virker IKKE </code></pre> Grundlæggende brute-force</h2> fcrackzip -v -b -c 'a1' -p aaaa -u arkiv.zip </code></pre> -v</code></strong> — verbose.</li> -b</code></strong> — brute-force-mode.</li> -c 'a1'</code></strong> — charset. a</code> = små bogstaver a–z</code>, A</code> = store, 1</code> = cifre, !</code> = printbare symboler. Kombiner: 'aA1!'</code> = alt printbart ASCII (94 tegn).</li> -p aaaa</code></strong> — start-kodeord (definerer minimum-længde = 4 her).</li> -u</code></strong> — rapporterer kun, hvis den dekrypterede fil “unzipper” rent (filtrerer falske positive — ZipCrypto har en lille CRC, som mange tilfældige kodeord passerer).</li> </ul> Længde: -p aaaaa</code> starter ved 5 tegn. fcrackzip</code> har ikke et --max-length</code>-flag; det inkrementerer start-kodeordet gennem charsettet uendeligt, så at lade det køre til “færdigt” ved længde 8 på det fulde printbare ASCII-charset er ca. 94⁸ ≈ 6×10¹⁵ kandidater</strong> — ikke realistisk. Du afgrænser angrebet ved at vælge et rimeligt max charset + længde eller ved at bruge en dictionary.</p> Dictionary-angreb</h2> fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt arkiv.zip </code></pre> -D</code></strong> — dictionary-mode.</li> -p <fil></code></strong> — ordliste-fil, én kandidat pr. linje.</li> -u</code></strong> — verificér via unzip, som før.</li> </ul> rockyou.txt</code> er den standard 14 M-indgange-ordliste, der leveres med Kali og er tilgængelig overalt. Har du kontekst om kodeordet (det er nogens navn + årstal, det er et projektkodenavn), så saml en mindre målrettet ordliste — hit-raterne er som regel meget højere end med en generisk liste.</p> Hastighed og hvad du kan forvente</h2> fcrackzip</code> er single-threaded og CPU-bundet. På en moderne laptop ser du groft:</p> 10–30 millioner ZipCrypto-forsøg pr. sekund pr. core</strong> for et dictionary-angreb mod en typisk zip.</li> Brute-force en anelse hurtigere pga. mindre streng-I/O.</li> </ul> Det gør den fin til:</p> Dictionary-angreb</strong> mod en hvilken som helst rimelig ordliste.</li> Kort brute-force</strong> (4–6 tegn alfanumerisk).</li> </ul> Det gør den uegnet til:</p> Længde 8+ med symboler</strong> — du når aldrig i mål.</li> AES-256-zips</strong> — forkert værktøj.</li> </ul> Hvornår du skal skifte til hashcat</h2> Hvis fcrackzip</code> er for langsom, eller zip’en er AES-krypteret, så gå over til hashcat</code>. Det er det general-purpose kodeord-cracking-værktøj, GPU-accelereret, og håndterer både ZipCrypto og AES-WinZip-hashes.</p> Trin 1: træk hashen ud med zip2john</code></h3> zip2john</code> er en del af John the Ripper. Ubuntu: apt install john</code>.</p> $ zip2john arkiv.zip > hash.txt $ cat hash.txt arkiv.zip:$zip2$*0*3*0*...*$/zip2$::arkiv.zip:hemmelig.pdf:/sti/til/arkiv.zip </code></pre> Trin 2: fodr den til hashcat</h3> # ZipCrypto (mode 17200, 17210, 17220, 17225 afhængigt af komprimering) hashcat -m 17200 hash.txt /sti/til/ordliste.txt # AES-krypteret WinZip (mode 13600) hashcat -m 13600 hash.txt /sti/til/ordliste.txt </code></pre> På en enkelt moderne diskret GPU (fx RTX 4090) ser du:</p> ZipCrypto: ~5–10 milliarder H/s</strong></li> WinZip AES-256: ~10–50 millioner H/s</strong> (meget langsommere, fordi AES er dyrt, og der er PBKDF2-iterationer involveret)</li> </ul> hashcats rule-engine, mask-angreb (-a 3</code>) og combinator-mode (-a 1</code>) gør den massivt mere fleksibel end fcrackzip</code>. Til alt ikke-trivielt er den det rigtige værktøj.</p> Almindelige faldgruber</h2> “PASSWORD FOUND!!!!: pw == abc”, men unzip</code> beder stadig om et kodeord</h3> Du brugte ikke -u</code>. fcrackzips CRC-tjek har falske positive. Kør igen med -u</code> for at verificere kandidater mod et rigtigt dekomprimerings-forsøg.</p> Forskellige filer i samme zip har forskellige kodeord</h3> Klassisk PKZIP understøtter per-fil-kodeord. fcrackzip</code> angriber én fil ad gangen; giv -l <filnavn></code> (eller lad den vælge den første krypterede) hvis du skal være specifik.</p> fcrackzip finder kodeordet, men jeg kan stadig ikke unzippe</h3> Charset/locale-problem. Hvis kodeordet indeholder ikke-ASCII-tegn, har zip’ens skaber måske brugt en anden encoding end din terminal. Prøv unzip -P "$(echo -n 'passwd' | iconv -t cp437)" arkiv.zip</code>.</p> AES-krypteret, og dictionary finder det ikke</h3> hashcat + regler + en målrettet ordliste er løsningen. Se migrations-trinnene ovenfor.</p> Defensiv pointe</h2> Hvis du laver zip-filer, der skal forblive krypterede: brug AES-256</strong>, ikke ZipCrypto. De fleste moderne værktøjer (7z</code>, zip</code> fra InfoZIP med -e</code>, WinZip, Keka) giver dig AES, hvis du beder om det. Default på zip</code> er desværre stadig ZipCrypto på mange systemer. Tjek med 7z l -slt arkiv.zip</code> før du sender den afsted.</p> Og vælg et kodeord med længde, ikke smarthed. hashcat</code> er ligeglad med, hvor mærkeligt dit substitutions-mønster er; det handler kun om entropi. En fire-ords passphrase (correct-horse-battery-staple</code>-stil, ~44 bit) er fin mod offline ZipCrypto-angreb; et tilfældigt 12-tegns blandet kodeord (~78 bit) er fint mod GPU-AES-angreb. Alt kortere er genvindbart.</p> Ofte stillede spørgsmål</h2> Er fcrackzip lovligt?</h3> At gendanne kodeord på filer du ejer eller har autorisation til at tilgå, er lovligt i alle jurisdiktioner, jeg kender. At gøre det på en andens fil uden autorisation er uautoriseret adgang — samme lov som for enhver anden computer-indtrængen.</p> Er fcrackzip vedligeholdt?</h3> Kun lige. Kodebasen har været stabil i femten-plus år. Til moderne arbejde har kombinationen af zip2john</code> + hashcat</code> overtaget.</p> Kan fcrackzip bruge en GPU?</h3> Nej. fcrackzip</code> er kun CPU. Hvis GPU er det, du har, så gå direkte til hashcat.</p> Håndterer fcrackzip .7z, .rar, .gpg-filer?</h3> Nej — kun klassisk PKZIP .zip</code>. Til .7z</code>, brug 7z2john</code> + hashcat (mode 11600). Til .rar</code>, rar2john</code> + hashcat (mode 12500 / 13000). Til .gpg</code>, gpg2john</code> + hashcat (mode 17010+).</p> Hvordan genererer jeg en målrettet ordliste?</h3> hashcat</code>s maskprocessor (mp64</code>), crunch</code> og cewl</code> (crawler et site for kandidat-ord) er alle værd at kende. Til at gendanne et specifikt glemt kodeord er den højeste-yield-tilgang at skrive ned, hvad du husker om det — længde, sandsynlige ord, sandsynlige tal — og bygge et mask-angreb fra det.</p> Opsummering</h2> fcrackzip</code> + -D</code> + en ordliste er det rigtige første forsøg.</li> Virker det ikke, og det er ZipCrypto: fcrackzip</code> + -b</code> med et snævert charset og kort længde.</li> Virker det ikke, eller det er AES: zip2john</code> + hashcat</code> på en GPU.</li> Virker det ikke: dit kodeord var stærkt nok. Det er systemet, der virker som tiltænkt.</li> </ul> Wi-Fi-hacking gennem 25 år — 2002, 2007, 2012, 2017, 2022, 2027 2026-04-22T00:00:00+00:00 TL;DR —</strong> Wi-Fi-sikkerhed har været gennem fire generationer — WEP</strong>, WPA</strong>, WPA2</strong>, WPA3</strong> — hver introduceret, fordi forgængeren var brudt. Dette indlæg går gennem seks snapshots af state of the art: 2002</strong> (WEP, trivielt), 2007</strong> (WEP død, WPA udbredt, offline-angreb kommer frem), 2012</strong> (WPA2 dominerer, dictionary-angreb på GPU’er), 2017</strong> (KRACK bryder WPA2 under de rette betingelser, PMKID-lækken i 2018), 2022</strong> (WPA3 ruller ud, downgrade-angreb, cloud-skala-cracking), 2027</strong> (dagens landskab: WPA3 næsten universel, 6 GHz åbner ny overflade, angreb flytter op i stakken). For hvert år opsummerer jeg angrebet, værktøjet og hvad en forsvarer burde have gjort. Kun autoriseret testning — den defensive vejledning i bunden er pointen.</p> Overblik</h2> År</th> Dominerende standard</th> Hovedangreb</th> Indsats for typisk netværk</th> Hurtigste dictionary / nøgle-rate dengang</th></tr></thead> 2002</td> WEP (100%)</td> FMS statistisk IV</td> ~4M pakker / 2–10 t på aktivt AP</td> N/A — nøglen udledes af IV’er</td></tr> 2007</td> WEP 35%, WPA 25%, WPA2 20%, åben 20%</td> PTW + aircrack-ng</td> 40–85k pakker / <5 min (WEP)</td> ~50–100 PSK/s (CPU, cowpatty)</td></tr> 2012</td> WPA2 ~70%</td> Reaver (WPS) + GPU PSK dictionary</td> 11.000 WPS-PIN-forsøg / 2–10 t</td> ~75.000 PSK/s (GTX 580)</td></tr> 2017</td> WPA2 ~85%</td> KRACK; derefter PMKID (2018)</td> 1 pakke (PMKID) → offline dict</td> ~400.000 PSK/s (GTX 1080)</td></tr> 2022</td> WPA2 ~60%, WPA3 ~20%, mixed ~15%</td> Dragonblood downgrade</td> Tving WPA2-fallback, så GPU/cloud</td> ~1,2M PSK/s (RTX 3090), ~10M (8× A100)</td></tr> 2027</td> WPA3 ~40%, mixed ~35%, WPA2 ~20%</td> Klient-side + downgrade + chipset-FW</td> SAE intakt; legacy WPA2 på lånt tid</td> ~5–8M PSK/s (RTX 5090-klasse enkelt GPU)</td></tr> </tbody></table> Globale udbredelses-andele er omtrentlige, afledt af offentlige Wi-Fi-målinger (WiGLE-trends + leverandør-rapporter); regn med ± 10 procentpoint.</p> 2002 — WEP overalt, og trivielt brudt</h2> Standard:</strong> IEEE 802.11b med WEP</strong> (Wired Equivalent Privacy). 40-bit eller 104-bit RC4-nøgle, 24-bit IV, CRC-32-integritet.</p> Hvad er galt med den:</strong> IV’en er for lille, nøglerne er statiske, og RC4’s initial key schedule lækker bits af nøglen, når visse IV’er bruges. Det er FMS-angrebet</strong> (Fluhrer, Mantin, Shamir, 2001) og dets efterkommere.</p> Hvad en angriber gjorde i 2002:</strong> fangede trafik med en Prism-baseret USB-adapter, indsamlede et par millioner pakker (timer på et aktivt netværk) og udtrak nøglen med AirSnort</strong> eller WEPCrack</strong>. Angrebene var så pinlige, at Wi-Fi Alliance skubbede WPA som en midlertidig firmware-patchbar løsning i 2003.</p> Tal (2002):</strong></p> Global Wi-Fi-udbredelse:</strong> ~100% WEP (WPA blev først ratificeret marts 2003).</li> Nøglelængde:</strong> 40 bit (eksport-grade) eller 104 bit. Irrelevant — angrebet er på IV’en, ikke på nøglen.</li> IV-space:</strong> 24 bit → kun ~16,7 M mulige IV’er. Fødselsdags-kollision efter ~5.000 pakker.</li> FMS-angrebets pakke-antal:</strong> ~500 k–4 M “interessante” IV-frames (få timers aktiv trafik).</li> Typisk crack-tid i ur-tid:</strong> 2–10 t på et travlt SOHO-netværk.</li> Forbrugerhardware:</strong> én laptop + én Prism2/Prism2.5 USB-dongle (~$40 brugt dengang).</li> Værktøjer:</strong> AirSnort, WEPCrack, Kismet til capture.</li> CVE’er:</strong> WEP er ikke i sig selv en CVE, men Borisov/Goldberg/Wagner (2001) og FMS-paperet (2001) er de kanoniske referencer.</li> </ul> Hvad en forsvarer burde have gjort:</strong> erkendt, at WEP ikke er en sikkerhedsfunktion, og behandle det trådløse LAN som ubetroet. Brug en VPN eller IPSec på lag 3.</p> 2007 — WEP død, WPA overgangsvis, WPA2 på vej</h2> Standard:</strong> WPA (2003), en nød-løsning med per-pakke-nøgler (TKIP). WPA2 (2004) med AES-CCMP begynder at dukke op i hjemme-routere.</p> Hvad der er nyt for angribere:</strong> PTW-angrebet</strong> på WEP (2007) reducerer pakke-antallet fra ~1 million til ~40.000 — WEP kan nu crackes på minutter. aircrack-ng</strong> bliver den kanoniske toolkit. Mod WPA-Personal bliver offline-dictionary-angreb på 4-way-handshake praktiske på CPU’er: fang en handshake, fodr PSK-afledningen gennem cowpatty</code> eller aircrack-ng</code>, prøv dictionary-indgange én ad gangen.</p> Hvad angribere endnu ikke havde:</strong> meningsfuld GPU-acceleration af WPA-PSK. Dictionary-angreb var langsomme.</p> Tal (2007):</strong></p> Global udbredelse (WiGLE-målinger):</strong> WEP ~35%, WPA ~25%, WPA2 ~20%, åben ~20%.</li> PTW-angrebets pakke-antal:</strong> ~40.000–85.000 fangede frames for at gendanne en WEP-nøgle (ned fra millioner).</li> Crack-tid med aircrack-ng + pakke-injektion:</strong> <5 minutter, ofte under 60 sekunder.</li> WPA-PSK dictionary-rate (CPU, cowpatty/aircrack-ng):</strong> ~50–100 kandidater/sek pr. core.</li> Rockyou-ordliste</strong> (lækket dec. 2009): 14,3 M indgange — blev de-facto engelsk PSK-ordliste.</li> WPA2 obligatorisk for Wi-Fi CERTIFIED:</strong> marts 2006.</li> Aircrack-ng 1.0:</strong> udgivet 2006, konsoliderede økosystemet.</li> </ul> Hvad en forsvarer burde have gjort:</strong> migrere til WPA2-AES-CCMP, vælg en PSK længere end nogen dictionary. Drop WEP-netværk helt.</p> 2012 — WPA2 dominerer, GPU-cracking moden</h2> Standard:</strong> WPA2 er default på stort set al consumer-gear. WPA2-Enterprise (802.1X / EAP) i corporate-netværk.</p> Hvad der er nyt for angribere:</strong> hashcat</strong> og oclHashcat</strong>, pyrit</strong> og John the Ripper</strong> gør WPA-PSK-dictionary-angrebet til et GPU-problem</strong>. En handshake-capture + en enkelt moderne GPU klarer titusindvis af kandidat-PSK’er pr. sekund; en lille lejet GPU-farm håndterer hundredtusinder. airodump-ng</strong> + Reaver</strong> (2011) udnytter en implementerings-fejl i WPS-PIN</strong> til at gendanne WPA-PSK’en helt uden en dictionary — en dødsdom for hjemme-routere med WPS-on-by-default.</p> Tal (2012):</strong></p> Global udbredelse:</strong> WPA2 ~70%, WEP ~10%, åben ~15%, WPA ~5%.</li> WPS-PIN-space på papir:</strong> 10⁸ = 100 millioner. Effektiv</strong> angrebs-space efter Viehböck-splittet: 10⁴ + 10³ = ~11.000 forsøg.</li> Reaver ur-tid til at gendanne WPS-PIN → PSK:</strong> 2–10 timer mod en upatched AP.</li> hashcat WPA-PSK throughput på GTX 580 (reference-GPU 2012):</strong> ~75.000 kandidater/sek.</li> hashcat WPA-PSK på en lille 4-GPU-rig fra æraen:</strong> ~300.000 kandidater/sek, dvs. rockyou.txt</code> (14,3 M) på ~50 sekunder.</li> Virkelig PSK-gendannelsesrate med rockyou + almindelige regler:</strong> ~20–25% på fangede handshakes i akademiske studier.</li> WPA2-PEAP/MSCHAPv2-hashrate (et Wi-Fi-tilstødende Enterprise-problem):</strong> titusinder af millioner/sek på en enkelt GPU, fuldt 2²⁸-keyspace inden for et døgn.</li> </ul> Hvad forsvarere burde have gjort:</strong></p> Slå WPS fra.</strong> De fleste routere havde den tændt som default.</li> Brug lange tilfældige PSK’er</strong>, ikke dictionary-ord.</li> Til enterprise: 802.1X + EAP-TLS med klient-certifikater</strong>, ikke PEAP-MSCHAPv2 (som i sig selv er et GPU-problem).</li> </ul> 2017 — KRACK</h2> Standard:</strong> WPA2 stadig overalt.</p> Hvad der er nyt for angribere:</strong> KRACK</strong> (Vanhoef, Piessens, 2017) — Key Reinstallation Attack. Det cracker ikke PSK’en. Det udnytter en subtil fejl i 4-way-handshaken, hvor, under visse betingelser (specifikt på Android 6+ og wpa_supplicant 2.4–2.6), genafspilning af handshake-meddelelse 3 får klienten til at geninstallere en all-zero session-nøgle</strong>. Derfra kan angriberen dekryptere udvalgt trafik og, afhængigt af cipher suite, injicere pakker.</p> Hvad gjorde KRACK anderledes end tidligere angreb:</strong> det ramte protokollen, ikke nøglen</strong>. En stærk PSK hjalp ikke. Hver WPA2-implementation havde brug for en patch. De fleste leverandører leverede en inden for uger; nogle tog år.</p> Også i denne æra:</strong></p> PMKID hashcat-angrebet</strong> (2018, Steube). Mange AP’er lækker PMKID’en i en enkelt besked; én pakke er nok til at starte et offline PSK-angreb. Sænkede capture-barren yderligere — ingen klient-association nødvendig.</li> Evil twin / captive portal-phishing.</strong> Efterhånden som enheds-UI’er blev smukkere, blev falske captive portals alarmerende effektive mod mennesker.</li> </ul> Tal (2017–2018):</strong></p> Global udbredelse:</strong> WPA2 ~85%, WEP <3%, åben ~10%, WPA3 endnu ikke leveret.</li> KRACK CVE’er:</strong> 10 i den koordinerede offentliggørelse (CVE-2017-13077 til CVE-2017-13088).</li> KRACK-berørte enheder:</strong> alle WPA2-klienter og AP’er — 10+ milliarder</strong> endpoints. Reel patching tog år for long-tail-IoT.</li> Patch-latency hos leverandører:</strong> Microsoft / de fleste Linux-distroer inden for 1 uge fra disclosure; Android 2+ måneder afhængigt af OEM; mange embedded-enheder blev aldrig patchet.</li> PMKID-angrebets pakke-antal:</strong> 1 enkelt frame</strong> mod 4-way-handshakens 4 frames — ingen klient-association eller deauth nødvendig.</li> hashcat på GTX 1080 (reference-GPU 2017):</strong> ~400.000 WPA-PSK-kandidater/sek — ~5× hurtigere end 2012.</li> En lejet 8× 1080 Ti-instans (~$4/t i 2017):</strong> ~3M kandidater/sek — rockyou.txt</code> på <5 sekunder.</li> Koordineret disclosure-forløbstid:</strong> 4 måneder fra leverandør-notificering til offentlig release.</li> </ul> Hvad en forsvarer burde have gjort:</strong> patch Android / wpa_supplicant straks, håndhæv HTTPS overalt, så dekrypteret Wi-Fi-trafik er mindre nyttig, begynd at planlægge WPA3-migration.</p> 2022 — WPA3 ruller ud, downgrade-angreb</h2> Standard:</strong> WPA3 (2018) påkrævet til Wi-Fi CERTIFIED-enheder siden 2020. Nøgle-opgraderinger:</p> SAE</strong> (Simultaneous Authentication of Equals) erstatter 4-way-handshake-PSK’en — offline-dictionary-angreb bliver ufremkommelige.</li> 192-bit mode</strong> til Enterprise.</li> Forward secrecy</strong>.</li> PMF</strong> (Protected Management Frames) obligatorisk — neutraliserer deauth-baseret denial-of-service.</li> </ul> Hvad der er nyt for angribere:</strong> WPA3 er ikke brudt, men dens udrulning er for det meste ikke WPA3-kun</strong>. WPA2/3-transition-mode</strong> — default på de fleste AP’er — betyder, at en angriber kan tvinge en downgrade og angribe som WPA2. Det er Dragonblood</strong> (Vanhoef, Ronen, 2019 + opfølgninger): en familie af side-channel- og downgrade-angreb mod SAE. I 2022 lukkede patchede SAE-implementationer for det meste timing-side-channels; downgrade-angrebet virker stadig på mixed-mode-netværk.</p> Også i denne æra:</strong></p> Cloud-skala-cracking</strong>: at leje 8× H100 eller lignende på timebasis gør PMK-dictionary-angreb praktiske på en skala, ingen amatør havde i 2012.</li> Chipset-firmware-sårbarheder</strong> (FragAttacks, 2021): fejl i selve Wi-Fi-stakken, under WPA-laget, lader angribere injicere frames uden at skulle bryde en handshake overhovedet.</li> </ul> Tal (2022):</strong></p> Global udbredelse:</strong> WPA2-only ~60%, WPA3 ~20%, WPA2/3-transition-mode ~15%, WEP <1%.</li> WPA3-understøttelse på nye routere:</strong> ~60% af forbruger-AP’er leveret i 2022 understøttede WPA3 (vs. ~10% i 2020).</li> Dragonblood CVE’er:</strong> 5 (CVE-2019-9494 til CVE-2019-9499).</li> FragAttacks CVE’er:</strong> 12 i 2021-bundlet.</li> hashcat WPA-PSK på RTX 3090:</strong> ~1,2M kandidater/sek.</li> 8× A100-cloud-instans:</strong> ~10M kandidater/sek samlet. rockyou.txt</code> på ~1,5 sekund; et 10 mia.-kandidats mask-angreb på ~17 minutter.</li> Pris pr. milliard PSK-forsøg på spot-cloud-GPU’er:</strong> ~$3–5.</li> 12-tegns fuldt tilfældig PSK-entropi:</strong> 2⁷² ≈ 4,7 × 10²¹. Ved 10M H/s er udtømmende angreb = ~15.000 år</strong>. Sikker.</li> 8-tegns små-bogstav+ciffer PSK-entropi:</strong> 2⁴¹ ≈ 2,2 × 10¹². Ved 10M H/s: ~2,5 døgn</strong>. Ikke sikker.</li> </ul> Hvad en forsvarer burde have gjort:</strong> WPA3-Personal kun (ingen WPA2-transition) på netværk, hvor du kan håndhæve det; PMF påkrævet; lang tilfældig PSK selv med SAE; hold AP-firmware opdateret.</p> 2027 — dagens landskab</h2> Standard:</strong> Wi-Fi 6E (6 GHz) og tidlige Wi-Fi 7-udrulninger. WPA3 næsten universel på nyt gear; legacy WPA2 stadig almindelig i små virksomheder og længe-levende hjemme-netværk.</p> State of the art i angreb:</strong></p> SAE holder.</strong> Intet offentligt, praktisk angreb mod et velkonfigureret WPA3-Personal-netværk i 2027. Dictionary-angreb mod PSK’en er ikke fremkommelige — det er SAE’s pointe.</li> Downgrade-angreb</strong> er den primære ting. Ethvert netværk, der stadig annoncerer WPA2/3-transition, kan angribes som WPA2. Modstandere kigger efter mixed-mode-SSID’er først.</li> 6 GHz åbner ny overflade.</strong> 6 GHz-båndet kræver WPA3 til nye standarder; men legacy-klient-bridging, IoT-enheder uden 6 GHz-understøttelse og fejlkonfigureret co-broadcast-SSID’er skaber inkonsistenser, angribere udnytter.</li> Klient-side-angreb.</strong> Når link-laget er sikkert, flytter angribere op. Rogue-captive-portals der snyder telefoner til at stole på et dårligt certifikat, QR-kode-tilslutning med falske SSID’er, deauth-under-roaming-angreb (sværere nu med PMF, men ikke elimineret).</li> Supply chain.</strong> Firmware-indlejrede bagdøre og vendor-bugs i Wi-Fi-chipsets (FragAttacks-arven) er stadig en varig kilde til exploits.</li> Cloud-cracking er blevet commodity.</strong> Et weekend-langt SAE-offline-angreb (i de tilfælde, hvor offline-angreb er muligt, altså målet kørte en upatched SAE) koster groft prisen på en pæn middag. Det betyder for det meste intet, fordi SAE ikke er reducerbart til offline-dictionary-angreb — men det skubber økonomien på legacy-WPA2-netværk, folk ikke har migreret.</li> </ul> Værktøjer stadig i rotation i 2027:</strong> aircrack-ng (ældre, stadig kanonisk til captures og WPA2), hashcat (cracking), bettercap (Wi-Fi MITM / rogue AP), airgeddon (workflow-lim) og en bølge af ESP32-baserede lomme-værktøjer til opportunistisk deauth og handshake-capture.</p> Tal (2027):</strong></p> Global udbredelse:</strong> WPA3 ~40%, WPA2/3-transition ~35%, WPA2-only ~20%, WEP ~0,5% (lang hale af gammelt gear).</li> Enterprise-andel der kører WPA3-Enterprise 192-bit mode:</strong> stadig <10%. De fleste corporate-netværk er stadig WPA2-Enterprise med PEAP.</li> Ny-enhed WPA3-certificering:</strong> obligatorisk for Wi-Fi 6 siden 2020, Wi-Fi 6E (6 GHz) siden 2022, Wi-Fi 7 fra launch.</li> hashcat WPA-PSK på RTX 5090-klasse enkelt-GPU (2025+):</strong> ~5–8M kandidater/sek.</li> 8× H100-cloud-instans:</strong> ~50M kandidater/sek samlet. rockyou.txt</code> på ~0,3 sekund.</li> SAE (WPA3-Personal) offline-angreb:</strong> ufremkommeligt ved enhver hash-rate — handshaken udleverer ikke en crackbar hash til en aflytter.</li> Pris for at brute-force en svag 8-tegns WPA2-PSK i 2027:</strong> <$10 på spot-cloud-GPU’er.</li> Pris for at brute-force en 12-tegns tilfældig WPA2-PSK:</strong> stadig ~$10⁹ (samme regnestykke som 2022, GPU’er 5× hurtigere → stadig årtusinder).</li> ESP32-S3 “Wi-Fi Nugget” / Flipper Zero-klasse lomme-værktøjer</strong> i cirkulation i 2027: hundredtusinder af enheder. Opportunistisk handshake-capture er trivielt; PSK-cracking er stadig offline på en kraftig host.</li> Deauth-DoS-effektivitet:</strong> nær-nul på PMF-required-netværk; virker stadig mod de ~30% af udrullede AP’er, hvor PMF er “capable”, men ikke “required”.</li> </ul> Bundlinje: mod WPA3-Personal med SAE, PMF påkrævet og en tilfældig PSK</strong> kommer intet af 2027-værktøjssættet ind via link-laget. Mod en typisk 2019-vintage hjemme-router, der stadig kører WPA2 med en svag PSK og WPS valgfrit eksponeret</strong>, er en weekend på en mellem-klasse-GPU rigeligt.</p> Defensiv vejledning for 2027</h2> Det er den del, der betyder mere end al historien.</p> WPA3-Personal SAE-only eller WPA3-Enterprise med EAP-TLS.</strong> Ingen transition-mode på noget netværk, du kan kontrollere. Tjek eksplicit — mange AP’er default til transition.</li> PMF påkrævet, ikke valgfrit.</strong> Protected Management Frames forhindrer deauth-drevne handshake-captures og basal denial-of-service.</li> PSK-længde: tilfældig, ≥ 20 tegn.</strong> SAE gør korte PSK’er sikrere end de plejede at være, men ingen grund til at spille.</li> Slå WPS permanent fra.</strong> Selvom WPS-PIN-angrebet er oldgammelt, leverer mange routere stadig med det aktiveret for “bekvemmelighed”.</li> Gæste-SSID isoleret.</strong> Klient-til-klient-isolation slået til og routet til et separat VLAN uden intern LAN-adgang.</li> IoT-SSID, separat og indelukket.</strong> Billige Wi-Fi-termostater og legetøj er det svageste led på de fleste hjemme-netværk. De får deres eget SSID, deres eget VLAN og ingen rute til noget vigtigt.</li> Firmware-opdateringer på AP’er.</strong> De fleste interessante 2020’er-Wi-Fi-sårbarheder var på chipset-niveau; rettelsen er altid en firmware-opdatering. Køb AP’er fra en leverandør, der leverer dem.</li> Antag at link-laget vil fejle og forsvar dig over det.</strong> HTTPS overalt, klient-certs på alt, der betyder noget, VPN eller Tailscale til fjernadgang. Når (ikke hvis) nogen bryder din Wi-Fi, skal lag 4+ stadig holde.</li> </ul> Hvad der forblev det samme gennem 25 år</h2> Tre mønstre gentager sig ved hver generation:</p> Kryptografien er næsten altid stærkere end udrulningerne.</strong> WEP var en design-fejl; WPA2 og WPA3 er blevet brudt af implementerings-fejl, downgrade-stier og side-channels — ikke af rene krypto-svagheder.</li> Defaults betyder mere end kapabiliteter.</strong> WPS tændt som default, WPA2/3-transition-mode tændt som default, gæste-netværk uden isolation som default — det er det, angribere faktisk finder, i skala.</li> Angriberen flytter altid op i stakken.</strong> Når link-lags-sikkerheden forbedres, skifter angreb til captive portals, falske certs, klient-fejlkonfigurationer og phishing. Ingen mængde WPA3 retter brugeren, der klikker “Stol på” på evil-twin’ens falske certifikat.</li> </ol> Coda</h2> Hvis denne posts forfader på dette site, fra 2010, var “Hvordan man hacker et trådløst netværk” og fokuserede på WEP med aircrack-ng</code>, er 2027-versionen tættere på “Hvordan man tænker om Wi-Fi-sikkerhed” og fokuserer på konfiguration, patching og realistisk trussels-modellering. Kryptografien har gjort sit arbejde. Lagene omkring den er den interessante front nu.</p> Test dine egne netværk — eller netværk, du er autoriseret til at teste — test ikke nogen andens. Samme lov, der gjaldt i 2002, gælder i 2027.</p> nemboks.dk — få din digitale post (mit.dk, e-Boks) sendt direkte til din e-mail 2026-04-22T00:00:00+00:00 TL;DR —</strong> nemboks.dk</a> videresender digital post</strong> (fra mit.dk</a> og e-Boks</a>) direkte til din e-mail. Problemet, det løser: digital post er i teorien “push”, men i praksis “pull” — du skal stadig logge ind med MitID, åbne en app og klikke rundt for at læse et brev fra SKAT eller kommunen. Nemboks laver det til en e-mail, der lander i den indbakke, du i forvejen bor i — med PDF’en vedhæftet. Bygget til danske SMV’er, hvor samme virksomhed</code> modtager post for flere selskaber eller medarbejdere, og hvor revisorer, bogholdere og ejendomsadministratorer vil have digital post samme sted som al anden e-mail. Gratis beta; efter beta koster det 39 kr/md på årlig betaling, 49 kr/md månedlig.</p> Problemet med dansk digital post</h2> Siden 2014 er kommunikation fra det offentlige digital som udgangspunkt. Det betyder, at hvis din kommune, SKAT, Udbetaling Danmark eller FerieKonto skal fat i dig, lægger de brevet i enten mit.dk</a></strong> (den offentlige portal) eller e-Boks</a></strong> (historisk set den mest brugte private portal, nu koblet til Digital Post).</p> I princippet er det fint: samlet, sporbart, ingen papir. I praksis er der en masse friktion:</p> Du skal logge ind med MitID hver gang.</strong> Hvert skattebrev, hver p-afgift, hver feriepenge-besked ligger bag en MFA-flow.</li> Apps notificerer dig, men notifikationerne er tynde.</strong> “Du har ny post” — ikke emnelinje, ikke afsender, ikke nok til at prioritere.</li> Der er ingen indbygget videresendelse.</strong> Du kan ikke sige “send alt fra SKAT til min bogholder på bogholder@firma.dk</code>”.</li> Virksomheder får det værste af begge verdener.</strong> En CVR-registreret virksomhed har sin egen mit.dk / e-Boks-indbakke. Hvis indehaveren ikke tjekker den, er der ingen, der gør.</li> </ul> E-mail er omvendt standard-indbakken for små virksomheder: delte postkasser, videresendelsesregler, arkivering, filtre, søgning. Nemboks bygger broen imellem.</p> Hvad Nemboks gør</h2> Når Nemboks er sat op, logger den på din mit.dk / e-Boks på dine vegne, tjekker for ny post og sender hvert nyt brev videre — som en rigtig e-mail med PDF’en vedhæftet</strong> — til den eller de adresser, du har konfigureret.</p> En e-mail pr. brev.</strong> Emne = afsender + emne. Brødtekst = tekst-preview. Vedhæftning = PDF’en.</li> Flere selskaber pr. konto.</strong> Hvis du er revisor for flere CVR’er, bor de alle under samme Nemboks-dashboard.</li> Flere destinationer pr. selskab.</strong> Send f.eks. alt fra SKAT til bogholderen, resten til ejeren.</li> Originalen bliver liggende i mit.dk / e-Boks.</strong> Intet slettes — Nemboks læser kun.</li> Logger hver videresendelse.</strong> For revision og ro i maven.</li> </ul> Det praktiske resultat: revisoren eller bogholderen, der allerede bor i Outlook eller Gmail, holder op med at skifte kontekst til en portal en gang om ugen.</p> Hvem det er til</h2> Nemboks er bygget til danske SMV’er, især:</p> Revisorer og bogholdere.</strong> Kunden giver adgang én gang; derefter bliver hvert SKAT-brev for hver kunde til en e-mail i den delte indbakke.</li> Ejendomsadministratorer.</strong> En enkelt administrator kan sidde med post for dusinvis af ejendoms-A/S og -ApS.</li> Smv-indehavere.</strong> Enkeltmandsvirksomheden eller to-mands-ApS, hvor ejeren hellere vil have brevet fra kommunen samme sted som sin kunde-mail.</li> </ul> Stakken</h2> For de nysgerrige:</p> Rails 8</strong> på Ruby 3.4 med Hotwire (Turbo + Stimulus) og Tailwind til dashboardet.</li> PostgreSQL</strong> til persistens.</li> Auth0</a></strong> til autentificering. Brugerne logger på med Google, Microsoft eller e-mail+kodeord — ingen separat Nemboks-kodeord at glemme.</li> Stripe</a></strong> til abonnementsstyring, inkl. deres hostede kundeportal til selv-betjent kortopdatering og opsigelse.</li> Postmark</a></strong> til transaktionel e-mail — de er kategoriens standard for “e-mail der skal lande i indbakken”, hvilket er hele pointen med en videresendelses-tjeneste.</li> Docker + Kamal</strong> til deployment. Zero-downtime rollouts på en lille flåde; ingen Kubernetes at drifte.</li> Cloudflare Pages</strong> til det statiske marketing-site på nemboks.dk</a>.</li> </ul> Opdelingen — Rails-app på Kamal, marketing-site på Pages — er bevidst. Marketing-sitet skal være billigt, hurtigt og tungt cached; Rails-appen skal have database og baggrundsjobs. At køre dem som to separate deployments holder hver af dem simpel.</p> Pris</h2> Gratis beta</strong>, mens tjenesten stabiliseres.</li> Efter beta: 39 kr/md</strong> på årlig betaling, 49 kr/md</strong> månedlig — excl. moms. Flad pris pr. selskab; ingen pris pr. brev.</li> 60 dages gratis prøveperiode</strong> til nye kunder efter beta.</li> </ul> Ofte stillede spørgsmål</h2> Må Nemboks læse min mit.dk / e-Boks?</h3> Ja — som indbakke-ejer giver du Nemboks lov til at læse på dine vegne. Nemboks læser kun; intet slettes, besvares eller markeres som læst uden at du har konfigureret det.</p> Er det GDPR-compliant?</h3> Nemboks behandler persondata på dine vegne. Som kunde er du dataansvarlig; Nemboks er databehandler, og der er en standard databehandleraftale (DPA) at underskrive. Alle data opbevares i EU.</p> Hvad sker der med det originale brev i mit.dk / e-Boks?</h3> Det bliver liggende. Nemboks er read-only.</p> Kan jeg videresende til flere e-mailadresser?</h3> Ja. Hvert selskab kan have flere modtagere, og du kan sende forskellige afsendere til forskellige adresser (f.eks. alt fra SKAT til bogholderen).</p> Virker Nemboks for privatpersoner?</h3> Det nuværende fokus er danske virksomheder (CVR). En privat-plan kommer måske senere.</p> Hvad hvis Nemboks går ned?</h3> Din post lander stadig i mit.dk / e-Boks som normalt; Nemboks videresender bare ikke, før tjenesten er tilbage. Intet går tabt.</p> Hvordan opsiger jeg?</h3> Via Stripes kundeportal inde fra dashboardet. Ingen e-mail, intet telefonopkald.</p> Hvorfor bygge det</h2> Digital post virker. Det er sikkert, sporbart, og jeg vil hellere have et SKAT-brev i mit.dk end en brun kuvert. Men brugerfladen er designet til en borger, der læser en håndfuld breve om året — ikke til en virksomhed, der får dusinvis om ugen på tværs af flere CVR’er. E-mail løser “dusinvis om ugen på tværs af flere postkasser” udmærket — filtre, regler, delte indbakker, søgning — så den mindst interessante, men mest nyttige bro er at få brevene ud af portalen og ind i e-mailen med PDF’en vedhæftet, uden at nogen skal logge ind hver gang.</p> Det er Nemboks.</p> Sådan afspiller du Spotify på en Logitech Squeezebox i 2026 2026-04-22T00:00:00+00:00 TL;DR —</strong> Det officielle Spotify-plugin, Logitech leverede med Squeezebox, holdt op med at virke, da Spotify lukkede libspotify</code>-API’en i 2022. I 2026 er der to fungerende veje til at få Spotify på en Squeezebox Classic, Touch, Boom, Radio eller Transporter</strong>: (1) Logitech Media Server + Spotty-plugin’et</a></strong> (nu omdøbt Spotty</code> / nogle gange Spotty-XL</code>), der bruger Spotifys Web API plus librespot</code> under motorhjelmen, eller (2) kør spotifyd</a></strong> på samme host som LMS og peg LMS på den som generisk lydkilde. Vej 1 er den, du vil bruge, medmindre du har en grund til andet. Dette indlæg gennemgår den.</p> Hvad skete der med det officielle plugin</h2> Squeezebox-hardware gik end-of-life hos Logitech i 2012, men softwaren — Logitech Media Server (LMS)</strong>, det der faktisk streamer musik til enhederne — er blevet community-vedligeholdt siden. I årevis leverede den et officielt “Spotify”-plugin, der brugte Spotifys nu udfasede libspotify</code> C-bibliotek. Da Spotify lukkede libspotify</code> i 2022, holdt det plugin op med at virke, og Spotify har ikke leveret en erstatning til tredjeparts-indbyggede enheder.</p> Community’et udfyldte hullet:</p> librespot</code></strong> — en open-source Rust-reimplementering af Spotify Connect-klientprotokollen. Grundlaget for de fleste moderne tredjeparts-Spotify-integrationer.</li> Spotty-plugin til LMS</strong> — pakker librespot</code> og Spotifys Web API ind i et LMS-plugin. Præsenterer Spotify-browsing, søgning, playlister og afspilning inde i Squeezebox-UI’et (både enheds-skærmen og LMS-web-UI’et).</li> spotifyd</strong> — en selvstændig librespot</code>-baseret dæmon, der fremstår som et Spotify Connect-mål. Din telefon ser den som en højttaler, du caster til den, og dens lydudgang går et sted hen, hvor LMS kan samle det op.</li> </ul> Vej 1 (anbefalet): Spotty-plugin på LMS</h2> Dette er den reneste oplevelse og den, der føles native på Squeezeboxen. Du søger og browser fra Squeezebox-fjernbetjeningen eller Touch-skærmen, og det Virker Bare.</p> 1. Få LMS op at køre</h3> Hvis du ikke allerede kører LMS, så installér det på en altid-tændt maskine — en Raspberry Pi, et NAS med Docker eller en lille Linux-boks er ideelt.</p> # Debian/Ubuntu — hent den nyeste .deb fra community-repoet wget https://downloads.slimdevices.com/LogitechMediaServer_v8.x/logitechmediaserver_<latest>_amd64.deb sudo apt install ./logitechmediaserver_<latest>_amd64.deb sudo systemctl enable --now logitechmediaserver </code></pre> Eller via Docker — lmscommunity/logitechmediaserver</code> er et vedligeholdt image:</p> docker run -d --name lms \ --network host \ -v lms-config:/config \ -v /sti/til/musik:/music:ro \ lmscommunity/logitechmediaserver:latest </code></pre> Åbn http://<host>:9000/</code>, og du skulle se LMS-web-UI’et. Dine Squeezebox-enheder på samme LAN skal dukke op under Players</strong> automatisk.</p> 2. Installér Spotty</h3> I LMS-web-UI’et: Settings → Plugins → Install new plugins</strong> og kryds Spotty</strong> af (forfatter: Michael Herger). LMS henter, installerer og genstarter. Efter genstart har du et Spotty</strong>-punkt i Settings → Advanced → Spotty</strong>.</p> 3. Autoriser Spotty med din Spotify-konto</h3> I Settings → Advanced → Spotty</strong> klik Add account</strong>.</li> Spotty starter et OAuth-flow via Spotifys Web API — du logger ind én gang i en browser, godkender adgangen, og tokenet gemmes på LMS-serveren.</li> Du skal bruge Spotify Premium</strong> til afspilning. (Det er en Spotify-side-grænse: librespot</code> kan autentificere med Free, men fuld-kvalitets-afspilning er kun til Premium.)</li> </ul> 4. Afspil noget</h3> På selve Squeezebox-enheden: Home → My Music → Spotty</strong> (eller Home → Music Library → Spotty</strong>, afhængigt af din LMS-version) — browsing af playlister, søgning, start et nummer. På Squeezebox Touch virker artwork på skærmen. På Classic virker tekst-UI’et. På Radio og Boom styrer du det fra web-UI’et eller apps som Squeeze Commander</a> / Squeezer</a>.</p> Spotty tilføjer også Squeezebox-enheder som Spotify Connect-mål</strong> — det betyder, at du kan caste fra din telefon-Spotify-app til “Stue-Squeezeboxen” native, på samme måde som du ville caste til en Sonos eller en Google Home.</p> Vej 2: spotifyd som Connect-bro</h2> Brug denne, hvis Spotty ikke vil installere (gammel LMS-version, gammel Perl, mærkeligt OS) eller du specifikt vil have Spotify Connect-adfærd uden Spotty.</p> # Debian/Ubuntu sudo apt install spotifyd # eller fra kilden: cargo install spotifyd </code></pre> Konfigurér /etc/spotifyd.conf</code> med dine Spotify-credentials, en backend (alsa</code>, pulseaudio</code> eller pipe</code>) og et enhedsnavn. Start dæmonen:</p> sudo systemctl enable --now spotifyd </code></pre> Fra din telefon, cast til den spotifyd</code>-navngivne enhed. Lyden kommer ud af hosten.</p> For at få den lyd ind i en Squeezebox, pipe spotifyd</code> til en FIFO og afspil FIFO’en i LMS:</p> # spotifyd.conf backend = "pipe" device = "/var/run/spotifyd.pipe" </code></pre> Tilføj derefter FIFO’en som en File system music folder</strong> i LMS og afspil den som en live-stream.</p> Det er klodset og har ~1 s forsinkelse i forhold til Spottys tætte integration. Brug det kun, hvis vej 1 ikke virker for dig.</p> Virker på hvilke Squeezeboxe?</h2> Spotty virker på alle Squeezebox-enheder, der taler med LMS:</p> Squeezebox Classic / Squeezebox v3</strong> (tekstdisplay) — tekst-UI-browsing og afspilning.</li> Squeezebox Touch</strong> — farvetouchskærm, artwork, hele UI’et.</li> Squeezebox Boom</strong> — tekst-UI, samme som Classic.</li> Squeezebox Radio</strong> — tekst-UI, indbygget højttaler.</li> Squeezebox Duet / Controller</strong> — controllerens UI virker; afspilning går til Receiveren.</li> Transporter</strong> — fuld understøttelse.</li> piCorePlayer / SqueezeLite på Pi</strong> — ja, det er software-Squeezeboxe, og Spotty streamer fint til dem.</li> </ul> Så længe enheden kan forbinde til LMS, kan Spotty fodre den.</p> Ofte stillede spørgsmål</h2> Skal jeg have Spotify Premium?</h3> Ja, til afspilning. librespot</code> (og dermed Spotty) kræver en Premium-konto for at afkode lyd. Spotify Free-konti kan autentificere, men kan ikke afspille.</p> Virker “Squeezeboxen som Spotify Connect-højttaler”?</h3> Ja, med Spotty installeret. Hver Squeezebox-player dukker op i Spotify-appens enhedsvælger som et Connect-mål.</p> Virker hi-res / lossless?</h3> Spotify tilbyder ikke selv lossless på standardplaner (Hi-Fi har været “kommer snart” i årevis). Spotty afspiller, hvad Spotify serverer — Ogg Vorbis 320 kbps på Premium — og Squeezeboxen håndterer det native.</p> Gapless afspilning?</h3> Ja, Spotty understøtter gapless.</p> Går det i stykker, hvis Spotifys Web API ændrer sig?</h3> Ja, lejlighedsvis — Spotify roterer jævnligt OAuth-scopes eller udfaser endpoints, og Spotty får en patch-release. Hold plugin’et opdateret.</p> Kan jeg køre LMS på samme boks som mit NAS?</h3> Absolut. LMS er let (~200 MB RAM, minimal CPU undtagen under bibliotek-scanninger). At køre det ved siden af Samba eller på en homelab-SBC er det almindelige setup.</p> Er det det samme som “piCorePlayer”?</h3> piCorePlayer er en lille Linux-distribution, der gør en Raspberry Pi til en Squeezebox-kompatibel player (via SqueezeLite). Den erstatter ikke LMS — du skal stadig bruge LMS som server. piCorePlayer + LMS + Spotty er en meget almindelig 2026-stak for folk, hvis oprindelige Squeezebox-hardware endelig døde.</p> Hvad du gør, hvis din Squeezebox slet ikke vil forbinde til LMS</h2> To ting at tjekke først:</p> mDNS / multicast på tværs af dit netværk.</strong> Moderne Wi-Fi-routere blokerer ofte multicast mellem SSID’er eller til kablede hosts. Sæt Squeezeboxen og LMS på samme subnet/VLAN med multicast tilladt.</li> SlimProto-porten (3483/udp og 3483/tcp).</strong> Det er det, Squeezeboxen bruger til at finde LMS. Ikke blokeret af noget fornuftigt, men værd at tjekke, hvis du kører en stram firewall.</li> </ol> Derudover er Squeezebox-community’et stadig aktivt — forums.slimdevices.com</a> og LMS Community GitHub</a> er, hvor problemer bliver løst.</p> Squeezebox-hardware blev udfaset for femten år siden. Takket være LMS, Spotty og librespot</code> afspiller den stadig Spotify bedre end de fleste “smarte højttalere”, der sælges nye i 2026.</p> elpriser.org — danske elpriser time for time 2026-04-20T00:00:00+00:00 TL;DR —</strong> elpriser.org</a> viser den reelle elpris time for time i Danmark</strong> — ikke kun spotprisen. Den samler Nord Pool-spotprisen, din lokale nettarif (netselskab</code>), Energinets system- og transmissionstariffer, elafgiften og 25 % moms. Data kommer fra Energi Data Service</a> og opdateres dagligt, når Nord Pool offentliggør de kommende 24 timer omkring kl. 13. DK1 (Vestdanmark) og DK2 (Østdanmark). Dansksproget, gratis, intet login.</p> Hvad koster el faktisk i Danmark?</h2> “Spotprisen”, du ser på de fleste energidashboards, er kun én del af regningen. Den pris, du rent faktisk betaler pr. kWh, består af seks elementer:</p> Spotpris</strong> — sættes time for time på Nord Pool-markedet for det kommende døgn.</li> Nettarif</strong> — betales til dit lokale netselskab. Varierer efter selskab og tidspunkt (lav-, mellem- og spidslast).</li> Systemtarif</strong> — betales til Energinet, den danske TSO.</li> Transmissionstarif</strong> — betales også til Energinet.</li> Elafgift</strong> — statslig afgift på forbrug.</li> Moms</strong> — 25 % oven i alt det andet.</li> </ol> De fleste prissider viser kun det første tal. Nogle få viser ét eller to mere. Ingen, jeg kunne finde, viste alle seks time for time, for begge prisområder, med den rigtige nettarif automatisk valgt for brugerens netselskab. Det er præcis det, elpriser.org gør.</p> De to prisområder: DK1 og DK2</h2> Danmark er delt i to elprisområder geografisk — Storebælt skiller dem — og de har ofte forskellig pris i samme time:</p> DK1 — Vestdanmark.</strong> Jylland og Fyn. Mere vind-domineret.</li> DK2 — Østdanmark.</strong> Sjælland, Lolland, Falster, Møn og Bornholm. Tættere forbundet med Sverige (SE4) og Tyskland.</li> </ul> Når vinden blæser kraftigt i Jylland, kan DK1 være billig, mens DK2 er dyr. Når en forbindelse er nede, vokser forskellen yderligere. elpriser.org viser begge områder side om side.</p> Hvilket netselskab har du?</h2> Du kan ikke selv vælge dit netselskab — det afhænger af din adresse — men den nettarif, de opkræver, er en betydelig del af regningen, og den varierer med 15–25 øre/kWh i spidslast</strong> mellem billigste og dyreste, hvilket svarer til ~500–1.000 kr/år</strong> for en typisk husstand.</p> Groft rangeret spidslast-tariffer pr. 2025:</p> Område</th> Netselskab</th> Spidslast-tarif (øre/kWh)</th></tr></thead> DK1</td> RAH Net</td> ~33</td></tr> DK1</td> Trefor</td> ~37</td></tr> DK1</td> N1</td> ~46</td></tr> DK2</td> Cerius</td> ~47</td></tr> DK2</td> Radius</td> ~65</td></tr> </tbody></table> Mindre selskaber (Konstant, Nord Energi, Vores Elnet, El-net Kongerslev og andre) har egne tariffer. På elpriser.org vælger du dit eget, og den all-in time-for-time-pris tilpasser sig.</p> Du kan ikke skifte netselskab, men du kan</strong> flytte forbrug — vaskemaskine, opvaskemaskine, EV-ladning, varmepumpe — ned i lavsats-timerne. Time-grafen findes til lige præcis det.</p> Historiske yderpunkter</h2> Rekord-høj:</strong> 16,69 kr/kWh (spotpris ex. moms) i DK2, kl. 19 den 5. september 2022 under energikrisen.</li> Rekord-lav:</strong> −2,76 kr/kWh i DK1, kl. 14 den 2. juli 2023, hvor vindproduktionen overskød forbruget.</li> </ul> Negative priser er ikke en fejl: når produktionen er høj og forbruget lavt, betaler producenterne forbrugerne for at aftage strømmen. Moderne prisstyrede varmepumper og EV-ladere kan læne sig ind i det.</p> Sådan er elpriser.org bygget</h2> Statisk HTML</strong>, genskabt én gang om dagen efter Nord Pools day-ahead-auktion omkring kl. 13 CET.</li> Datakilde</strong>: Energi Data Service</a>, Energinets åbne data. Ingen API-nøgler nødvendige.</li> Strukturerede data</strong>: schema.org/WebApplication</code> og FAQPage</code> udsendes på hver side, så Google kan vise priserne direkte i søgeresultater og AI-oversigter.</li> Hosting</strong>: en lille origin bag Cloudflare. Cachebar hele døgnet; purges ved det daglige rebuild.</li> Sprog</strong>: kun dansk. Domænenavnet burde have været et fingerpeg.</li> </ul> Det hele er et enkeltsporet værktøj: ingen tracking, intet login, ingen nyhedsbrev-popover, ingen “10 måder at spare på strømmen”-lister.</p> Ofte stillede spørgsmål</h2> Hvor ofte opdaterer elpriser.org?</h3> Én gang om dagen, efter at Nord Pools day-ahead-auktion offentliggør næste døgn omkring kl. 13 CET. Intradag-justeringer vises ikke; de fleste forbrugere afregnes alligevel efter day-ahead-prisen.</p> Er prisen med eller uden moms?</h3> Med. Headline-tallet på elpriser.org er all-in pr. kWh: spotpris + tariffer + afgift + 25 % moms. Du kan folde det ud og se opdelingen.</p> Hvorfor er priserne forskellige i DK1 og DK2?</h3> Danmark har to fysisk adskilte elprisområder, forbundet via Storebælt. Når forbindelsen er fuldt udnyttet, eller når vindproduktionen adskiller sig markant mellem øst og vest, clearer de to områder på forskellige Nord Pool-priser.</p> Kan jeg se opdelingen af hver komponent?</h3> Ja. Hver time-celle kan foldes ud for at vise spotpris, hver tarif-komponent, elafgift og moms.</p> Får jeg reelt negative priser, når engrosprisen bliver negativ?</h3> Det afhænger af din kontrakt. Rene spotpris-kontrakter videregiver Nord Pools råpris — tariffer og afgift gælder stadig, så all-in-prisen kan gå svagt negativ eller bare meget lav. Fastpris-kontrakter gør ikke.</p> Hvorfor kun dansk?</h3> Data, regulering, netselskabs-strukturen og målgruppen er alle danske. En engelsk version ville oversætte kontekst, ikke indhold.</p> Hvor kommer data fra?</h3> Energi Data Service</a> (Nord Pool-spot) og Energinets tarifdata. Begge er officielle, offentlige datasæt fra den danske TSO.</p> Lille, fokuseret, intet login, ingen tracking. Sådan bør forbruger-energiværktøjer se ud.</p> winniemethmann.com — fra WordPress til Astro 2026-04-19T00:00:00+00:00 TL;DR —</strong> winniemethmann.com</a> er portfolien for en dansk madfotograf og opskriftsudvikler. I et årti var det et WordPress-site. Jeg byggede det om oven på Astro</a> med content collections</strong> (typet Markdown) i stedet for et CMS, Sharp + AVIF</strong> til billedpipelinen og Astros i18n-routing</strong> (dansk som standard, engelsk på /en/</code>). Build-tid: ~30 sekunder. Output: ~70 % mindre. Intet admin-panel, ingen plugin-opdateringer, ingen bot-prøvet login-endpoint.</p> Hvorfor væk fra WordPress</h2> For en portfolio, der opdateres et par gange om måneden, lavede WordPress for meget:</p> PHP-runtime og MySQL</strong> for et site, der i praksis er statisk.</li> Titusindvis af plugins</strong> til billedgallerier, kontaktformularer, SEO og caching — hver med sin egen opdateringskadence og sikkerhedshuller.</li> Et halvt-forket tema</strong> med patches, ingen huskede hvorfor var der.</li> Et admin-login-endpoint</strong>, der blev prøvet flere tusind gange i døgnet af bots.</li> Gentagne cache-kvaler</strong>, hver gang CDN og plugins var uenige.</li> </ul> Konkret betød det at droppe WordPress:</p> Ingen admin-panel at holde patchet.</strong> WordPress-core, plugin-opdateringer, tema-opdateringer — væk.</li> Ingen database.</strong> Indholdet ligger som Markdown i repoet.</li> Ingen login-flade, bots kan prøve.</strong> Der findes ikke en /wp-admin/</code> længere.</li> ~10× hurtigere sideindlæsning</strong> uden cache-lag.</li> ~70 % mindre samlet build-størrelse</strong> — vi skiftede håndeksporterede JPEG’er ud med AVIF med fornuftige srcset</code>-breakpoints.</li> </ul> Til gengæld mister du den ikke-tekniske redigering. I praksis betød det ingenting: ejeren var gladere for at redigere Markdown end for at kæmpe med WordPress’ blok-editor.</p> Hvorfor Astro</h2> Jeg overvejede Hugo, 11ty, Next.js static export og SvelteKit. Astro vandt på tre konkrete punkter:</p> Content collections.</strong> En typet, skema-kontrolleret måde at beskrive et portfolio-projekt som en mappe med fotos plus lidt front-matter. Buildet fejler højlydt, hvis noget ikke overholder skemaet. Intet CMS nødvendigt.</li> <Image></code>-komponenten.</strong> Astros indbyggede billedpipeline håndterer AVIF + JPEG-fallback + srcset</code> + width</code>/height</code> med en one-liner. Sharp er motoren under.</li> Islands-arkitektur — ikke relevant her.</strong> Siden har ingen interaktive komponenter, så den sender stort set ingen JavaScript.</li> </ol> Content collections, ikke et CMS</h2> Hvert portfolio-projekt er en mappe under src/content/portfolio/</code> med et front-matter-skema:</p> src/content/portfolio/ ├── 2024-kogebogs-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-forarets-katalog/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code>’s front-matter deklarerer titel, kategori, år og forsidebillede. Astro håndhæver skemaet ved build-tid via defineCollection</code></a> med et Zod-skema. Hvis et projekt mangler et forsidebillede eller har en dårlig kategori, fejler buildet.</p> Kategorier: madfotografi, opskriftsudvikling, interiør- og haveproduktion, editorial, kogebøger og mode</strong>. At tilføje et nyt projekt er mkdir</code> + cp *.jpg</code> + en kort YAML-front-matter-blok. Ingen admin-UI, ingen database-migration, ingen cache at invalidere.</p> Billedpipeline: Sharp + AVIF</h2> Madfotografi står og falder med billedkvalitet. Astros <Image></code>-komponent — drevet af Sharp</a> — genererer:</p> AVIF</strong> som primært format. Stort set alle moderne browsere understøtter det nu (se caniuse</a>).</li> JPEG</strong>-fallback med matchende srcset</code>-breakpoints (320, 640, 960, 1280, 1920 px).</li> Eksplicitte width</code>- og height</code>-attributter, så der er nul layout shift, mens billederne loader.</li> loading="lazy"</code> til billeder under folden og fetchpriority="high"</code> til heroet.</li> </ul> Tal</strong>: en typisk portfolio-side gik fra ~4,8 MB håndeksporterede JPEG’er til ~1,4 MB AVIF — omkring 70 % reduktion — uden synligt kvalitetstab i de viste størrelser.</p> i18n — dansk som standard, engelsk på /en/</h2> Astros i18n-routing sidder i astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> Det giver:</p> /</code> for dansk (standard, uden præfiks).</li> /en/</code> for engelsk.</li> Hvert indholds-entry deklarerer sit sprog via sin collection og filnavn.</li> <link rel="alternate" hreflang></code> og sitemap genereres fra samme kilde.</li> </ul> Indlæg og portfolio-entries uden oversættelse dukker simpelthen ikke op i det andet sprogs routing — der er ingen forkert-sprog-404.</p> Deployment og build</h2> Output</strong>: fuldt statisk, udgivet som almindelige filer bag Cloudflare.</li> Build-tid</strong>: ~30 sekunder fra koldt cache, ~6 sekunder inkrementelt.</li> Ingen server, ingen database, ingen løbende kørselstid.</strong></li> </ul> Målbare forbedringer</h2> Mål</th> WordPress (før)</th> Astro (efter)</th></tr></thead> Build / deploy-tid</td> ikke relevant</td> ~30 s koldt, ~6 s varmt</td></tr> Typisk sidestørrelse (portfolio-side)</td> ~4,8 MB</td> ~1,4 MB</td></tr> Largest Contentful Paint</td> ~2,8 s</td> ~0,9 s</td></tr> Time to Interactive</td> ~3,5 s</td> ~1,1 s</td></tr> JS sendt til klienten</td> ~220 KB</td> ~0 KB</td></tr> Plugins at holde patchet</td> 14</td> 0</td></tr> </tbody></table> Ofte stillede spørgsmål</h2> Kan en ikke-teknisk ejer stadig redigere siden?</h3> Ja, til tekstændringer. At redigere Markdown i GitHubs web-editor er i praksis lettere end WordPress’ blok-editor. For nye portfolio-projekter er workflowet: træk billeder ind i en mappe, skriv en lille front-matter-blok, commit. Er det for teknisk, kan man bolte en minimal admin på (Decap CMS, Sveltia CMS eller Keystatic).</p> Hvad med SEO efter flytningen?</h3> URL’er blev bevaret, hvor det var muligt. Manglende gamle stier omdirigeres via Cloudflare-regler. Sitemap genereres ved hvert build, og strukturerede data (Person</code>, ImageGallery</code>, Article</code>) udsendes pr. side.</p> Hvorfor Astro og ikke Hugo?</h3> Hugo er hurtigere og simplere til ren blogging, men Astros typede content collections og førsteklasses <Image></code>-komponent vandt i det her tilfælde. Til x2q.net</a> selv endte jeg senere med Zola — men til en portfolio med tung billedpipeline var Astro det rigtige valg.</p> Hvordan holdes billederne organiseret?</h3> Hvert portfolio-projekt har sin egen mappe. Git-repoet er CMS’et. git log</code> fortæller, hvornår et billede blev tilføjet, og hvorfor.</p> Er buildet deterministisk?</h3> Ja. Samme input giver bit-for-bit identisk output. Sharp er pinned i package.json</code>; det samme er Astro. CI kører på Node LTS.</p> Hvis du sidder med et WordPress-site, der laver langt mindre, end dets infrastruktur antyder, er Astro en eftermiddag værd.</p> apextowww.com — gratis apex-til-www-omdirigering 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS tillader ikke CNAME</code>-records på zoneapex (RFC 1034 §3.6.2</a>). Det er derfor hostingplatforme som Netlify, Vercel, Cloudflare Pages, Firebase og Heroku beder dig om at sætte www.eksempel.dk</code> op med en CNAME</code> og lader eksempel.dk</code> (selve apex) være et problem, du selv løser. apextowww.com</a> løser det: peg to A</code>-records og to AAAA</code>-records mod tjenesten, og den udsteder et Let’s Encrypt-certifikat til dit apex og 301</code>-omdirigerer hver forespørgsel til https://www.ditdomæne.tld/</code> — med sti og querystring bevaret. Gratis, ingen oprettelse, ingen konto.</p> Hvorfor du ikke kan sætte en CNAME på apex</h2> DNS-specifikationen er entydig: en zoneapex (det “nøgne” domæne som eksempel.dk</code>) skal have en SOA</code>-record og som regel NS</code>-records. CNAME</code> er defineret som et alias, der skal stå alene — den må ikke sameksistere med de SOA</code>- og NS</code>-records, som apex er forpligtet til at have. Derfor kan du godt CNAME www.eksempel.dk → mitsite.netlify.app</code>, men du kan ikke</strong> CNAME eksempel.dk → mitsite.netlify.app</code>.</p> Der findes workarounds, og alle er en smule akavede:</p> ALIAS- / ANAME-records.</strong> Leverandørspecifikke hos Cloudflare, Route 53, DNSimple, NS1 og andre. De virker ved at slå målet op bag kulisserne og returnere en A</code>/AAAA</code>. Fint, hvis din DNS-udbyder understøtter det; ubrugeligt, hvis ikke.</li> Fladning på udbyderniveau.</strong> Cloudflares “CNAME flattening” er præcis det, gjort automatisk.</li> Din egen altid-tændte VPS med 301 → www</code>.</strong> Det var det, jeg gjorde for flere domæner — både overkill og en lille vedligeholdelsesskat.</li> </ul> apextowww er den fjerde mulighed: en andens altid-tændte omdirigerer, driftet for dig.</p> Hvad apextowww gør</h2> Nøjagtig én ting: en 301 Moved Permanently</code> fra https://ditdomæne.tld/noget?x=y</code> til https://www.ditdomæne.tld/noget?x=y</code>.</p> TLS</strong> udstedes automatisk ved første forespørgsel via Let’s Encrypts HTTP-01-challenge. Ingen ACME-klient at køre selv.</li> IPv4 + IPv6</strong> som dual-stack fra starten. Begge record-typer er påkrævet.</li> HTTP/1.1, HTTP/2 og HTTP/3</strong> serveres. Selve omdirigeringen er lille, så protokolversion betyder mindre, men det hjælper first-paint, når omdirigeringen ligger i den kritiske sti.</li> Sti og querystring</strong> bevares, så deep links stadig virker.</li> Ingen oprettelse, intet login, ingen konto.</strong> Hvis DNS er peget korrekt, virker det bare.</li> </ul> Sådan sætter du det op</h2> Gå til apextowww.com</a> og kopiér de aktuelle IP-adresser (to IPv4, to IPv6).</li> I din DNS-udbyder: sæt A</code>-records på dit apex, der peger på de to IPv4-adresser. Fjern eventuelle eksisterende A</code>-records på apex.</li> Sæt AAAA</code>-records på dit apex, der peger på de to IPv6-adresser.</li> Sørg for, at www.ditdomæne.tld</code> stadig peger på din rigtige host (CNAME til Netlify / Vercel / Pages / osv.).</li> Vent på DNS-propagering. Besøg http://ditdomæne.tld/</code> — den skal nu 301-omdirigere til https://www.ditdomæne.tld/</code>.</li> </ol> apextowww-siden har platform-specifikke guides under /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code> og /heroku-apex-domain-redirect/</code>.</p> Stak</h2> Hetzner ARM64</strong>-servere for billig, strømbesparende compute. ARM64 er ~30 % billigere pr. vCPU hos Hetzner end x86 og kører omdirigereren uden at ryste på hånden.</li> Caddy-agtig automatisk TLS</strong> med Let’s Encrypt</strong> HTTP-01-challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Offentligt statisk marketing-site</strong> på Cloudflare Pages, med platform-guides i hver sin URL-sti, så de rangerer uafhængigt på Google for “netlify apex redirect”, “vercel apex domain” osv.</li> </ul> Ofte stillede spørgsmål</h2> Kan jeg bruge apextowww sammen med Cloudflare DNS?</h3> Ja — men du skal have Cloudflares proxy (den orange sky) slået fra</strong> på apex’ens A</code>/AAAA</code>-records. Hvis proxien er slået til, opfanger Cloudflare forespørgslen, og Let’s Encrypts HTTP-01-challenge når aldrig frem til apextowww. Når certifikatet er udstedt og fornyes, skal du ikke bøvle videre — bare lad det være slukket.</p> Understøtter apextowww wildcards eller andre subdomæner end www?</h3> Nej. Tjenesten omdirigerer kun apex til www.</code>. Alt andet bliver liggende hos din rigtige host.</p> Hvad sker der, hvis apextowww-IP’erne skifter?</h3> Så skal du opdatere dine DNS A</code>/AAAA</code>-records. Operatøren offentliggør aktuelle IP’er på forsiden og giver varsel før ændringer. Det er fint for et privat domæne; for noget missionkritisk bør du køre din egen omdirigerer.</p> Er der rate-limit?</h3> Der er ingen publiceret hård grænse, men det er en gratis community-tjeneste. Hvis du serverer millioner af apex-omdirigeringer i døgnet, er det tid til at selv-hoste.</p> Hvorfor ikke bare bruge Cloudflares gratis plan?</h3> Cloudflares CNAME-flattening på apex er et fint alternativ, hvis hele din DNS er hos Cloudflare. apextowww er nyttig, når din DNS ikke er hos Cloudflare, eller når du vil have en host-agnostisk omdirigerer, der virker identisk på tværs af domæner.</p> Er den virkelig gratis?</h3> Ja. Marginalomkostningen pr. omdirigering på ARM64 er minimal. Ingen reklamer, ingen tracking ud over grundlæggende logs, ingen upsell.</p> Hvorfor den findes</h2> Hostingplatforme optimerer efter deres egen onboarding, ikke efter de DNS-selvfølgeligheder, der snubler enhver ny bruger. Det føltes værre at sende folk videre til en fremmeds VPS end selv at drifte én. Nu peger mine egne apex-domæner (inklusive x2q.net</a>) på apextowww, og jeg har kunnet slukke for den sidste lille omdirigerer-VPS, jeg stadig kørte af historiske grunde.</p> Det er den slags projekt, der ikke virker interessant, før du har brug for det — og så er det lige præcis det, du skal bruge.</p>