Section 1: Critical Overview - IoT Forensics Priorities
⚠️ CRITICAL UNDERSTANDING:
IoT devices are FUNDAMENTALLY DIFFERENT from computers/phones
KEY DIFFERENCE:
• Most IoT data is stored IN THE CLOUD, NOT on the device
• Physical device seizure alone = INCOMPLETE evidence
• Cloud data preservation = PRIMARY PRIORITY
• Time-critical: User can delete cloud data remotely
IoT devices are FUNDAMENTALLY DIFFERENT from computers/phones
KEY DIFFERENCE:
• Most IoT data is stored IN THE CLOUD, NOT on the device
• Physical device seizure alone = INCOMPLETE evidence
• Cloud data preservation = PRIMARY PRIORITY
• Time-critical: User can delete cloud data remotely
↓
IoT Evidence Has 4 Components (ALL REQUIRED):
1. Physical IoT Devices (cameras, locks, hubs, routers)
→ Local storage (if present - microSD cards)
→ Device configurations
→ Local logs (limited)
2. Cloud Accounts (Amazon, Google, Ring, Nest) ⭐ PRIMARY
→ Video recordings (cameras)
→ Audio recordings (voice assistants)
→ Access logs (smart locks)
→ Device activity history
3. Companion Mobile Apps (smartphone with IoT apps)
→ Device configurations
→ Cached data (thumbnails, notifications)
→ Account credentials
→ Automation rules
4. Network Infrastructure (router, hub)
→ Device connection logs
→ Network activity
→ Ecosystem configuration
1. Physical IoT Devices (cameras, locks, hubs, routers)
→ Local storage (if present - microSD cards)
→ Device configurations
→ Local logs (limited)
2. Cloud Accounts (Amazon, Google, Ring, Nest) ⭐ PRIMARY
→ Video recordings (cameras)
→ Audio recordings (voice assistants)
→ Access logs (smart locks)
→ Device activity history
3. Companion Mobile Apps (smartphone with IoT apps)
→ Device configurations
→ Cached data (thumbnails, notifications)
→ Account credentials
→ Automation rules
4. Network Infrastructure (router, hub)
→ Device connection logs
→ Network activity
→ Ecosystem configuration
🚨 EVIDENCE LOSS RISK:
Cloud data can be deleted by user REMOTELY - Even after device seized!Timeline:
• Ring/Nest recordings: 30-60 days retention (then auto-deleted)
• Alexa recordings: User can delete anytime
• Smart lock logs: Varies by manufacturer
ACTION REQUIRED: Submit cloud preservation requests SAME DAY as investigation starts (ideally BEFORE scene entry)
Section 2: Cloud Data Preservation (Budapest Convention Article 16)
IoT Cloud Data = PRIMARY EVIDENCE SOURCE
↓
⚡ IMMEDIATE ACTION REQUIRED:
Submit emergency preservation requests to cloud providers
Common IoT Cloud Providers:
• Amazon (Alexa, Ring, Blink) - USA servers
• Google (Nest, Google Home) - USA servers
• Wyze - USA/China servers
• Arlo - USA servers
• Eufy (Anker) - China/Hong Kong servers
• TP-Link - China servers
• Samsung (SmartThings) - South Korea servers
• Apple (Whatch, Tag, Homepod ) - USA servers
Submit emergency preservation requests to cloud providers
Common IoT Cloud Providers:
• Amazon (Alexa, Ring, Blink) - USA servers
• Google (Nest, Google Home) - USA servers
• Wyze - USA/China servers
• Arlo - USA servers
• Eufy (Anker) - China/Hong Kong servers
• TP-Link - China servers
• Samsung (SmartThings) - South Korea servers
• Apple (Whatch, Tag, Homepod ) - USA servers
↓
Is cloud data stored in a foreign country?
(Most IoT providers = USA, China, South Korea)
(Most IoT providers = USA, China, South Korea)
YES - Cross-Border Data
↓
Budapest Convention Applies
Articles 32 & 16
Articles 32 & 16
↓
THREE LEGAL PATHWAYS:
Article 32.a - Public Data:
• Data publicly accessible
• NO foreign authorization needed
• RARE for IoT (most data private)
Article 32.b - Consent:
• User provides written consent
• NO foreign authorization needed
• Faster (days to weeks)
Article 16 - Preservation + MLAT:
• NO consent - standard investigation
• Step 1: Preservation (90-180 days)
• Step 2: MLAT for production (months/years)
• MOST COMMON pathway
Article 32.a - Public Data:
• Data publicly accessible
• NO foreign authorization needed
• RARE for IoT (most data private)
Article 32.b - Consent:
• User provides written consent
• NO foreign authorization needed
• Faster (days to weeks)
Article 16 - Preservation + MLAT:
• NO consent - standard investigation
• Step 1: Preservation (90-180 days)
• Step 2: MLAT for production (months/years)
• MOST COMMON pathway
NO - Domestic Data
↓
National Rules Only
• National authorization (warrant)
• No Budapest Convention
• Submit to provider directly
• National authorization (warrant)
• No Budapest Convention
• Submit to provider directly
📋 IMPORTANT - National Rules ALWAYS Apply:
Regardless of Budapest Convention pathway, national legal authorization is ALWAYS required (your country's warrant/court order).Budapest Convention addresses foreign state authorization, NOT national authorization.
↓
DETAILED BUDAPEST CONVENTION PATHWAYS
See Section 3 below for complete procedures
See Section 3 below for complete procedures
Section 3: Budapest Convention - Three Legal Pathways
Article 32.a - Public Data
WHEN TO USE:
• Data publicly accessible
• Anyone can view without login
EXAMPLES:
• Public social media posts
• Public device data
RARE FOR IoT:
Most IoT data is private:
• Camera recordings (private)
• Lock access logs (private)
• Voice recordings (private)
• Data publicly accessible
• Anyone can view without login
EXAMPLES:
• Public social media posts
• Public device data
RARE FOR IoT:
Most IoT data is private:
• Camera recordings (private)
• Lock access logs (private)
• Voice recordings (private)
↓
PROCEDURE:
✅ NO foreign authorization
✅ National authorization required
✅ Access data directly
✅ NO foreign authorization
✅ National authorization required
✅ Access data directly
Article 32.b - Consent
WHEN TO USE:
• Device owner provides written consent
• Voluntary cooperation
REQUIREMENTS:
1. Account owner (not just device user)
2. Written consent form
3. Voluntary (no coercion)
4. Informed (understands what data)
5. Witnessed (contradictory procedure)
• Device owner provides written consent
• Voluntary cooperation
REQUIREMENTS:
1. Account owner (not just device user)
2. Written consent form
3. Voluntary (no coercion)
4. Informed (understands what data)
5. Witnessed (contradictory procedure)
↓
PROCEDURE:
1. Obtain signed consent form:
• Specify accounts (Amazon, Google, Ring, etc.)
• Specify data types (video, audio, logs)
• Witnesses present
• Date/time recorded
2. National authorization (may still be required)
3. Submit to provider:
• Attach consent form
• Reference Article 32.b
• NO foreign authorization needed
4. Provider produces data (days-weeks)
✅ FASTER than MLAT
✅ NO foreign authorization needed
1. Obtain signed consent form:
• Specify accounts (Amazon, Google, Ring, etc.)
• Specify data types (video, audio, logs)
• Witnesses present
• Date/time recorded
2. National authorization (may still be required)
3. Submit to provider:
• Attach consent form
• Reference Article 32.b
• NO foreign authorization needed
4. Provider produces data (days-weeks)
✅ FASTER than MLAT
✅ NO foreign authorization needed
Article 16 - MLAT (MOST COMMON)
WHEN TO USE:
• Data NOT public
• NO consent
• Standard investigation
TWO-STEP PROCEDURE:
Step 1: Preservation (temporary)
Step 2: MLAT (production)
• Data NOT public
• NO consent
• Standard investigation
TWO-STEP PROCEDURE:
Step 1: Preservation (temporary)
Step 2: MLAT (production)
↓
STEP 1: Article 16.1
Expedited Preservation
• Submit to provider (Amazon, Google, etc.)
• Provider PRESERVES data (does NOT produce yet)
• Duration: 90 days (renewable once = max 180 days)
• Prevents deletion while waiting for MLAT
• Reference: Budapest Convention Article 16
⏰ TIME LIMIT: 90-180 days maximum
Expedited Preservation
• Submit to provider (Amazon, Google, etc.)
• Provider PRESERVES data (does NOT produce yet)
• Duration: 90 days (renewable once = max 180 days)
• Prevents deletion while waiting for MLAT
• Reference: Budapest Convention Article 16
⏰ TIME LIMIT: 90-180 days maximum
↓
STEP 2: Article 16.2
MLAT Request for Production
1. National authorization FIRST:
• Warrant (content: video, audio)
• Subpoena (non-content: subscriber info)
2. Prepare MLAT request:
• Case details
• Account identifier
• Data requested (specific)
• Legal justification
• National authorization reference
• Preservation reference
3. Submit to competent authority:
• Ministry of Justice / Prosecutor General
• Sent to foreign state (USA, China, etc.)
• Via diplomatic channels
4. Foreign state processes:
• Reviews under their law
• Issues foreign authorization
• ⏰ TIMELINE: MONTHS to YEARS (slow)
5. Submit to provider with foreign authorization
6. Provider produces data
MLAT Request for Production
1. National authorization FIRST:
• Warrant (content: video, audio)
• Subpoena (non-content: subscriber info)
2. Prepare MLAT request:
• Case details
• Account identifier
• Data requested (specific)
• Legal justification
• National authorization reference
• Preservation reference
3. Submit to competent authority:
• Ministry of Justice / Prosecutor General
• Sent to foreign state (USA, China, etc.)
• Via diplomatic channels
4. Foreign state processes:
• Reviews under their law
• Issues foreign authorization
• ⏰ TIMELINE: MONTHS to YEARS (slow)
5. Submit to provider with foreign authorization
6. Provider produces data
↓
⚠️ TIMELINE PROBLEM:
• Preservation expires: 90-180 days
• MLAT can take longer: Months to years
SOLUTION:
• Request preservation renewal OR
• Expedite MLAT (urgent cases, foreign liaison)
• Preservation expires: 90-180 days
• MLAT can take longer: Months to years
SOLUTION:
• Request preservation renewal OR
• Expedite MLAT (urgent cases, foreign liaison)
⚡ CRITICAL DISTINCTION:
Preservation ≠ Production• Preservation (Article 16.1): Provider freezes data, does NOT give it to you yet (covert - user NOT notified)
• Production (Article 16.2 via MLAT): Provider delivers data to you (requires foreign state authorization)
You MUST complete BOTH steps to obtain cloud data.
Section 4: IoT Device Access - Three Legal Scenarios
IoT Device Seized (Locked/Password-Protected)
↓
IoT Devices That May Be Locked:
• Smart locks (PIN/password protected configuration access)
• Smart home hubs (password-protected admin panels)
• Smart cameras (password-protected web interfaces)
• Smart TVs (account-protected apps, parental controls)
• Wearables (PIN/password protected device settings)
• Router admin panels (password protected)
• Voice assistants (voice profile recognition)
• Smart locks (PIN/password protected configuration access)
• Smart home hubs (password-protected admin panels)
• Smart cameras (password-protected web interfaces)
• Smart TVs (account-protected apps, parental controls)
• Wearables (PIN/password protected device settings)
• Router admin panels (password protected)
• Voice assistants (voice profile recognition)
↓
THREE LEGAL SCENARIOS FOR ACCESS
(Choose based on legal situation)
(Choose based on legal situation)
SCENARIO 1: Written Consent
LEGAL BASIS:
Budapest Convention Article 32.b
WHEN TO USE:
• Device owner provides written voluntary consent
• Voluntary cooperation
LEGAL EFFECT:
Full voluntary cooperation
Budapest Convention Article 32.b
WHEN TO USE:
• Device owner provides written voluntary consent
• Voluntary cooperation
LEGAL EFFECT:
Full voluntary cooperation
↓
PROCEDURE:
1. Obtain written consent form:
• Consent to unlock IoT devices
• Consent to access cloud accounts
• Specify devices covered (hub, camera, lock, etc.)
• Specify data types (configs, logs, cloud data)
• Person signs voluntarily
• Witnesses present (contradictory procedure)
• Date, time, location recorded
2. Request device owner to provide:
• Device passwords/PINs (hub admin password, camera password, smart lock codes)
• Cloud account credentials (or just consent form for cloud request)
• Voice profile cooperation (if voice assistant recognition needed)
3. Document:
• Written consent form (original)
• Credentials documented (written or verbal)
• Witnesses present
4. Network isolate device (Airplane Mode, Faraday bag, or disconnect internet at router)
5. Access device using provided credentials:
• Smart hub admin panel
• Smart camera web interface
• Smart lock configuration (via app or USB)
• Router admin panel
6. Export:
• Configurations
• Logs
• Local data (if any)
7. Cloud data access:
• Submit legal request with consent form
• Budapest Article 32.b
• NO foreign authorization needed
1. Obtain written consent form:
• Consent to unlock IoT devices
• Consent to access cloud accounts
• Specify devices covered (hub, camera, lock, etc.)
• Specify data types (configs, logs, cloud data)
• Person signs voluntarily
• Witnesses present (contradictory procedure)
• Date, time, location recorded
2. Request device owner to provide:
• Device passwords/PINs (hub admin password, camera password, smart lock codes)
• Cloud account credentials (or just consent form for cloud request)
• Voice profile cooperation (if voice assistant recognition needed)
3. Document:
• Written consent form (original)
• Credentials documented (written or verbal)
• Witnesses present
4. Network isolate device (Airplane Mode, Faraday bag, or disconnect internet at router)
5. Access device using provided credentials:
• Smart hub admin panel
• Smart camera web interface
• Smart lock configuration (via app or USB)
• Router admin panel
6. Export:
• Configurations
• Logs
• Local data (if any)
7. Cloud data access:
• Submit legal request with consent form
• Budapest Article 32.b
• NO foreign authorization needed
↓
RESULT:
✅ Full device access (configs, logs)
✅ Full cloud access (Article 32.b)
✅ Complete extraction possible
✅ Credentials provided voluntarily
✅ NO Article 37 issue (voluntary cooperation)
✅ Full device access (configs, logs)
✅ Full cloud access (Article 32.b)
✅ Complete extraction possible
✅ Credentials provided voluntarily
✅ NO Article 37 issue (voluntary cooperation)
SCENARIO 2: Live Exam
LEGAL BASIS:
Contradictory Process
Article 37 Albanian CPC applies
WHEN TO USE:
• Device owner does NOT consent to provide credentials
• Live examination authorized
LEGAL EFFECT:
Live examination ONLY in owner's presence
Limited access to visible data
NO credential extraction for cloud
Contradictory Process
Article 37 Albanian CPC applies
WHEN TO USE:
• Device owner does NOT consent to provide credentials
• Live examination authorized
LEGAL EFFECT:
Live examination ONLY in owner's presence
Limited access to visible data
NO credential extraction for cloud
↓
Article 37 Albanian CPC COMPLIANCE:
Before asking for passwords/credentials:
1. Assess if person is defendant
2. If not defendant + question could incriminate:
→ Issue Article 37 warning:
• "Investigation may be carried out"
• "Right to lawyer"
• "Lawyer present during questioning"
3. If lawyer requested:
→ SUSPEND all questioning
4. Statements before warning = INADMISSIBLE
Before asking for passwords/credentials:
1. Assess if person is defendant
2. If not defendant + question could incriminate:
→ Issue Article 37 warning:
• "Investigation may be carried out"
• "Right to lawyer"
• "Lawyer present during questioning"
3. If lawyer requested:
→ SUSPEND all questioning
4. Statements before warning = INADMISSIBLE
↓
CRITICAL:
Network isolate device IMMEDIATELY
(Prevent remote wipe, data modification)
Network isolate device IMMEDIATELY
(Prevent remote wipe, data modification)
↓
PROCEDURE:
1. Perform live examination in device owner's presence:
• Contradictory procedure (owner present, witnesses present)
• If owner voluntarily operates device (shows configurations, data): Document visible data on screen
• Examiner photographs/screenshots visible information
• Owner controls device (examiner observes and documents)
2. LIMITATION:
❌ Cannot compel owner to provide credentials for full extraction
❌ Can observe what owner voluntarily shows
❌ Cannot extract data without credentials
❌ Cannot access cloud accounts without consent
3. Document:
• Live examination performed (contradictory)
• Screens photographed
• Data observed
• Owner cooperation (voluntary showing of data)
• Credentials NOT provided (no compulsion)
1. Perform live examination in device owner's presence:
• Contradictory procedure (owner present, witnesses present)
• If owner voluntarily operates device (shows configurations, data): Document visible data on screen
• Examiner photographs/screenshots visible information
• Owner controls device (examiner observes and documents)
2. LIMITATION:
❌ Cannot compel owner to provide credentials for full extraction
❌ Can observe what owner voluntarily shows
❌ Cannot extract data without credentials
❌ Cannot access cloud accounts without consent
3. Document:
• Live examination performed (contradictory)
• Screens photographed
• Data observed
• Owner cooperation (voluntary showing of data)
• Credentials NOT provided (no compulsion)
↓
If live examination insufficient:
Proceed to Scenario 3 (Technical Bypass)
Proceed to Scenario 3 (Technical Bypass)
↓
RESULT:
✅ Live examination only (what owner shows)
❌ NO full device access (credentials not obtained)
❌ NO cloud access (no consent = MLAT required)
❌ NO extraction (limited to photographs/screenshots)
✅ Article 37 compliant (no compulsion)
✅ Live examination only (what owner shows)
❌ NO full device access (credentials not obtained)
❌ NO cloud access (no consent = MLAT required)
❌ NO extraction (limited to photographs/screenshots)
✅ Article 37 compliant (no compulsion)
SCENARIO 3: Technical Bypass
LEGAL BASIS:
Technical Method (Laboratory)
WHEN TO USE:
• No consent
• No live examination cooperation
• OR live examination insufficient
LEGAL EFFECT:
NO Article 37 issue (subject not asked to provide anything)
Pure technical method
Technical Method (Laboratory)
WHEN TO USE:
• No consent
• No live examination cooperation
• OR live examination insufficient
LEGAL EFFECT:
NO Article 37 issue (subject not asked to provide anything)
Pure technical method
↓
PROCEDURE:
1. Device transported to forensic laboratory
• In network-isolated state (Faraday bag or disconnected)
2. Technical bypass methods used:
A. Default Credentials
• Many IoT devices use default passwords
• Check manufacturer documentation
• Common: "admin/admin", "admin/password", "root/root", device serial number
B. Firmware Extraction and Analysis
• Extract firmware via UART, JTAG, or chip-off
• Analyze for stored credentials (often in cleartext)
• Use extracted credentials to access device
C. Network Sniffing
• Capture device network traffic (isolated environment)
• Some devices transmit credentials in cleartext (HTTP)
D. Exploit Known Vulnerabilities
• Check for published vulnerabilities
• Use forensic exploits (if legal and authorized)
E. Manufacturer Assistance
• Request manufacturer technical support
• Some provide "forensic mode" or backdoor access (rare)
3. After bypass successful:
• Access device admin panel, web interface, or configuration mode
• Export configurations, logs, local data
• Document bypass method used
• Document time taken
4. Cloud data:
• Bypass does NOT provide cloud access
• Still requires legal process (preservation + MLAT if no consent)
1. Device transported to forensic laboratory
• In network-isolated state (Faraday bag or disconnected)
2. Technical bypass methods used:
A. Default Credentials
• Many IoT devices use default passwords
• Check manufacturer documentation
• Common: "admin/admin", "admin/password", "root/root", device serial number
B. Firmware Extraction and Analysis
• Extract firmware via UART, JTAG, or chip-off
• Analyze for stored credentials (often in cleartext)
• Use extracted credentials to access device
C. Network Sniffing
• Capture device network traffic (isolated environment)
• Some devices transmit credentials in cleartext (HTTP)
D. Exploit Known Vulnerabilities
• Check for published vulnerabilities
• Use forensic exploits (if legal and authorized)
E. Manufacturer Assistance
• Request manufacturer technical support
• Some provide "forensic mode" or backdoor access (rare)
3. After bypass successful:
• Access device admin panel, web interface, or configuration mode
• Export configurations, logs, local data
• Document bypass method used
• Document time taken
4. Cloud data:
• Bypass does NOT provide cloud access
• Still requires legal process (preservation + MLAT if no consent)
↓
ADVANCED HARDWARE METHODS:
If software bypass fails:
→ JTAG Forensics (Section 5 below)
→ Chip-Off Forensics (Section 6 below)
If software bypass fails:
→ JTAG Forensics (Section 5 below)
→ Chip-Off Forensics (Section 6 below)
↓
RESULT:
✅ Full device access (after bypass)
✅ Configurations, logs, local data extracted
❌ NO cloud access (still need MLAT if no consent)
✅ NO Article 37 issue (no subject interaction)
✅ Complete extraction possible (device only)
✅ Full device access (after bypass)
✅ Configurations, logs, local data extracted
❌ NO cloud access (still need MLAT if no consent)
✅ NO Article 37 issue (no subject interaction)
✅ Complete extraction possible (device only)
📊 Summary - Three Distinct Approaches:
| Scenario | Consent | Credentials Provided | Full Device Access | Cloud Access | Legal Basis |
|---|---|---|---|---|---|
| 1. Written Consent | ✅ YES | ✅ YES (voluntary) | ✅ YES | ✅ YES (Article 32.b) | Budapest 32.b |
| 2. Live Exam | ❌ NO | ❌ NO (observe only) | ❌ NO (live only) | ❌ NO | Contradictory process |
| 3. Technical Bypass | ❌ NO | ❌ NO (bypass) | ✅ YES (device only) | ❌ NO (need MLAT) | Technical method |
Key Difference from Mobile Phones: IoT devices generally lack biometric unlock (most use passwords/PINs), so Scenario 2 (Live Exam) is limited to observing what owner voluntarily shows. Mobile phones have biometric option (jurisdiction-dependent) for live exam.
Section 5: Advanced Laboratory Technique - JTAG Forensics
JTAG = Hardware Interface for Memory Extraction
↓
WHAT IS JTAG?
JTAG (Joint Test Action Group) is a hardware interface standard (IEEE 1149.1) originally designed for testing circuit boards.
Forensic Use: Direct access to device's processor and memory, bypassing software protections.
Capabilities:
• Extract RAM contents (volatile memory - encryption keys!)
• Extract flash storage (non-volatile - file systems, firmware)
• Bypass password/access controls (software-level protections bypassed)
• Recover data from locked devices
JTAG (Joint Test Action Group) is a hardware interface standard (IEEE 1149.1) originally designed for testing circuit boards.
Forensic Use: Direct access to device's processor and memory, bypassing software protections.
Capabilities:
• Extract RAM contents (volatile memory - encryption keys!)
• Extract flash storage (non-volatile - file systems, firmware)
• Bypass password/access controls (software-level protections bypassed)
• Recover data from locked devices
↓
WHEN TO USE JTAG:
✅ IoT device has accessible JTAG interface (test points or header on PCB)
✅ Device is password-protected and software bypass failed
✅ Device has encryption, and JTAG may access keys in RAM
✅ Device is functional but locked
✅ Faster than chip-off (minutes to hours vs. hours to days)
IoT Devices with JTAG:
• Routers (very common - JTAG headers for debugging)
• Smart home hubs (Linux-based devices)
• Smart cameras (some models)
• Industrial IoT devices
• Development boards (Raspberry Pi, Arduino-based IoT)
✅ IoT device has accessible JTAG interface (test points or header on PCB)
✅ Device is password-protected and software bypass failed
✅ Device has encryption, and JTAG may access keys in RAM
✅ Device is functional but locked
✅ Faster than chip-off (minutes to hours vs. hours to days)
IoT Devices with JTAG:
• Routers (very common - JTAG headers for debugging)
• Smart home hubs (Linux-based devices)
• Smart cameras (some models)
• Industrial IoT devices
• Development boards (Raspberry Pi, Arduino-based IoT)
↓
JTAG PROCEDURE (8 Steps):
Step 1: Pre-JTAG Documentation
• Photograph device
• Legal authorization verified (device disassembly authorized)
• Note: JTAG is semi-invasive (disassembly required but not destructive)
Step 2: Device Disassembly and JTAG Identification
• Open device casing (photographs each step)
• Expose circuit board (PCB)
• Identify JTAG interface:
→ JTAG header (4, 5, 10, 14, or 20 pins) OR
→ JTAG test points (solder pads on PCB) OR
→ Silkscreen labels (TDI, TDO, TCK, TMS, GND, VCC)
• Document JTAG pins
Step 3: JTAG Connection
• JTAG adapter selected (Easy JTAG Plus, Segger J-Link, OpenOCD, etc.)
• Adapter connected to device JTAG pins (TDI, TDO, TCK, TMS, GND)
• Verify solid connections
• Adapter connected to forensic workstation (USB)
• Device powered ON
Step 4: JTAG Software Setup
• JTAG software launched (Easy JTAG software, J-Link Commander, OpenOCD)
• JTAG chain detected (IDCODE - identifies processor)
• Processor identified and profile loaded
• Processor halted (RAM captured before it changes - CRITICAL)
Step 5: Memory Extraction
• RAM dump (PRIORITY - volatile memory):
→ Identify RAM address range
→ Dump RAM contents via JTAG
→ Save RAM dump (.BIN file)
→ Calculate hash (SHA-256)
→ Forensic value: Encryption keys, passwords, session tokens, cached data
• Flash dump (non-volatile storage):
→ Identify flash memory address range
→ Dump flash contents via JTAG
→ Save flash dump (.BIN file)
→ Calculate hash (SHA-256)
→ Forensic value: File systems, firmware, configurations, logs, user data
Step 6: JTAG Disconnect
• Processor resumed (device returns to normal operation)
• JTAG adapter disconnected
• Device reassembled (device should still be functional)
Step 7: JTAG Dump Analysis
• RAM analysis: Search for passwords, encryption keys, session tokens (Strings, Bulk Extractor, HxD hex editor)
• Flash analysis: File system analysis (FTK Imager, Autopsy, X-Ways), Firmware analysis (Binwalk, Firmware Mod Kit)
Step 8: Documentation
• JTAG rationale, interface identification, connection procedure
• Memory extraction (RAM/flash sizes, hashes, time taken)
• Analysis and findings
• Limitations documented
Step 1: Pre-JTAG Documentation
• Photograph device
• Legal authorization verified (device disassembly authorized)
• Note: JTAG is semi-invasive (disassembly required but not destructive)
Step 2: Device Disassembly and JTAG Identification
• Open device casing (photographs each step)
• Expose circuit board (PCB)
• Identify JTAG interface:
→ JTAG header (4, 5, 10, 14, or 20 pins) OR
→ JTAG test points (solder pads on PCB) OR
→ Silkscreen labels (TDI, TDO, TCK, TMS, GND, VCC)
• Document JTAG pins
Step 3: JTAG Connection
• JTAG adapter selected (Easy JTAG Plus, Segger J-Link, OpenOCD, etc.)
• Adapter connected to device JTAG pins (TDI, TDO, TCK, TMS, GND)
• Verify solid connections
• Adapter connected to forensic workstation (USB)
• Device powered ON
Step 4: JTAG Software Setup
• JTAG software launched (Easy JTAG software, J-Link Commander, OpenOCD)
• JTAG chain detected (IDCODE - identifies processor)
• Processor identified and profile loaded
• Processor halted (RAM captured before it changes - CRITICAL)
Step 5: Memory Extraction
• RAM dump (PRIORITY - volatile memory):
→ Identify RAM address range
→ Dump RAM contents via JTAG
→ Save RAM dump (.BIN file)
→ Calculate hash (SHA-256)
→ Forensic value: Encryption keys, passwords, session tokens, cached data
• Flash dump (non-volatile storage):
→ Identify flash memory address range
→ Dump flash contents via JTAG
→ Save flash dump (.BIN file)
→ Calculate hash (SHA-256)
→ Forensic value: File systems, firmware, configurations, logs, user data
Step 6: JTAG Disconnect
• Processor resumed (device returns to normal operation)
• JTAG adapter disconnected
• Device reassembled (device should still be functional)
Step 7: JTAG Dump Analysis
• RAM analysis: Search for passwords, encryption keys, session tokens (Strings, Bulk Extractor, HxD hex editor)
• Flash analysis: File system analysis (FTK Imager, Autopsy, X-Ways), Firmware analysis (Binwalk, Firmware Mod Kit)
Step 8: Documentation
• JTAG rationale, interface identification, connection procedure
• Memory extraction (RAM/flash sizes, hashes, time taken)
• Analysis and findings
• Limitations documented
↓
JTAG ADVANTAGES:
✅ Less invasive (no chip desoldering - device remains functional)
✅ Faster (minutes to hours vs. chip-off hours to days)
✅ RAM access (CRITICAL - captures volatile encryption keys)
✅ Encryption key recovery (keys may be in RAM - accessible via JTAG, not via chip-off)
✅ Less invasive (no chip desoldering - device remains functional)
✅ Faster (minutes to hours vs. chip-off hours to days)
✅ RAM access (CRITICAL - captures volatile encryption keys)
✅ Encryption key recovery (keys may be in RAM - accessible via JTAG, not via chip-off)
JTAG LIMITATIONS:
❌ JTAG interface required (not all IoT devices have accessible JTAG)
❌ JTAG may be disabled in firmware (security measure by manufacturer)
❌ JTAG fuses blown (one-time-programmable fuses permanently disable JTAG)
❌ Expertise required (pin identification, software configuration, processor knowledge)
❌ Encryption: Hardware encryption with key in secure element may not be accessible via JTAG
❌ JTAG interface required (not all IoT devices have accessible JTAG)
❌ JTAG may be disabled in firmware (security measure by manufacturer)
❌ JTAG fuses blown (one-time-programmable fuses permanently disable JTAG)
❌ Expertise required (pin identification, software configuration, processor knowledge)
❌ Encryption: Hardware encryption with key in secure element may not be accessible via JTAG
🔧 JTAG vs. Chip-Off Decision:
| Scenario | Use JTAG | Use Chip-Off |
|---|---|---|
| Device functional, JTAG accessible | ✅ JTAG (preferred) | ❌ |
| Device damaged (not powering on) | ❌ | ✅ Chip-off |
| Need volatile RAM contents (encryption keys) | ✅ JTAG | ❌ |
| JTAG interface not present or disabled | ❌ | ✅ Chip-off |
| Device must remain functional | ✅ JTAG (less invasive) | ❌ Chip-off destroys device |
| Need file system only (not RAM) | Both possible | ✅ Chip-off (simpler if JTAG unavailable) |
Best Practice: Attempt JTAG first (if interface accessible) - less invasive, captures RAM. If JTAG fails or unavailable, proceed to chip-off.
Section 6: Advanced Laboratory Technique - Chip-Off Forensics
Chip-Off = Physical Memory Chip Removal and Reading
↓
WHAT IS CHIP-OFF?
Chip-off is an advanced hardware forensic technique where the memory chip (flash storage) is physically removed from an IoT device's circuit board and directly read using specialized equipment.
CRITICAL: This is a DESTRUCTIVE method - device will NOT be functional after chip-off.
Chip-off is an advanced hardware forensic technique where the memory chip (flash storage) is physically removed from an IoT device's circuit board and directly read using specialized equipment.
CRITICAL: This is a DESTRUCTIVE method - device will NOT be functional after chip-off.
↓
WHEN TO USE CHIP-OFF:
✅ IoT device is physically damaged (water, fire, impact) but memory chip may be intact
✅ Device cannot be powered on (power circuitry damaged, but memory chip intact)
✅ Device has strong encryption/protection that cannot be bypassed via software
✅ Password/access bypass methods failed (Section 4 Scenario 3)
✅ JTAG interface not available or disabled
✅ Last resort for critical evidence recovery
IoT Devices Suitable for Chip-Off:
• Smart cameras with local storage (flash memory chips)
• Smart home hubs (flash memory for configs, logs)
• Smart locks (flash memory for access logs)
• Routers (flash memory for logs, configurations)
• Wearables (flash memory for activity logs)
• Any IoT device with soldered flash memory chip (NAND, NOR, eMMC)
✅ IoT device is physically damaged (water, fire, impact) but memory chip may be intact
✅ Device cannot be powered on (power circuitry damaged, but memory chip intact)
✅ Device has strong encryption/protection that cannot be bypassed via software
✅ Password/access bypass methods failed (Section 4 Scenario 3)
✅ JTAG interface not available or disabled
✅ Last resort for critical evidence recovery
IoT Devices Suitable for Chip-Off:
• Smart cameras with local storage (flash memory chips)
• Smart home hubs (flash memory for configs, logs)
• Smart locks (flash memory for access logs)
• Routers (flash memory for logs, configurations)
• Wearables (flash memory for activity logs)
• Any IoT device with soldered flash memory chip (NAND, NOR, eMMC)
↓
⚠️ CHIP-OFF PREREQUISITES:
• Specialized training in chip-off forensics (soldering, desoldering, chip identification)
• Cleanroom or anti-static workspace (ESD protection critical)
• Specialized equipment (hot air rework station, chip programmers, adapters)
• Last resort method - DESTRUCTIVE (device cannot be reassembled functional)
• Legal authorization for destructive forensic method
• Photographic documentation before, during, after
• Specialized training in chip-off forensics (soldering, desoldering, chip identification)
• Cleanroom or anti-static workspace (ESD protection critical)
• Specialized equipment (hot air rework station, chip programmers, adapters)
• Last resort method - DESTRUCTIVE (device cannot be reassembled functional)
• Legal authorization for destructive forensic method
• Photographic documentation before, during, after
↓
CHIP-OFF PROCEDURE (8 Steps):
Step 1: Pre-Chip-Off Documentation
• Photograph device (all angles, serial number, condition)
• Document device make, model, firmware version (if visible)
• X-ray device (if available - identifies chip locations without disassembly)
• Note: Chip-off is DESTRUCTIVE - device will NOT be functional after
• Legal authorization verified (destructive method authorized)
Step 2: Device Disassembly
• Anti-static wrist strap worn (ESD protection)
• Open device casing carefully (photograph each step)
• Identify circuit board (PCB - Printed Circuit Board)
• Photograph circuit board (top and bottom - before touching)
• Remove screws, shields, tape covering chips
Step 3: Memory Chip Identification
• Read chip markings using magnifying glass or microscope
• Chip types:
→ NAND Flash (most common - cameras, hubs, routers): TSOP or SOP8/16 package, 128MB-128GB capacity
→ eMMC (embedded MultiMediaCard - hubs, Android-based): BGA package (balls underneath), 4GB-256GB capacity
→ NOR Flash (less common - firmware/bootloader): SOP8/16 package, 1MB-128MB capacity
• Look up chip datasheet online (search part number)
• Photograph chip markings (close-up, clear text)
• Document chip: Type, manufacturer, part number, capacity, package type, location on PCB
Step 4: Chip Removal (Desoldering)
• CRITICAL: Heat damage can destroy data - proper temperature control essential
• Hot air rework station setup:
→ Temperature: 300-350°C for NAND/eMMC/NOR (DO NOT exceed 380°C)
→ ESD mat, wrist strap grounded
→ PCB secured (PCB holder)
→ Mask nearby components (Kapton heat-resistant tape)
• Apply flux around chip (improves heat transfer)
• Preheat PCB (for BGA chips - 150°C for 2-3 min)
• Apply hot air (circular motion, 30-90 seconds until solder melts)
• Remove chip with tweezers (gentle lift when solder melted - DO NOT FORCE)
• Cool chip naturally (2-5 minutes on heat-resistant surface)
Step 5: Chip Cleaning
• Clean chip with isopropyl alcohol 99% (remove flux residue)
• Allow to dry completely (1-2 minutes)
• Inspect under microscope (check for physical damage, cracks, burns)
• Photograph cleaned chip (all angles)
Step 6: Chip Reading
• Chip programmer setup (FlashCat USB, RT809H, Easy JTAG Plus with adapters)
• Insert chip into appropriate adapter/socket:
→ Match Pin 1 of chip to Pin 1 of socket (CRITICAL - reversed = damage)
→ TSOP/SOP: Insert into socket (pins go into socket holes)
→ BGA eMMC: Requires BGA adapter (solder chip to adapter board OR use pressure-contact socket)
• Connect chip programmer to forensic workstation (USB)
• Launch chip programmer software
• Select chip type and part number (from datasheet)
• Read chip contents (block-by-block, minutes to hours depending on capacity)
• VERIFY READ: Perform second read, compare hashes (SHA-256)
→ If hashes match: Read successful
→ If hashes differ: Bad blocks, chip damage, or unstable read - attempt multiple reads
• Save chip dump (.BIN file - raw binary)
• Calculate hash (SHA-256)
• Create backup copy on separate media
Step 7: Chip Dump Analysis
• Raw chip dump = binary data - needs analysis to extract usable files/data
• File System Analysis (if chip contains file system):
→ Load .BIN file into forensic tool (FTK Imager, Autopsy, X-Ways)
→ Identify file system (Linux IoT: ext4, ext3, JFFS2, UBIFS, SquashFS)
→ Mount partitions (read-only)
→ Extract files: Configs (/etc/), logs (/var/log/), user data, media, databases
• Firmware Analysis (if chip contains firmware):
→ Use Binwalk (identifies embedded files, filesystems, compressed data)
→ Extract embedded filesystems
→ Look for hardcoded passwords, configurations, application binaries
• Data Carving (if file system corrupted):
→ Use PhotoRec, Foremost, Scalpel
→ Carve video files (MP4, AVI), image files (JPEG, PNG), log files
Step 8: Documentation and Reporting
• Chain of custody: Chip-off date/time, examiner, authorization
• Report: Chip-off rationale, disassembly, chip identification, removal procedure, reading method, analysis, findings
• Evidence storage: Physical chip (anti-static bag, labeled, sealed), chip dump files (hash verified, backed up)
Step 1: Pre-Chip-Off Documentation
• Photograph device (all angles, serial number, condition)
• Document device make, model, firmware version (if visible)
• X-ray device (if available - identifies chip locations without disassembly)
• Note: Chip-off is DESTRUCTIVE - device will NOT be functional after
• Legal authorization verified (destructive method authorized)
Step 2: Device Disassembly
• Anti-static wrist strap worn (ESD protection)
• Open device casing carefully (photograph each step)
• Identify circuit board (PCB - Printed Circuit Board)
• Photograph circuit board (top and bottom - before touching)
• Remove screws, shields, tape covering chips
Step 3: Memory Chip Identification
• Read chip markings using magnifying glass or microscope
• Chip types:
→ NAND Flash (most common - cameras, hubs, routers): TSOP or SOP8/16 package, 128MB-128GB capacity
→ eMMC (embedded MultiMediaCard - hubs, Android-based): BGA package (balls underneath), 4GB-256GB capacity
→ NOR Flash (less common - firmware/bootloader): SOP8/16 package, 1MB-128MB capacity
• Look up chip datasheet online (search part number)
• Photograph chip markings (close-up, clear text)
• Document chip: Type, manufacturer, part number, capacity, package type, location on PCB
Step 4: Chip Removal (Desoldering)
• CRITICAL: Heat damage can destroy data - proper temperature control essential
• Hot air rework station setup:
→ Temperature: 300-350°C for NAND/eMMC/NOR (DO NOT exceed 380°C)
→ ESD mat, wrist strap grounded
→ PCB secured (PCB holder)
→ Mask nearby components (Kapton heat-resistant tape)
• Apply flux around chip (improves heat transfer)
• Preheat PCB (for BGA chips - 150°C for 2-3 min)
• Apply hot air (circular motion, 30-90 seconds until solder melts)
• Remove chip with tweezers (gentle lift when solder melted - DO NOT FORCE)
• Cool chip naturally (2-5 minutes on heat-resistant surface)
Step 5: Chip Cleaning
• Clean chip with isopropyl alcohol 99% (remove flux residue)
• Allow to dry completely (1-2 minutes)
• Inspect under microscope (check for physical damage, cracks, burns)
• Photograph cleaned chip (all angles)
Step 6: Chip Reading
• Chip programmer setup (FlashCat USB, RT809H, Easy JTAG Plus with adapters)
• Insert chip into appropriate adapter/socket:
→ Match Pin 1 of chip to Pin 1 of socket (CRITICAL - reversed = damage)
→ TSOP/SOP: Insert into socket (pins go into socket holes)
→ BGA eMMC: Requires BGA adapter (solder chip to adapter board OR use pressure-contact socket)
• Connect chip programmer to forensic workstation (USB)
• Launch chip programmer software
• Select chip type and part number (from datasheet)
• Read chip contents (block-by-block, minutes to hours depending on capacity)
• VERIFY READ: Perform second read, compare hashes (SHA-256)
→ If hashes match: Read successful
→ If hashes differ: Bad blocks, chip damage, or unstable read - attempt multiple reads
• Save chip dump (.BIN file - raw binary)
• Calculate hash (SHA-256)
• Create backup copy on separate media
Step 7: Chip Dump Analysis
• Raw chip dump = binary data - needs analysis to extract usable files/data
• File System Analysis (if chip contains file system):
→ Load .BIN file into forensic tool (FTK Imager, Autopsy, X-Ways)
→ Identify file system (Linux IoT: ext4, ext3, JFFS2, UBIFS, SquashFS)
→ Mount partitions (read-only)
→ Extract files: Configs (/etc/), logs (/var/log/), user data, media, databases
• Firmware Analysis (if chip contains firmware):
→ Use Binwalk (identifies embedded files, filesystems, compressed data)
→ Extract embedded filesystems
→ Look for hardcoded passwords, configurations, application binaries
• Data Carving (if file system corrupted):
→ Use PhotoRec, Foremost, Scalpel
→ Carve video files (MP4, AVI), image files (JPEG, PNG), log files
Step 8: Documentation and Reporting
• Chain of custody: Chip-off date/time, examiner, authorization
• Report: Chip-off rationale, disassembly, chip identification, removal procedure, reading method, analysis, findings
• Evidence storage: Physical chip (anti-static bag, labeled, sealed), chip dump files (hash verified, backed up)
↓
CHIP-OFF RISKS AND LIMITATIONS:
Risks:
❌ Destructive method - Device cannot be reassembled functional (permanent disassembly)
❌ Chip damage - Overheating, physical damage during removal, lifted pads, cracked chip = data loss
❌ Data encryption - If chip contents encrypted (full-disk encryption), chip-off provides encrypted data only (decryption key needed - may be in device's secure element or TEE, not on chip)
❌ Bad blocks - NAND flash chips have bad blocks (unreadable sectors) - may lose data in bad blocks
❌ Specialized expertise required - High skill level (soldering, chip identification, forensic analysis)
❌ Equipment cost - Chip programmers, adapters, hot air stations = expensive (€1000-€10,000+)
When Chip-Off NOT Suitable:
• Device functional and can be accessed via software methods (use software bypass first)
• Chip has hardware encryption with key in separate secure element (chip-off won't help)
• Legal authorization does not permit destructive analysis
• Expertise not available (risk of destroying evidence)
Risks:
❌ Destructive method - Device cannot be reassembled functional (permanent disassembly)
❌ Chip damage - Overheating, physical damage during removal, lifted pads, cracked chip = data loss
❌ Data encryption - If chip contents encrypted (full-disk encryption), chip-off provides encrypted data only (decryption key needed - may be in device's secure element or TEE, not on chip)
❌ Bad blocks - NAND flash chips have bad blocks (unreadable sectors) - may lose data in bad blocks
❌ Specialized expertise required - High skill level (soldering, chip identification, forensic analysis)
❌ Equipment cost - Chip programmers, adapters, hot air stations = expensive (€1000-€10,000+)
When Chip-Off NOT Suitable:
• Device functional and can be accessed via software methods (use software bypass first)
• Chip has hardware encryption with key in separate secure element (chip-off won't help)
• Legal authorization does not permit destructive analysis
• Expertise not available (risk of destroying evidence)
⚠️ CHIP-OFF AS LAST RESORT:
Always attempt non-destructive methods first:1. Scenario 3 software bypass (default credentials, password reset, network sniffing, exploits, manufacturer assistance)
2. JTAG (if available - less invasive, captures RAM)
3. Chip-off ONLY when other methods failed OR device physically damaged beyond software access
Section 7: Legal Compliance Checklist for Prosecutors and Judges
✅ EVIDENCE IS ADMISSIBLE IF:
Legal Authorization:
• Legal authorization obtained (consent/warrant/court order)
• Authorization specifies scope (device seizure, extraction level, cloud access)
• National authorization ALWAYS obtained (regardless of Budapest pathway)
Cloud Data Compliance:
• Cross-border cloud data: Budapest Convention pathway followed (Article 32.a, 32.b, or 16)
• Article 32.b: Written voluntary consent obtained (signed, witnessed, voluntary, informed)
• Article 16: Preservation submitted (90-180 days max) + MLAT for production (foreign authorization obtained)
• National rules always complied with
Device Access Compliance:
• IoT device access: One of three legal scenarios followed (Written Consent, Live Exam, Technical Bypass)
• Scenario 1 (Consent): Written consent obtained, credentials provided voluntarily, documented
• Scenario 2 (Live Exam): Article 37 Albanian CPC complied with (warnings issued, lawyer rights respected, no compulsion)
• Scenario 3 (Technical Bypass): Pure technical method, no Article 37 issue, bypass method documented
Network Isolation:
• Network isolated immediately (Airplane Mode, Faraday bag, or disconnect internet at router)
• Prevents remote wipe, data modification, user notification
Chain of Custody and Documentation:
• Contradictory process followed (owner + witnesses present throughout, if applicable)
• Biological traces preserved or collected properly (gloves worn at all times)
• Photographic documentation complete (scene, devices in situ, seizure, isolation)
• Hashes calculated (SHA-256 for all dumps, images, cloud data received)
• RFC3161 timestamp (if applicable)
• Chain of custody unbroken (all transfers documented, signatures obtained)
Advanced Techniques (if used):
• JTAG: Legal authorization for disassembly, JTAG procedure documented, device functional after (if possible)
• Chip-off: Legal authorization for destructive method, chip-off procedure documented, chip stored properly
Legal Authorization:
• Legal authorization obtained (consent/warrant/court order)
• Authorization specifies scope (device seizure, extraction level, cloud access)
• National authorization ALWAYS obtained (regardless of Budapest pathway)
Cloud Data Compliance:
• Cross-border cloud data: Budapest Convention pathway followed (Article 32.a, 32.b, or 16)
• Article 32.b: Written voluntary consent obtained (signed, witnessed, voluntary, informed)
• Article 16: Preservation submitted (90-180 days max) + MLAT for production (foreign authorization obtained)
• National rules always complied with
Device Access Compliance:
• IoT device access: One of three legal scenarios followed (Written Consent, Live Exam, Technical Bypass)
• Scenario 1 (Consent): Written consent obtained, credentials provided voluntarily, documented
• Scenario 2 (Live Exam): Article 37 Albanian CPC complied with (warnings issued, lawyer rights respected, no compulsion)
• Scenario 3 (Technical Bypass): Pure technical method, no Article 37 issue, bypass method documented
Network Isolation:
• Network isolated immediately (Airplane Mode, Faraday bag, or disconnect internet at router)
• Prevents remote wipe, data modification, user notification
Chain of Custody and Documentation:
• Contradictory process followed (owner + witnesses present throughout, if applicable)
• Biological traces preserved or collected properly (gloves worn at all times)
• Photographic documentation complete (scene, devices in situ, seizure, isolation)
• Hashes calculated (SHA-256 for all dumps, images, cloud data received)
• RFC3161 timestamp (if applicable)
• Chain of custody unbroken (all transfers documented, signatures obtained)
Advanced Techniques (if used):
• JTAG: Legal authorization for disassembly, JTAG procedure documented, device functional after (if possible)
• Chip-off: Legal authorization for destructive method, chip-off procedure documented, chip stored properly
❌ EVIDENCE IS INADMISSIBLE IF:
Legal Authorization Violations:
• No legal authorization or authorization scope insufficient
• National authorization missing (even if Budapest Convention followed)
Cloud Data Violations:
• Cross-border data accessed without Budapest Convention compliance (no Article 32.a, 32.b, or 16 followed)
• Article 32.b consent: Coerced, uninformed, or not genuinely voluntary
• Article 16 MLAT: Foreign authorization not obtained, preservation expired before production
• Cloud data accessed directly without legal process (no preservation, no MLAT)
Device Access Violations:
• Article 37 violated (statements before warning used, questioning continued after lawyer requested, compulsion of credentials)
• Live exam: Credentials compelled against owner's will (Article 37 violation)
• Consent: Coerced or uninformed consent used for device access or cloud data
Network Isolation Violations:
• Network NOT isolated (remote wipe occurred, data modified, user notified, eSIM commands received)
• Evidence integrity compromised (device remained connected to internet, cloud sync occurred)
Chain of Custody Violations:
• Contradictory process violated (owner/witnesses not present when required)
• Chain of custody broken (undocumented transfers, missing signatures, unexplained gaps)
• Documentation incomplete (no photographs, no hashes, no timestamps)
• Biological traces destroyed or not preserved
Advanced Techniques Violations:
• JTAG/Chip-off: No legal authorization for invasive/destructive method
• Chip-off: Destructive method used without exhausting non-destructive options first
• Technical bypass: Method used violates national law or exceeds authorization scope
Legal Authorization Violations:
• No legal authorization or authorization scope insufficient
• National authorization missing (even if Budapest Convention followed)
Cloud Data Violations:
• Cross-border data accessed without Budapest Convention compliance (no Article 32.a, 32.b, or 16 followed)
• Article 32.b consent: Coerced, uninformed, or not genuinely voluntary
• Article 16 MLAT: Foreign authorization not obtained, preservation expired before production
• Cloud data accessed directly without legal process (no preservation, no MLAT)
Device Access Violations:
• Article 37 violated (statements before warning used, questioning continued after lawyer requested, compulsion of credentials)
• Live exam: Credentials compelled against owner's will (Article 37 violation)
• Consent: Coerced or uninformed consent used for device access or cloud data
Network Isolation Violations:
• Network NOT isolated (remote wipe occurred, data modified, user notified, eSIM commands received)
• Evidence integrity compromised (device remained connected to internet, cloud sync occurred)
Chain of Custody Violations:
• Contradictory process violated (owner/witnesses not present when required)
• Chain of custody broken (undocumented transfers, missing signatures, unexplained gaps)
• Documentation incomplete (no photographs, no hashes, no timestamps)
• Biological traces destroyed or not preserved
Advanced Techniques Violations:
• JTAG/Chip-off: No legal authorization for invasive/destructive method
• Chip-off: Destructive method used without exhausting non-destructive options first
• Technical bypass: Method used violates national law or exceeds authorization scope
⚖️ KEY LEGAL CONSIDERATIONS FOR JUDGES:
1. Cloud Data ≠ Device Data
• IoT evidence primarily in cloud (Amazon, Google, Ring, Nest)
• Device seizure alone = incomplete evidence
• Cloud data requires separate legal process (Budapest Convention if cross-border)
2. Budapest Convention Applies to MOST IoT Cases
• Most IoT providers = USA servers (Amazon, Google, Ring, Nest, Arlo)
• Cross-border data = Budapest Convention mandatory
• Three pathways: Public (32.a) / Consent (32.b) / MLAT (16)
• National authorization ALWAYS required (Budapest addresses foreign authorization only)
3. Article 37 Albanian CPC Applies to IoT Device Access
• Asking for device passwords = may trigger Article 37 (protection against self-incrimination)
• Three legal scenarios: Written Consent (no Article 37 issue) / Live Exam (Article 37 applies) / Technical Bypass (no Article 37 issue)
• Compelled credentials without Article 37 compliance = inadmissible
4. Advanced Techniques Require Proper Authorization
• JTAG: Semi-invasive (disassembly), authorization for device opening required
• Chip-off: Destructive (device unusable after), explicit authorization for destructive method required
• Both techniques: Legitimate if other methods failed and properly authorized
5. Timeline Critical for Cloud Data
• Preservation (Article 16): 90-180 days maximum
• MLAT: Can take months to years
• If MLAT takes longer than preservation: Renewal required OR evidence lost
• Judges should prioritize MLAT requests for IoT cases (time-sensitive)