Live rushes on, we are distracted

Rainbow table

2019-06-14T16:07:07+00:00

Rainbow table

해시는 포렌식에서 무결성을 검증하는 중요한 도구로 사용된다. 해시 함수의 주요 특징은 다음과 같다.

입력이 한 비트만 바뀌어도 결과 전체가 완전하게 바뀐다.(눈사태 효과)
두 해시 값이 다르다면 원래의 데이 터도 다르다.
같은 해시 값을 갖더라도 원래의 입력값이 같다는 것을 보장하지 않는다.(단사함수가 아님)

특히 첫 번째 특징 때문에 해시는 데이터의 무결성을 검증하는 도구로 사용되고, 결과만 보고 입력을 유추하는 것은 불가능해진다. 그런데, 입력의 경우의 수가 유한한 경우 모든 입력에 대해 해시값을 구한 후 유지하고 있으면, 향후 해시값을 가지고 이 값을 만들어낸 원본 데이터를 찾아낼 수 있는데 이런 자료구조를 레인보우 테이블이라고 한다.

안드로이드의 패턴락 및 카카오톡의 패런락은 사용자의 입력을 내부적으로 해시를 통해 저장하는데, 패턴락을 입력할 수 있는 경우의 수가 유한하기 때문에, 모든 경우의 수에 대한 패턴락을 미리 계산해 놓으면 추후 증거물에서 저장된 해시값을 데이터베이스의 키로 사용하여 원래의 패턴을 찾아낼 수 있다.

아래 화면은 카카오톡의 패턴락 입력화면인데 좌측 상단부터 1, 2, 3, …, 7, 8, 9의 값을 가진다.

표 1. 카카오톡 패턴락

1에서 다음으로 이동할 수 있는 경우는 { 2, 4, 5 }. 2에서는 { 1, 3, 4, 5, 6 } 이런 식으로 나누어 볼 수 있는데 이것을 정리해 보면 다음과 같은 자료구조로 표현이 가능하다.

Ruby: ranbow_table.rb

1
2
3
4
5
6
7
8
9
10
11
12
@candidate_hash = {
  0 => [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ],
  1 => [ 2, 4, 5 ],
  2 => [ 1, 3, 4, 5, 6 ],
  3 => [ 2, 5, 6 ],
  4 => [ 1, 2, 5, 7, 8 ],
  5 => [ 1, 2, 3, 4, 5, 6, 7, 8, 9],
  6 => [ 2, 3, 5, 8, 9],
  7 => [ 4, 5, 8 ],
  8 => [ 4, 5, 6, 7, 9 ],
  9 => [ 5, 6, 8 ]
}

위의 코드에서 키 ‘0’은 사용자가 패턴을 시작하는 첫 지점, 즉 아홉 개의 점에서 어떤 점에서도 선택을 할 수 있다는 것을 표시하고 나머지 1 ~ 9의 경우는 각 점에서 이동할 수 있는 인접한 점(8-neighbor)을 표시한다.

이 데이터를 기반으로 ‘backtracking’을 해서 사용자가 입력가능한 모든 패턴의 경우를 나열하고 이 데이터를 기반으로 레인보우 테이블을 구성하여, 실제 증거물에서 발견된 해시를 기반으로 원래 패턴을 찾아낸다. 레인보우 테이블 구성을 위한 ‘backtracking’ 코드는 다음과 같다.

Ruby: ranbow_table.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#!/usr/bin/env ruby

require "deep_clone"
require "digest/sha1"

class Passcode
  def initialize
    @sha1 = Digest::SHA1.new
    @passcode = {}
    @candidates_hash = {
      0 => [1, 2, 3, 4, 5, 6, 7, 8, 9], # for start

      1 => [2, 4, 5],
      2 => [1, 3, 4, 5, 6],
      3 => [2, 5, 6],
      4 => [1, 2, 5, 7, 8],
      5 => [1, 2, 3, 4, 6, 7, 8, 9],
      6 => [2, 3, 5, 8, 9],
      7 => [4, 5, 8],
      8 => [4, 5, 6, 7, 9],
      9 => [5, 6, 8]
    }

    prepare_rainbow_table
  end

  def passcode_of hash
    @passcode[hash]
  end

private
  def prepare_rainbow_table
    4.upto(9) { |i| backtrack([], 0, i) }
  end

  def process arr
    @sha1.reset
    arr.each { |e| @sha1 << (e-1).chr }
    s = arr.map(&:to_s).reduce(:+) # [1, 2, 3, 4] => "1234"
    e = @sha1.hexdigest.upcase
    @passcode[e] = s
    printf("%s => %s\n",e, s)
  end

  def backtrack(arr, beg, depth)
    process(arr) && return if arr.length == depth

    @candidates_hash[beg].each do |c|
      unless arr.include?(c)
        backtrack(DeepClone.clone(arr).push(c), c, depth)
      end
    end
  end
end

decryptor = Passcode.new
p decryptor.passcode_of("59A3556203C8F6C908D6C6BCE4C5E03F6BF343E3")

What is FFS?

2019-06-09T12:34:06+00:00

What is FFS?

Figure 1. General Filesystem Structure

이 naive한 설계는 파일시스템이 사용됨에 따라서 성능의 문제를 겪게되는데 fragmentation이 심해짐에 따라 하드디스크의 읽기 지연이 점점 늘어가는 현상이 대표적인 문제라고 할 수 있다.

Figure 2는 이러한 문제를 극복하기 위해 설계된 FFS(Fast File System)의 개념을 보여주고 있다. 기본적인 아이디어는 데이터의 공간 지역성(spacail locality)를 이용하여 관련 데이터를 동일 실린더 그룹(cyliner gourp)안에 배치시킴으로써 파일 참조시 디스크 탐색을 최소화 하는 것이다.

Figure 2. Example of FFS, Ext 4

Which filesystem falls into the category of FFS?

가장 대표적인 FFS 파일시스템은 ext 2/3/4, 그리고 XFS가 있다.

What problems does FFS have in mobile Devices?

대부분의 모바일 기기는 NAND Flash 혹은 이것을 기본 building block으로 사용하고 있는 eMMC 혹은 UFS를 사용하고 있다. 이러한 NAND Flash는 FFS 설계의 기본 전제인 ‘하드 디스크’와 근본적으로 성격이 다르기 때문에 FFS방식으로 설계된 파일시스템은 Flash 기반 저장장치에서 최적화된 성능을 낼 수 없다.

Then, what’s alternative for this FFS?

LFS(Log File System)!

About UTF-8

2018-03-11T11:58:06+00:00

UTF-8 소개

유니코드. 전 세계의 문자를 통일된 규칙으로 표현한 체계. 1990년 IBM, Microsoft, Apple등의 회사가 전세계의 모든 문자에 0x0000 ~ 0xFFFF까지(65,536) 숫자를 매겨놓은 규칙. 제정할 때 고려하지 못한 문자를 표현하기 위해 15개의 세트(플레인이라고 함)가 추가되었다. 그래서, U+0000 처럼 4개의 nibble로 표현된 유니코드를 기본 플레인(BMP, Basic multilingual plain)이라고 표시하고 추가된 15개의 플레인은 U+10000 ~ U+F0000 처럼 5개의 nibble로 표현한다.

UCS-2는 추가된 15개의 플레인을 무시하고 BMP만을 사용하는 인코딩 방식. UTF-16은 BMP 문자는 UCS-2로 그 이상의 문자는 32비트로 인코딩 방식. UTF-32는 16개의 플레인으로 표현되는 모든 문자를 4바이트의 문자로 표현하는 방식.

UTF-8은 1~4 바이트의 가변길이 유니코드 인코딩이다. 가장 많이 사용되는 코드는 1 바이트 (ASCII), 사용 빈도가 적은 언어에는 더 많은 바이트를 할당한다. 한글의 경우 문자 당 3 바이트 할당.

아래 그림 1에서 확인할 수 있는 것처럼 UTF-8이 가장 널리 사용된다.

그림 1. utf-8 사용 추세

포렌식에서 UTF-8

포렌식 분석 시 도구가 증거 데이터를 정확하게 분석하지 못할 경우, 분석관이 직접 헥스 에디터를 보면서 분석해야 하는 경우가 있다. 획득한 이미지를 헥스 뷰어로 볼 때 연속된 헥사 값에서 한글을 찾아내는 것은 매우 중요하다. 아래 표 1에서 보는 것처럼 3바이트로 표현되는 한글은 각 바이트에 1110, 10, 10 라는 숫자가 할당된다. 즉, 이진수 1110은 16진수로 0xE 이므로 헥스 뷰어에서 0xE로 시작되는 3바이트를 한글이라고 가정하고 해석하면 한글을 쉽게 찾을 수 있다.

표 1. utf-8 변환표

연습

“이창하” 를 편집기를 이용해서 utf-8로 저장하고 Hex Viewer로 읽으면 => [EC 9D B4 EC B0 BD ED 95 98]

    EC 9D B4  => 1110(1100) . 10(011101) . 10(110100)
              => 1100 . 011101 . 110100
              => 11000111 . 01110100
              => 1100 . 0111 . 0111 . 0100
              => C774    ([U+C774](https://codepoints.net/U+C774))
    EC B0 BD  => U+CC3D
    ED 95 98  => U+D558

아래 소스코드는 utf-8로 저장된 한글 데이터를 읽어서 해당 unicode로 출력하는 예제이다. 변수 path에 실제 파일의 경로를 주면 된다.

Ruby: utf8_to_unicode_point.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/usr/bin/env ruby

class String
  def to_codepoint
    self.bytes.each_slice(3).map { |s|
      first = (s[0] & 0xf0) >> 4
      return nil unless first == 0b1110
      init  = s.shift & 0xff
      s.reduce(init) { |r, e| r << 6 | e & 0x3f }
    }
  end
end

chars = File.open(path, "r:UTF-8") { |f| f.read.chomp }
chars.to_codepoint.each { |cp|
  p "U+#{cp.to_s(16).upcase}"
}