[논문요약] 「Reconstructing streamed video content」 요약

​

Reconstructing streamed video content: A case study on YouTube and Facebook Live stream content in the Chrome web browser cache - ScienceDirect

Reconstructing streamed video content: A case study on YouTube and Facebook Live stream content in the Chrome web browser cache

​

논문출처: Graeme Horsman. "Reconstructing streamed video content: A case study on YouTube and Facebook Live stream content in the Chrome web browser cache"(2018)

 

​1. 요약의 요약

: 유튜브 및 페이스북 라이브 비디오가 재생된 곳에서 버퍼링된 비디오 스트림 데이터를 재조립하여 콘텐츠를 볼 수 있는 비디오 클립을 생성할 수 있다는 결과를 보여주는 스트림 재구성 방법론이 제공

​

2. 소개 요약

: 온라인 비디오 스트리밍 플랫폼은 사용자에게 비디오 컨텐츠를 다운로드 및 저장하지 않아도 컨텐츠를 공유하고 다른 사람이 게시한 비디오 자료를 확인할 수 있는 기회를 제공. 스트리밍 서비스의 수가 증가하면서 트래픽 양으로 인해 법률 및 플랫폼 정책을 위반하는 비디오 컨텐츠의 업로드와 배포 문제, 이러한 자료의 후속 시청 및 참여와 관련된 규제 문제가 발생. 따라서 사건에 효과적으로 대응하려고 시도할 때 문제가 발생함. 비디오를 보고 상호작용 한 사람을 식별하면 비디오를 게시한 제공자 뿐만이 아니라 해당 개인에 대한 추가 책임이 발생할 수 있음.

 

인터넷 기록이 액세스한 호스팅 비디오에 대한 포인터를 제공하는 경우도 있지만, 스트리밍된 컨텐츠를 식별하는게 항상 효과적인 것은 아님. 비디오가 공급자에 의해 제거된 경우, 로컬로로 캐시된 스트림 데이터는 스트림 컨테츠 및 컨텍스트를 식별하기 위해 남아 있는 유일한 정보 소스일 수 있음.

​

1) 유튜브

: 유튜브의 URL 자체에는 유튜브 동영상 자체에 대한 고유 식별자가 접두사로 붙게 됨. 어떠한 경우에는 이 식별자를 사용하여 동영상을 검색하고 확인할 수 있지만 유튜브에서 영상이 삭제된 경우 의심되는 URL은 식별할 수 있지만 유튜브 사이트에서 비디오를 찾을 수는 없고, 유튜브에 계정 공개를 요청하더라도 해당 정보의 기록이 더 이상 존재하지 않거나 제한된 조직 리소스에서 공개 경로가 비현실적이라고 간주 할 수 있다는 점과 비디오의 길이가 긴 경우 사용자가 시청한 비디오의 양과 증거가치가 있고 제공할 수 있는 특정 컨텐츠를 결정한다는 점을 해결할 수는 없다.

​

* 행동(비디오 길이가 긴 경우)의 나머지 부분에서는 크롬 웹 브라우저 캐시에서 유튜브 스트림의 영향에 대한 조사를 제공함

​

2.1 예비 접근 요약

: 파일 식별, 구문 분석 및 복구 프로세스를 사용하여 테스트 스트림을 본 후, 브라우저 캐시를 검사하도록 설계된 초기 테스트를 실행.

일반적으로 자동화된 절차 스크립트 실행을 통해 수행되는 대규모 파일 복구 및 보기 프로세스를 포함하는 기존의 접근 방식을 시뮬레이션 하기 위함

​

1) 윈도우 운영체제 설치 & 크롬 브라우저 설치

2) 고유하게 식별 가능한 유튜브 동영상을 적절한 테스트 데이터로 선택, 그 내용을 기록. 이를 통해서 테스트 스트림을 로컬 시스템에서 후속적으로 복구한 스트리밍 컨텐츠를 시각적으로 식별하고 확인 가능. 크롬 캐시 폴더 비어 있음을 확인

3) 동영상 재생, 브라우저를 닫고 머신을 종료한 후 이미지 생성

4) Ways 포렌식의 포괄적인 검색 옵션으로 모든 잠재적 이미지와 비디오, 인터넷 관련 데이터를 복구. 법의학 조사에 자주 사용되는 기존 사례 절차를 시뮬레이션하기 위해 자동화된 미디어 수집 프로세스 사용

​

완료 시 두 도구에 의해 스트림에 포함된 컨텐츠를 나타내는 4개의 스틸 썸네일 크기 캐시 이미지가 복구, 압축 비디오 스트림 형식 파일도 발견됨.

​

2.2 요약

: 로컬에서 캐시되는 컨텐츠의 존재에 대한 초기 표시기를 제공하기 위해서 유뷰브 비디오가 로드될 때 회색 비디오 막대로 표시되는 버퍼링이 발생, 스트림의 일부가 버퍼링 되면 인터넷 연결을 제거해도 스트림의 버퍼링된 부분 중 일부를 재생이 가능, 유튜브 서버의 데이터에 액세스할 수 없으면 이 정보가 로컬에 있는 컨텐츠에서 재생되는 것 처럼 보임.

* 유튜브 스트림에 액세스할 때 버퍼링 프로세스로 인해 데이터가 로컬 장치에 점진적으로 저장됨

​

캐시된 스트림 분석과 관련된 이러한 프로세스의 문제는 미디어 파일이 단일 엔터티(자체 권한으로 완전한 비디오)로 검토되는 데 존재.

이러한 합의는 비디오가 더 작은 데이터 패키지를 통해 분해되고 전송괴는 스트리밍 프로세스와 충돌(=엔터티로 검토 되면 스트리밍 프로세스와 충돌하게 됨) 단일 파일로 검사할 때, 스트림의 시작 부분을 검토할 수 있으며 나머지 스트림 내용은 볼 수 있지만, 버퍼링된 스트림 조각의 효과적인 재조립 후에만 확인할 수 있다.

​

2.3 비디오 재구성 요약

: 유튜브 스트림을 재구성하려면 먼저 모든 .webm 항목을 수집해야 함. 모든 파일이 집합적으로 하나의 완전한 스트림을 형성하지만, 컨텐츠를 확인하기 위해서는 올바르게 처리하는 과정이 필요함. 각 .webm 항목은 스트림의 일부를 유지하면서 시청 가능한 비디오를 생성하기 위해 재조립을 수행해야 함.

​

크롬 캐시뷰를 사용해서 마지막으로 액세스한 날짜 및 시간별로 캐시 항목을 정렬, 아티팩트가 로컬 디스크의 크롬에 캐시되는 순서가 제공됨.

각 .webm 캐시 항목은 조각 순서를 식별하기 위해 관련 URL을 검사해야 함.

​

캐싱된 비디오 스트림 내에서 프레임의 순서를 결정하는 데 사용할 수 있는 range 1/4 값이 제일 중요. webm 형태의 유튜브 스트림은 비디오의 시작을 식별하는 헤더 프레임을 유지함, 이 때 webm 서명을 통해서 이를 식별 가능, range 1/4의 값은 0-<숫자>

테스트 결과 이 파일이 개별적으로 액세스할 때 재생할 수 있는 유일한 .webm 파일

​

dur 1/4 속성은 비디오의 전체 길이를 나타냄

​

헤더 파일을 시작 위치로 사용해서 비디오로 다시 만들려면 추가 .webm 파일을 연결해야 함. 이는 range1/4 속성에 저장된 값을 사용하여 프레임 순서로 수행되어야 함. 헤더 파일이 식별 가능한 .webm 서명을 유지하지만 스트림 청크가 일관된 헤더 구조를 유지하지는 않음. 따라서 모든 조각의 순서를 식별하려면 range=ordering 변수를 사용, chorme, 캐시 아티팩트 및 관련 메타데이터의 구문 분석을 통해 MIME 유형 및 range=속성을 포함하는 관련 URL을 식별하도록 해야 함.

​

중간 정리: 어쨌든 모든 파일들은 '효과적으로 재조립'되어야 유의미한 비디오 파일을 확인할 수 있음(이해한 바로는). 조립되기 전에는 헤더 .webm 파일만 단독으로 재생이 가능. 캐싱된 스트림 파일은 range 1/4의 서명을 통해서 헤더 값을 가지고, 헤더 파일을 시작 위치로 해서 비디오를 재조립할 경우에는 추가적으로 파일이 더 필요로 하는데 이 역시 range 1/4 속성에 저장된 값을 사용해서 순서대로 연결해야함. 그러나 스트림 파일들이 헤더 파일을 식별하는 것은 가능하지만 일관된 헤더 구조를 유지 하지는 않음, 따라서 파일 조각들의 순서를 식별하기 위해서는 변수를 사용해서 구문 분석을 하여 관련 URL을 식별하도록 작업을 수행해야 함.

​

​

2.4 주의사항 요약

:

1) 스트림의 버퍼링된 부분만 재구성 가능, 버퍼링된 컨텐츠의 사용자가 화면에서 본 하위 부분은 식별 불가

ex) 50초 비디오 중 40초만 버퍼링되었다면 마지막 10초는 재구성 불가.

+) 버퍼링 되었지만 시청되지 않은 컨텐츠는 어쨌든 버퍼링 되었기에 저장되고 재구성될 수 있음

 

2) 스트림 재구성은 캐시된 컨텐츠와 캐시된 인공물에 속하는 관련 메타 데이터를 구문 분석하기 위해 전체 캐시 조사가 필요. range 1/4 값이 없으면 재조립이 성공할 가능성이 거의 없음. 이 문제는 재구축에 필요한 관련 스트림 메타 데이터가 누락 될 수 있으므로 컨텐츠가 더 이상 캐시에 없는 단편화된 스트림을 복구 및 재구축하는 성공률이 낮음을 의미.

​

*메타 데이터: 다른 데이터를 설명해주는 데이터 ex) HTML 태그

https://terms.naver.com/entry.naver?docId=1224192&cid=40942&categoryId=32840

 

3) 스트림 조각이 불완전하거나 잘못된 순서로 스트림을 재구축 하려는 시도는 일반적으로 재구축된 스트림을 볼 수 없게 만듦. 하나의 조각이 순서대로 나타나지 않는 경우에도 마찬가지

​

4) .mp4 파일 형식의 스트림이 존재. 캐시에서의 동작은 .webm과 비슷하며, range1/4 URL 속성의 순서를 통해 재구축을 얻을 수 있음

​

​

3. 페이스북 라이브 요약

: 페이스북 라이브의 공개 방송은 수동적으로 계정에 접근하는 사람만 볼 수 있지만 비공개 방송은 계정 소유자의 친구인 사람만 확인 가능, 생방송이 끝나도 비디오는 계속 사용할 수 있으며, 저자가 보기 설정을 삭제하거나 조정한 후 나중에 볼 수 있음. 역시나 트래픽은 무해하지만, 서비스의 남용 사례가 지적됨

​

3.1 초기 테스트 요약

: 페이스북 라이브와 상호작용할 때 캐시되는 항목과 캐시되지 않는 항목을 확인하는 것이 중요. 사용자가 생방송을하고 용의자 계정이 이를 시청할 때, 용의자의 크롬 브라우저 캐시에서 캐싱이 발생하지 않는 것으로 나타남. (=페이스북 라이브 시청은 캐시에 기록이 남지 않음)

​

3.2 스트림 다시보기 요약

: 용의자 계정이 페이스북 사용자가 라이브 방송 후에 호스팅한 비디오를 재생할 경우에는 브라우저 캐싱이 발생, 스트림 조각은 mp4 형식으로 표기되지만 개별 파일로 재생할 수 있는 것은 없음. 유튜브 스트림과 마찬가지로 단편 조각을 재조립하여 스트림 컨텐츠를 재구성하는 것이 가능. 그러나 캐시된 인공물(컨텐츠)의 URL 분석을 통해서만 이것이 가능.

​

스트림을 다시 작성하려면 oe1/4 , bytestart1/4, byteend1/4 속성이 중요.

​

oe 1/4: 스트림 식별자 역할 → 이 값이 동일해야 스트림을 재구축할 수 있음

bytestart1/4, byteend1/4: 연결 순서를 나타냄

​

**참고사항: 테스트 시, 재구성하기 전에 스트림이 포함된 oe1/4 속성을 확인할 수 없었음. 따라서 볼 수 있는 스트림을 만들려면 모두 빌드해야 함. 또한 bytestart1/4, byteend1/4 속성은 연결 순서를 결정하기 위해 증분 순서로 사용해야 하지만, 항상 숫자적으로 완벽하게 정렬되지는 않음. 그래도 숫자 순서대로만 하면 재구충 가능 ex) 1.2.3.4 가 아니라 1.3.4.6으로 나타나는데, 이렇게 해도 재구축이 가능.

​

4. 결론 요약

: 두 파일 모두 미디어 컨텐츠를 단일 엔터티로 식별하고 검사하기 위한 기존의 '단일 파일' 미디어 분석 전략은 효과가 없었음. 스트림 조각은 캐시 파일에 포함된 캐시된 인공물과 관련 메타 데이터 모두에 대한 분석이 우리가 필요로 하는 캐시 내에서 식별되어야 함

=캐시된 인공물(아마 파일인듯)과 메타 데이터에 대한 분석이 우리가 분석하고자 하는 캐시 내에서 식별되어야(존재해야)함

​

ChromeCacheView 애플리케이션은 Chrome 캐시 폴더의 구문 분석을 용이하게 하고 효과적인 스트림 재구축을 수행하기 위해 필요

​

스트림 재구성 중에 스트림 조각이 올바르게 정렬되도록 하려면 각 인공물을 둘러싼 메타 데이터가 필요

=메타 데이터가 oe1/4 나 range 1/4인듯

​

이 데이터가 없으면 조각의 순서를 추측해야 함, 그러나 이럴 경우 재구축의 가능성이 현저히 낮아짐