diff --git a/course/en/22-network-file-formats.md b/course/en/22-network-file-formats.md
new file mode 100644
index 0000000..2c5b0cb
--- /dev/null
+++ b/course/en/22-network-file-formats.md
@@ -0,0 +1,61 @@
+# Numbers in networks and file formats
+
+Network packets and binary files are sequences of bytes. Understanding them requires knowing which bytes form fields, the byte order of multi-byte values and the meaning assigned by the format.
+
+## PREDICT
+
+The bytes `12 34` form a 16-bit integer. Is the value `0x1234` or `0x3412`?
+
+It depends on the format's byte order.
+
+## STEP — network byte order
+
+Many multi-byte fields in Internet protocols use **network byte order**, which is big-endian. A 16-bit `0x1234` field is therefore transmitted as `12 34`.
+
+This does not require the host CPU itself to be big-endian. Protocol representation and native machine representation are separate concerns.
+
+## IPv4 and MAC addresses
+
+IPv4 is 32 bits. The familiar `192.168.1.10` corresponds to bytes `C0 A8 01 0A`.
+
+A common 48-bit MAC address can be displayed as six hexadecimal bytes, for example `02:12:34:56:78:9A`. Hexadecimal maps naturally to byte-oriented representations.
+
+## Protocol fields
+
+Packets may contain versions, lengths, types, flags, ports, sequence numbers, checksums and payloads. Some are bit fields; others are multi-byte integers. The protocol specification defines width, byte order and semantics.
+
+## Magic numbers and binary formats
+
+Binary formats often begin with characteristic signatures. For example, `89 50 4E 47 ...` begins with the signature bytes used by PNG.
+
+A signature can aid identification, but does not by itself prove that the rest of a file is structurally valid.
+
+## From hex dump to structure
+
+Consider a fictional record:
+
+`01 03 12 34 41 42 43`
+
+Its specification says byte 0 is a version, byte 1 a payload length, bytes 2–3 a big-endian ID and the remainder payload.
+
+The record therefore contains version 1, length 3, ID `0x1234`, and payload `41 42 43`, which can be interpreted as ASCII `ABC`.
+
+Without the specification these are simply seven bytes.
+
+## Offsets and lengths
+
+Binary parsers move through structures using field offsets and lengths. A field beginning at offset 4 with length 2 occupies bytes 4 and 5; the next field begins at offset 6.
+
+An incorrect width or offset shifts subsequent interpretation.
+
+## OBSERVE
+
+The same byte can be part of an IP address, character, flags, integer or opaque payload.
+
+## EXPLAIN
+
+A hex dump exposes stored or transmitted bytes. A format or protocol specification tells us how to group and interpret them.
+
+## Check yourself
+
+How is `0xBEEF` stored as a big-endian 16-bit field? Which bytes encode IPv4 `127.0.0.1`? Why is a magic number insufficient to validate an entire file?
diff --git a/course/no/22-nettverk-filformater.md b/course/no/22-nettverk-filformater.md
new file mode 100644
index 0000000..496fae7
--- /dev/null
+++ b/course/no/22-nettverk-filformater.md
@@ -0,0 +1,108 @@
+# Tall i nettverk og filformater
+
+Nettverkspakker og binære filer består av byte. For å forstå dem må vi vite hvilke byte som hører sammen, hvilken byteorden som brukes, og hva hvert felt betyr.
+
+## PREDICT
+
+Bytefølgen `12 34` representerer et 16-bit tall. Er verdien `0x1234` eller `0x3412`?
+
+Svaret er: det avhenger av formatets byteorden.
+
+## STEP — nettverksbyteorden
+
+Mange Internett-protokollfelt med flere byte bruker **network byte order**, som er big-endian.
+
+Et 16-bit felt med verdien `0x1234` ligger da som:
+
+`12 34`
+
+Dette betyr ikke at maskinen som sender eller mottar pakken selv må være big-endian. Protokollens representasjon og CPU-ens interne representasjon er separate spørsmål.
+
+## IPv4
+
+En IPv4-adresse er 32 bit og vises vanligvis som fire desimale oktetter.
+
+`192.168.1.10`
+
+tilsvarer byte:
+
+`C0 A8 01 0A`
+
+Punktnotasjonen er menneskevennlig; pakken inneholder byte.
+
+## MAC-adresser
+
+En vanlig 48-bit MAC-adresse skrives ofte som seks hex-byte:
+
+`02:12:34:56:78:9A`
+
+Her er hex spesielt nyttig fordi hvert byte kan skrives med nøyaktig to hex-sifre.
+
+## Protokollfelt
+
+En pakke kan inneholde:
+
+- versjon
+- lengde
+- type
+- flagg
+- portnummer
+- sekvensnummer
+- checksum
+- payload
+
+Noen felt er bitfelt. Andre er heltall over flere byte. Dokumentasjonen bestemmer bredde, byteorden og semantikk.
+
+## Magic numbers
+
+Binære filformater starter ofte med karakteristiske byte som hjelper programvare å identifisere formatet.
+
+For eksempel kan en fil begynne:
+
+`89 50 4E 47 ...`
+
+De fire første bytene er en signatur brukt av PNG-formatet. En signatur er nyttig identifikasjon, men alene beviser den ikke at resten av filen er gyldig.
+
+## Fra hex dump til struktur
+
+Tenk denne fiktive posten:
+
+`01 03 12 34 41 42 43`
+
+Formatet sier:
+
+- byte 0: versjon
+- byte 1: payload-lengde
+- byte 2–3: big-endian ID
+- resten: payload
+
+Da får vi:
+
+- versjon = 1
+- lengde = 3
+- ID = `0x1234`
+- payload = `41 42 43`, som kan tolkes som ASCII `ABC`
+
+Uten formatbeskrivelsen er dette bare sju byte.
+
+## Lengde og offsets
+
+Binære parsere arbeider ofte med offsets:
+
+`offset + field_length`
+
+Et felt som starter ved offset 4 og er 2 byte langt bruker byte 4 og 5. Neste felt starter ved offset 6.
+
+Feil bredde eller feil offset forskyver resten av tolkningen.
+
+## OBSERVE
+
+Samme byte kan representere del av en IP-adresse, et tegn, et flaggfelt, et heltall eller rå payload.
+
+## EXPLAIN
+
+Hex dumpen viser lagrede eller overførte byte. Format- eller protokollspesifikasjonen forteller hvordan byte skal grupperes og tolkes.
+
+## Sjekk deg selv
+
+Hvordan lagres `0xBEEF` som et big-endian 16-bit felt? Hvilke byte representerer IPv4-adressen `127.0.0.1`? Hvorfor er en magic number ikke nok til å validere en hel fil?
diff --git a/exercises/no/11-nettverk-filformater.md b/exercises/no/11-nettverk-filformater.md
new file mode 100644
index 0000000..5de6651
--- /dev/null
+++ b/exercises/no/11-nettverk-filformater.md
@@ -0,0 +1,10 @@
+# Øvelser: nettverk og filformater
+
+1. Skriv `0xCAFE` som to byte i big-endian og little-endian.
+2. Skriv IPv4-adressen `10.0.0.42` som fire hex-byte.
+3. Hvor mange bit og byte inneholder en vanlig 48-bit MAC-adresse?
+4. Et big-endian 16-bit felt inneholder `01 F4`. Hva er verdien i desimal?
+5. I posten `02 02 BE EF 48 69` betyr byte 0 versjon, byte 1 lengde, byte 2–3 big-endian ID og resten payload. Tolk posten.
+6. Et felt starter ved offset 8 og er 4 byte langt. Hvilke offsets bruker det, og hvor starter neste felt?
+7. Hvorfor kan samme hex dump få forskjellige tolkninger?
+8. Hvorfor bør en parser validere mer enn bare filens signatur?
diff --git a/solutions/no/11-nettverk-filformater.md b/solutions/no/11-nettverk-filformater.md
new file mode 100644
index 0000000..635720c
--- /dev/null
+++ b/solutions/no/11-nettverk-filformater.md
@@ -0,0 +1,10 @@
+# Løsninger: nettverk og filformater
+
+1. Big-endian: `CA FE`. Little-endian: `FE CA`.
+2. `0A 00 00 2A`.
+3. 48 bit = 6 byte.
+4. `0x01F4 = 500`.
+5. Versjon 2, payload-lengde 2, ID `0xBEEF`, payload `48 69`, som i ASCII er `Hi`.
+6. Offset 8, 9, 10 og 11. Neste felt starter ved offset 12.
+7. Byte har ikke komplett semantikk alene; format/protokoll bestemmer feltdeling, type, bredde, byteorden og mening.
+8. En signatur identifiserer bare noen karakteristiske byte. Lengder, strukturer, feltverdier og resten av innholdet kan fortsatt være ugyldig eller avkortet.