역분해(Decompilation)는 저수준 기계 코드 스니펫을 C와 같은 고수준 프로그래밍 언어로 다시 변환하는 과정이다. 이는 역공학자들이 코드의 맥락적 의미론을 이해하는 데 도움을 주기 위한 기반으로 활용된다. 이러한 점에서 Hex-Rays와 같은 상용 역분해기들은 시간이 지남에 따라 역분해된 코드의 가독성을 향상시키는 데 상당한 성과를 거두었다. 선행 연구에서는 식별자, 변수명, 함수명, 주석을 포함한 소스 코드의 가독성을 평가하기 위한 메트릭을 제안해 왔으나, 주로 i) 소스에서 풍부한 의미론적 정보가 부족하고 ii) 오류가 있는 문법 또는 부적절한 표현이 존재하기 때문에 이러한 메트릭들은 역분해 코드의 가독성을 측정하기에 적합하지 않다. 이에 대응하여, 본 연구는 우리가 아는 한 역분해 코드를 상대적 맥락에서 정량적으로 평가하기 위해 특화된 메트릭인 R2I(Relative Readability Index)를 최초로 제안한다. 본질적으로 R2I는 i) 서로 다른 역분해기들로부터 얻은 코드 스니펫을 입력으로 하고 ii) 추상 구문 트리(abstract syntax tree)에서 사전에 정의된 특징들을 추출함으로써 계산될 수 있다. R2I의 견고성을 확보하기 위해, (비)상용 역분해기와 학술 연구가 코드 가독성을 증진하기 위해 수행해 온 향상 노력을 면밀히 조사하였고, 신뢰할 수 있는 지수를 집합적으로 산출하기 위해 31개의 특징을 식별하였다. 또한 본 연구는 개인의 코딩 스타일 및 선호와 같은 주관적 요인을 포착하기 위해 사용자 설문을 수행하였다. 실증 실험 결과, R2I는 역분해 코드의 상대적 품질(예: 난독화, 역분해기 업데이트)을 나타낼 수 있는 다목적 메트릭이며, 설문에서의 인간의 인식과도 잘 일치함을 보여준다.

자바 네이티브 인터페이스(Java Native Interface, JNI)는 자바 애플리케이션이 네이티브 라이브러리에 접근할 수 있게 하지만, 올바른 JNI 프로그램을 개발하는 것은 어렵다. 네이티브 코드를 활용함으로써 JNI는 자바 개발자가 효율적인 애플리케이션을 구현하고 C 및 C++와 같은 다른 프로그래밍 언어로 작성된 코드를 재사용할 수 있도록 한다. 핵심 자바 라이브러리는 그래픽 사용자 인터페이스와 같은 시스템 기능을 제공하기 위해 JNI를 사용하며, 주류 자바 가상 머신(Java Virtual Machine, JVM) 또한 JNI를 지원한다. 그러나 서로 다른 프로그래밍 언어 간의 복잡한 상호작용 의미론 때문에, 올바른 JNI 프로그램을 구현하는 일은 사소하지 않다. JVM은 성능 오버헤드 때문에 기본적으로 JNI 상호작용을 검증하지는 않지만, 두 가지 방법을 제공한다. 첫째, JVM은 JNI 명세에서 정의된 상호작용 실패를 런타임에 보고한다. 둘째, JVM은 JNI 상호작용을 검증하지만 런타임 성능을 저하시킬 수 있는 디버그 옵션을 지원한다. 우리가 아는 한, 잘못된 JNI 상호작용이 부정확한 동작을 유발할 수 있음에도 불구하고, JVM의 이러한 방법들의 품질은 문헌에서 충분히 연구되지 않았다. 본 논문에서는 잘못된 JNI 상호작용에서의 JVM 동작을 경험적으로 연구한다. 체계적인 연구를 위해, 우리는 JNI 명세로부터 잘못된 상호작용을 유발하는 JNI 테스트 프로그램을 생성하는 반자동 도구 JUSTGen을 제안한다. JUSTGen은 도메인 특화 언어(DSL)로 작성된 JNI 명세를 입력으로 받아, SMT 솔버를 사용해 상호작용에서 런타임 오류로 이어질 수 있는 사례를 자동으로 찾아낸다. 이어서, 이러한 잘못된 사례에서의 동작을 유발하는 테스트 프로그램을 생성한다. 생성된 테스트를 사용하여, 우리는 잘못된 JNI 상호작용에서 JVM의 실패 처리 메커니즘과 디버그 옵션의 기능을 경험적으로 평가한다. 실험 결과, JVM이 실패를 처리하지 않거나 명세와 다르게 처리하는 잘못된 사례들이 존재함을 확인했다. 또한 JNI 디버그 옵션이 수천 개의 잘못된 사례를 검증하지 못하며, 이는 메모리 부패(memory corruption) 및 자바 타입 시스템 위반과 같은 치명적인 런타임 오류를 유발할 수 있음을 발견했다. 우리는 JVM이 실패를 올바르게 처리하지 않는 18개의 잘못된 사례를 각 해당 벤더에 보고했으며, 그중 16개 사례는 해결되었다.