M11: debugging and reverse engineering

course/en/23-debugging-reverse-engineering.md

@@ -0,0 +1,63 @@
+# Numbers in debugging and reverse engineering
+
+When software crashes, a file is undocumented or an old system lacks specifications, raw bytes may appear before their structure is known. Number representation becomes an analysis tool.
+
+## PREDICT
+
+You find the bytes `48 65 6C 6C 6F 00`. Are they integers, machine code or text?
+
+Without context, several interpretations may be possible. As ASCII/UTF-8 they resemble `Hello` followed by a zero byte.
+
+## STEP — observe before assuming
+
+Separate observations from hypotheses. A hex editor or memory dump may show offsets or addresses, hexadecimal bytes, a text column and highlighted regions.
+
+Readable characters are evidence worth investigating, not proof that a field is text.
+
+## Recognizing patterns
+
+Useful observations include repeated zeros, recurring values, text-like sequences, possible lengths or offsets, known signatures, regular blocks and bit fields whose bits change predictably.
+
+A hypothesis becomes stronger when it explains multiple independent examples.
+
+## Integers, addresses and offsets
+
+Bytes `34 12` may represent big-endian `0x3412` or little-endian `0x1234`.
+
+If the field is hypothesized to be a length, test whether that value agrees with the surrounding structure.
+
+Debugger addresses are commonly hexadecimal. Address differences reveal sizes: `0x1040 - 0x1000 = 0x40 = 64`.
+
+## Disassembly
+
+A disassembler interprets bytes as instructions for a selected CPU and starting point. That does not prove those bytes are executable code.
+
+Data can decode into syntactically valid but meaningless instructions. Ask whether the CPU and start address are known, whether control flow reaches the region, whether the sequence is plausible and whether the bytes might instead be data.
+
+## Code and data
+
+Code, tables, strings and constants may live close together. `41 42 43 44` could be ASCII `ABCD`, four integers, portions of larger values or instruction bytes. Context determines the useful interpretation.
+
+## Reconstructing a possible structure
+
+Consider the fictional bytes `03 00 08 00 41 42 43 00`.
+
+One hypothesis is type 3, flags 0, a little-endian length of 8 and four data bytes. This is a model, not yet a fact. Comparing additional records can test whether those fields behave consistently.
+
+## Change one thing
+
+With systems and test data you control, changing one known value at a time and comparing before and after is powerful.
+
+If enabling a flag changes exactly one bit, that is useful evidence. If changing a counter tracks one field, its representation becomes clearer.
+
+## OBSERVE
+
+Data reverse engineering is often a process of constructing hypotheses that can be weakened or strengthened rather than instantly guessing the correct format.
+
+## EXPLAIN
+
+Bases, signedness, byte order, bit fields, addresses and text encodings make raw bytes easier to reason about. Context and repeated observations distinguish plausible interpretation from documented structure.
+
+## Check yourself
+
+Why can data produce apparently valid disassembly? What could `00 01` mean under different byte orders? Why are multiple examples more useful than one dump when reconstructing a structure?

course/no/23-debugging-reverse-engineering.md

@@ -0,0 +1,111 @@
+# Tall i debugging og reverse engineering
+
+Når et program krasjer, en fil er ukjent eller et gammelt system mangler dokumentasjon, møter vi ofte rå byte før vi kjenner strukturen. Tallrepresentasjon blir da et analyseverktøy.
+
+## PREDICT
+
+Du finner bytene:
+
+`48 65 6C 6C 6F 00`
+
+Er dette seks heltall, maskinkode eller tekst?
+
+Uten kontekst kan flere tolkninger være mulige. Som ASCII/UTF-8 ser de ut som `Hello` etterfulgt av en nullbyte.
+
+## STEP — start med observasjon
+
+Skill mellom det du **ser** og det du **antar**.
+
+En hex-editor eller memory dump kan vise:
+
+- offset eller adresse
+- byte i hex
+- en tekstkolonne
+- markerte områder eller endringer
+
+At en tekstkolonne viser lesbare tegn er et spor, ikke et bevis på at feltet faktisk er tekst.
+
+## Gjenkjenn mønstre
+
+Nyttige observasjoner kan være:
+
+- mange nullbyte
+- repeterende verdier
+- sekvenser som ligner tekst
+- verdier som ligner lengder eller offsets
+- kjente signaturer
+- regelmessige blokker
+- bitfelt med stabile og skiftende bit
+
+Hypoteser bør testes mot flere eksempler.
+
+## Heltall i en dump
+
+Bytene
+
+`34 12`
+
+kan være `0x3412` som big-endian eller `0x1234` som little-endian.
+
+Hvis en hypotese sier at feltet er en lengde, kan vi kontrollere om verdien passer med resten av datastrukturen.
+
+## Adresser og offsets
+
+Debuggere viser ofte adresser i hex. Forskjellen mellom to adresser er en størrelse:
+
+`0x1040 - 0x1000 = 0x40 = 64`
+
+Dette er nyttig når vi undersøker buffere, tabeller og strukturer.
+
+## Disassembly
+
+En disassembler tolker byte som instruksjoner for en bestemt CPU og et bestemt startpunkt.
+
+Det betyr ikke automatisk at alle viste byte faktisk er kode. Data som tolkes som instruksjoner kan produsere syntaktisk gyldig, men meningsløs disassembly.
+
+Spør derfor:
+
+- kjenner vi CPU/ISA?
+- kjenner vi riktig startadresse?
+- peker kontrollflyt hit?
+- ser instruksjonssekvensen plausibel ut?
+- kan området i stedet være data?
+
+## Kode og data
+
+I eldre og innebygde systemer kan kode, tabeller, strenger og konstanter ligge tett sammen.
+
+En sekvens som `41 42 43 44` kan være teksten `ABCD`, fire små heltall, deler av større tall eller instruksjonsbyte. Kontekst avgjør.
+
+## Rekonstruer en mulig struktur
+
+Tenk denne fiktive dumpen:
+
+`03 00 08 00 41 42 43 00`
+
+En hypotese kan være:
+
+- byte 0: type = 3
+- byte 1: flagg = 0
+- byte 2–3: little-endian lengde = 8
+- byte 4–7: data
+
+Dette er foreløpig bare en modell. Vi styrker den ved å undersøke flere poster og se om feltene oppfører seg konsekvent.
+
+## Endre én ting
+
+En effektiv metode i egne systemer og testdata er å endre én kjent verdi om gangen og sammenligne før/etter.
+
+Hvis et flagg slås på og nøyaktig én bit endres, har vi et godt spor. Hvis en teller økes og et bestemt felt følger den, lærer vi mer om representasjonen.
+
+## OBSERVE
+
+Reverse engineering av data handler ofte mindre om å «gjette riktig» med én gang og mer om å formulere hypoteser som kan motbevises eller styrkes.
+
+## EXPLAIN
+
+Kunnskap om baser, signedness, byteorden, bitfelt, adresser og tekstkoding gjør rå byte lesbare. Men kontekst og flere observasjoner er nødvendig for å skille en plausibel tolkning fra en dokumentert struktur.
+
+## Sjekk deg selv
+
+Hvorfor kan disassembly av data se ut som gyldig kode? Hva kan `00 01` bety under ulike byteordener? Hvorfor er flere eksempler bedre enn én dump når vi prøver å finne en struktur?

exercises/no/12-debugging-reverse-engineering.md

@@ -0,0 +1,10 @@
+# Øvelser: debugging og reverse engineering
+
+1. Tolk `48 69 00` som ASCII der det er mulig.
+2. Tolk `78 56 34 12` som et 32-bit little-endian heltall.
+3. En buffer starter på `0x2000` og slutter rett før `0x2080`. Hvor stor er den?
+4. Nevn tre mulige forklaringer på bytefølgen `41 42 43 44`.
+5. Hvorfor beviser ikke en disassembler-listing at et område er kode?
+6. To nesten identiske testfiler skiller seg bare ved at byte `0x20` endres fra `04` til `05` når en teller økes fra 4 til 5. Hva kan vi foreløpig anta, og hva vet vi fortsatt ikke?
+7. Hvorfor er en feltverdi som passer én dump ikke nok til å fastslå et filformat?
+8. Lag en mulig feltinndeling for `01 02 04 00 DE AD BE EF`, men marker tydelig hvilke deler som er hypotese.

solutions/no/12-debugging-reverse-engineering.md

@@ -0,0 +1,10 @@
+# Løsninger: debugging og reverse engineering
+
+1. `48 69` er ASCII `Hi`; `00` er en nullbyte.
+2. `0x12345678`.
+3. `0x2080 - 0x2000 = 0x80 = 128` byte.
+4. For eksempel ASCII `ABCD`, fire 8-bit heltall, deler av større heltall eller instruksjonsbyte.
+5. En disassembler forsøker å dekode de valgte bytene som instruksjoner. Mange datastrømmer kan tilfeldigvis gi gyldige instruksjonskodinger.
+6. Endringen støtter hypotesen om at feltet ved offset `0x20` representerer telleren. Vi vet ennå ikke nødvendigvis feltbredde, signedness, om verdien er direkte kodet eller om andre verdier påvirker feltet.
+7. Flere forskjellige strukturer kan forklare ett eksempel. Flere kontrollerte eksempler kan avsløre hvilke hypoteser som faktisk holder.
+8. Én mulig hypotese er type=`01`, flagg=`02`, little-endian lengde=`04 00`, data=`DE AD BE EF`. Dette er bare én mulig modell inntil formatet eller flere observasjoner bekrefter den.