Programist's Laboratory

윈도우폰을 이용하여 콘솔 작업을 할 수 있는 방법이 없는지 검색하는 중, 마이크로소프트 공식 블로그에서 윈도우폰에 대한 MS-DOS를 지원하는 앱을 발표한 것을 보고 설치해서 돌려 보았다.

https://blogs.windows.com/devices/2015/04/10/our-guide-to-the-new-ms-dos-for-mobile-app-for-windows-phone/

다음과 같이 MS-DOS 부팅이 가능하며, 콘솔을 이용하여 기본적인 윈도우폰의 앱 실행과 이스터 에그처럼 Windows 3.1에 대한 UI를 지원한다. 하지만 그 이외에 PC와 모바일 간의 연결하는 방법은 아직 찾지 못하여 해매는 중이다.

노키아가 마이크로소프트에 인수되고 윈도우폰으로 달고 나온 Lumia 시리즈...

마이크로소프트에서는 이제 Lumia 시리즈를 생산 중단하기로 결정을 내렸다고 한다.

서피스폰으로 다시 출시한다는 소식도 있기 때문에, 마이크로소프트가 윈도우폰을 접는다라기보다는 서피스 시리즈로 내놓지 않을까 기대를 하며, 맛보기로 마지막 루미아 시리즈를 구매해서 사용해보았다.

마치 데스크탑 윈도우 10을 그대로 스마트폰으로 옮겨놓은 느낌에 UI도 데스크탑 윈도우와 흡사한 부분이 많아, 처음 사용에도 불구하고 아무런 불편함이 없었으며, 오히려 '오호라~?'라고 느껴지는 몇몇 부분에서는 감탄이 나오는 폰이였다.

  - 최초 구동 시, 설정 화면

상당히 깔끔하며, 최초 구동시 안드로이드와 유사한 환경 설정을 보여준다. 최초에 디바이스에 저장된 OS에서는 상당히 불안정한 모습과 앱 실행 도중 Hang이 걸리는 모습들이 자주 보였으나, OS 업데이트 후 상당히 안정화가 된 것을 느낄 수가 있었으며, 다양한 윈도우폰용 앱들만 주어진다면 쓸만하겠다라는 느낌도 받았다.

  - UI 및 응용 앱들 구동

우분투를 디폴트로 설치할 경우, 기본으로 X-Window로 설치가 진행된다.

GUI를 사용하지 않는 환경에서는 오히려 GUI가 불필요하게 리소스만 차지하기 때문에 CUI로 변경하는 것이 효율적일 것이다.

이번 포스팅은 우분투에서 GUI모드에서 CUI 또는 콘솔 모드 혹은 텍스트 모드로 부팅하도록 변경하는 방법을 설명한다.

1. grub 편집

아래 그림과 같이 GRUB_CMDLINE_LINUX_DEFAULT를 "text"로 변경하여 저장

2. 수정된 grub를 update

3. update후 재부팅

테스트 환경 : Ubuntu 16.04

간혹 root 계정 비밀번호를 잊어버릴 경우 난감할 때가 있다.

이럴 경우, 시스템이 물리적인 환경에서 접속이 가능하다면 single 모드로 접속하여 root 계정 비밀번호 변경이 가능하다.

시스템 부팅 전, Esc 키를 이용하여 부팅 설정 모드로 접속한 후, 'e'키를 눌러 편집 모드로 들어간다.

root 권한으로 작업하는 사람들에겐 매번 root 로그인을 하는 것이 다소 번거로운 작업일 것이다.

root 계정으로 로그인 설정은 다음과 같은 방법으로 변경이 가능하다.

 - /etc/lightdm 경로로 이동하여 lightdm.conf 파일을 생성

  - root 계정 로그인을 위한 설정 정보 입력 후 저장

바로 재부팅을 하면 다음과 같이 tty 에러 메시지를 확인할 수 있다.

if `tty -s`; then으로 해당 메시지를 slient한다.

재부팅 후, 터미널을 열면 다음과 같이 root 계정으로 로그인 된 것을 확인할 수 있다.

테스트 환경 : Ubuntu 16.04

Ubuntu에서는 기본적으로 root 로그인을 허용하지 않는다. 

따라서, 설치 직후 일반 계정으로 설치 후 "su" 명령어를 사용하여 root 계정에 접근하려고 하면

비밀번호 설정이 되지 않아 접근이 불가능하다.

따라서, 다음과 같은 방법으로 root 계정의 Password 설정을 한 후에 root 계정 접근이 가능하다.

맨 처음 일반 계정으로 로그인한 비밀번호를 인증한 후, root 계정에 대한 비밀번호를 설정하면

다음과 같이 root 계정에 접근 가능할 것을 확인할 수 있다.

테스트 환경 : Ubuntu 16.04

Suricata는 OISF에서 개발한 NIDS/IPS로, 2010년에 발표한 이후 빠르게 성장한 오픈소스 프로젝트이다.
​Suricata는 오랫동안 사용된 IDS인 Snort의 단일 스레드 방식에서 벗어나, 대용량 트래픽을 실시간으로 처리 할 수 있도록 멀티 코어/멀티 스레드를 지원하며, 기존의 Snort룰을 완벽하게 호환하기 때문에 Snort 사용에 익숙하다면 Suricata를 사용하는데 무리가 없을 것이다.

Suricata : https://suricata-ids.org

1. Suricata 설치
  - 필요 라이브러리 설치

  - Suricata 다운로드 (https://suricata-ids.org/download)

  - Suricata 설치

다음과 같이 Suricata에서는 다양한 기능들을 지원한다. 혹여나 필요한 라이브러리가 있다면 필요에 맞게 Configure 설정을 하여 컴파일을 하도록 한다.

  - Suricata 실행

2. Suricata 설정 및 로그

  - Suricata 설정 경로 (/etc/suricata)

- Suricata 로그 경로 (/var/log/suricata)

3. Suricata를 이용한 파일 추출
Suricata에서는 파일 시그니쳐 및 파일 확장자명을 이용한 파일 추출 기능을 제공한다.
  - Suricata를 이용한 네트워크 통신 파일 추출 룰 경로 (/etc/suricata/rules/files.rule)

  - Suricata 설정 수정

      = 추출할 파일의 룰 설정 파일 명시

      = 추출할 파일 저장 기능 및 로그 활성화

      = 추출할 파일의 stream 크기를 무제한 설정

  - NIC offloading 설정 변경

  - 추출된 파일 로그 확인 (/var/log/suricata/files-json.log)

  - 추출된 파일 저장 경로(/var/log/suricata/files)
      = file.ID ​형식으로 저장되며 메타 정보는 file.ID.meta를 통하여 파일에 대한 메타 정보를 확인할 수 있다.

테스트 환경 : Ubuntu 16.04

Apache Kafka는 LinkedIn에서 2011년 오픈 소스로 공개된 메시지 큐 시스템이다.
MQTT처럼 Broker(중개자) 서버를 두고, Producer/Consumer(생산자/소비자) 방식으로 동작한다. 이는 MQTT의 Broker 서버와 Publish/Subscribe 방식과 유사함을 알 수 있다.

Apache Kafka는 다음과 같이 Zookeeper 연동을 지원하며, Broker 서버를 클러스터로 구성 가능하다. 이를 통하여 메시징 큐의 안정화 및 분산 처리 작업이 가능하며 그 성능 또한 우수하다고 한다.

출처 : http://notes.stephenholiday.com/Kafka.pdf

1. Apache Kafka 설치
​  - Kafka 다운로드 (https://kafka.apache.org/downloads)

  - Kafka 압축 풀기

Apache Kafka 테스트를 위한 네트워크 환경 구성은 아래와 그림과 같은 구조이며, 이를 바탕으로 설정 방법을 설명한다.

2. Zookeeper 설정
  - config/zookeeper.properties 수정

다음과 같이 각 Broker 서버에 설치된 Kafka의 config/zookeeper.properties에 다음과 같이 각 Broker 서버에 설정 정보를 입력 후 저장한다.

또한, 각 서버의 /tmp/zookeeper에 myid 파일을 생성하여, 각각 서버의 고유 ID값을 부여한다. 만약 /tmp/zookeeper 디렉토리가 없다면 생성한다.

  - Broker Server 1 (IP : 192.168.0.101)

  - Broker Server 2 (IP : 192.168.0.102)

  - Broker Server 3 (IP : 192.168.0.103)

3. Kafka 설정
  - config/server.properties 수정

각 서버의 config/server.properties에 해당 설정 활성화 및 Broker Server 정보를 입력한다.

  - Broker Server 1 (IP : 192.168.0.101)

  - Broker Server 2 (IP : 192.168.0.102)

  - Broker Server 3 (IP : 192.168.0.103)

4. 서버 구동

서버 구동이 완료되면 다음과 이 Kafka 서버가 정상적으로 시작했음을 알 수 있다.

5. Topic 생성 및 삭제

  - Topic 생성

replication-factor : 인스턴스 개수
partitions : 병렬 처리를 위한 개수

  - Topic 리스트 확인

  - Topic 삭제

  -  Topic의 partition과 replication-factor에 대한 상세 정보 확인

6. Producer/Consumer 테스트
  - Producer 테스트

  - Consumer 테스트

테스트 환경 : Ubuntu 16.04

MQTT (Message Queuing Telemetry Transport)는 1999년에 발표한 오픈 프로토콜로 낮은 대역폭, 높은 지연이나 신뢰 할 수 없는 네트워크를 위하여 설계된 경량적인(라즈베리파이에서도 사용가능) 메시지 프로토콜이다.

Google에서는 푸시 알림 서비스로 GCM(Google Cloud Messaging)을 제공하며, Apple에서는 APNs(Apple Push Notification service)을 서비스로 제공한다.

이와 마찬가지로 푸시 알림 서비스를 활용하는데 있어서, 자체적인 서비스를 만들고 싶다면 MQTT로 활용이 가능하다.

대표적으로, Facebook Messenger에서는 푸시 알림 서비스 방식으로 MQTT를 활용하고 있다고 한다.
출처 : https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

MQTT는 중개자(Broker) 서버를 두고, 발행/구독(Publish/Subscribe) 방식으로 동작하는 환경에서 이용하는 프로토콜이다.

이번 포스팅에서는 간혹 악성코드에서 사용되는 dex 파일을 DES 암호화 한 후, 이를 복호화하여 dex를 load하는 방법인 DES 암호화 패킹에 대한 복호화 방법을 설명한다.

흔히 이 방법은 다음과 같은 형태의 클래스 형태를 띄고 있다.

NoApp 클래스를 분석하면, 아래 그림과 같이 Assets 폴더 내부에 ns 파일을 DES key인 gjaoun을 이용하여 복호화하는 것을 알 수 있다.

해당 코드를 바탕으로 Assets 폴더 내부의 ns 파일을 복호화하는 코드는 아래와 같다.

복호화된 dex파일을 디컴파일을 이용하여 열면 다음과 같이 기존 dex파일과 다른 구조의 실제 악성행위를 하는 dex 파일을 확인할 수 있다.