SharpEmu 딥다이브
— PS5 게임을 '해석'하지 않고, 게스트 x86-64 코드를 호스트 CPU에서 그대로 실행하는 C# 브리지

1프로젝트 한 줄 요약

SharpEmu는 "PS5용으로 빌드된 게임 실행 파일(eboot.bin)을 PC에서 로드하고, 그 안의 x86-64 기계어를 실행하며, PS5 운영체제 함수 호출을 PC 쪽 구현으로 가로채 대신 처리하는 에뮬레이터"다. 이름은 Sharp(C# = C-Sharp)와 Emulator의 합성어. 대부분의 콘솔 에뮬레이터가 C/C++로 쓰이는 것과 달리, 이 프로젝트는 거의 전부 C#(99.8%)이라는 점이 첫 번째 이례성이다.

2왜 지금 주목받는가

콘솔 에뮬레이션에서 최신 세대(PS5)는 사실상 성배다. PS4용으로는 완성도 높은 ShadPS4가 있지만, PS5는 아직 제대로 게임이 돌아가는 에뮬레이터가 거의 없다. SharpEmu가 별 5개에 불과한 극초기 프로젝트인데도 TrendShift Daily 상위에 오른 건, "누군가 PS5 에뮬을 진지하게 C#으로 시도한다"는 사실 자체가 X·해커뉴스에서 화제가 됐기 때문이다. (TrendShift의 굵은 숫자는 별 수가 아니라 사회적 언급 모멘텀이다.)

주목 포인트 1 — CPU를 "해석"하지 않는 대담한 전략

대부분의 에뮬레이터는 인터프리터나 JIT로 게스트 명령어를 호스트 명령어로 번역한다. SharpEmu는 PS5도 PC도 x86-64라는 사실을 이용해 그 단계를 통째로 건너뛴다. 게스트 코드를 호스트 메모리에 실행 가능 상태로 얹고, 진짜 CPU가 직접 실행하게 한다. 코드에 실제로 CPU 엔진은 NativeOnly 하나뿐이고, 유명한 x86 디스어셈블러 Iced는 실행이 아니라 로그·진단용으로만 쓴다. 이 한 가지 결정이 이 레포의 모든 것을 설명한다.

주목 포인트 2 — 콘솔 에뮬을 C#/.NET 10으로

DolphinㆍRPCS3ㆍShadPS4 등 주류 에뮬레이터는 성능을 위해 C++이 정석이다. SharpEmu는 관리형 언어(managed) C#으로 이 영역에 뛰어들었다. 관리형 언어의 가비지 컬렉터(GC)와 네이티브 게스트 코드가 충돌하는 까다로운 문제를, [UnmanagedCallersOnly] · 손수 emit한 기계어 · 원시 OS 스레드로 정면 돌파한다. "C#으로 이런 것까지 되나?"라는 호기심이 개발자들을 끌어들이는 지점.

주목 포인트 3 — 뼈대가 놀랍도록 깔끔하다 (v0.0.1인데도)

고작 154 커밋짜리 v0.0.1이지만, 코드가 인터페이스로 잘 쪼개져(ISelfLoader·IVirtualMemory·IModuleManager…) 있고, HLE 함수를 [SysAbiExport] 애트리뷰트 하나로 등록하는 플러그인 구조, 8천 줄짜리 실행 백엔드를 partial class로 5조각 나눈 정리까지 — 교재로 삼기 좋은 설계 패턴이 곳곳에 있다. "작동하는 PS5 에뮬"로서가 아니라 "에뮬레이터 아키텍처 학습 자료"로서 값지다.

주목 포인트 4 — 명시적 반(反)불법복제 스탠스

README가 분명히 밝힌다: 저장소에 펌웨어·게임 데이터·소니 자산이 전혀 없고, 테스트에 쓴 게임은 전부 개발자가 직접 소유한 콘솔에서 덤프한 것이며, 사용자도 합법적으로 취득한 사본만 쓰라고 못박는다. 순수 연구·교육 목적임을 반복 강조한다. (에뮬레이터 자체는 합법이며, 이 문서도 그 설계를 공부하기 위한 것이다.)

3기술 스택 전체 지도

SharpEmu는 순수 .NET 솔루션이다. global.json이 SDK를 10.0.103으로 못박고(rollForward: disable), 타깃 프레임워크는 net10.0, nullable·ImplicitUsings 켜짐, 그리고 네 개 프로젝트에서 AllowUnsafeBlocks가 켜져 있다(게스트 메모리를 포인터로 직접 만지기 때문). AOT는 쓰지 않고 JIT + SelfContained + PublishSingleFile로 배포한다.

솔루션 = 6개 프로젝트로 역할 분담

SharpEmu.slnx에 6개 프로젝트가 있고, 의존 방향은 Logging ← HLE ← Libs ← Core ← CLI (GUI는 Logging에만 의존, CLI가 GUI를 호스팅).

핵심 NuGet 패키지 — 무엇으로 무엇을 하나

라이선스 구성도 학습거리다. 프로젝트 전체는 GPL-2.0-or-later이고, REUSE.toml + LICENSES/로 SPDX/REUSE 규격을 지킨다. PS5의 ATRAC9 오디오 코덱을 디코드하는 src/SharpEmu.GUI/Atrac9/만 별도로 MIT(Alex Barney의 LibAtrac9 포팅)다. NID 이름표 파일(aerolib.bin·ps5_names.txt)은 소니 코드가 아니라 함수 이름↔해시 대응표일 뿐이라 저작권 문제가 없다.

4아키텍처 심화 분석

이 섹션의 첫 문장만 기억해도 이 레포의 90%를 이해한 것이다: SharpEmu는 CPU 에뮬레이터가 아니라 "로더 + HLE + 네이티브 실행 브리지"다. 게스트 PS5 코드는 호스트 x86-64 CPU 위에서 직접 돈다. 그래서 이 프로젝트의 어려움은 "명령어를 어떻게 흉내 내나"가 아니라 "내 코드(관리형 C#)와 게스트 코드(네이티브)를 어떻게 안전하게 오가나"에 집중돼 있다.

4-0. 전체 부팅 흐름 한눈에

SharpEmu.CLI "eboot.bin"을 실행하면 SharpEmuRuntime.Run이 아래 파이프라인을 태운다.

4-1. SELF/ELF 로더 — 게임 실행 파일을 메모리에 펼치기

Core/Loader/SelfLoader.cs(2,421줄)가 담당한다. PS5 실행 파일은 리눅스 ELF의 소니 변형(SELF)이다. 로더의 일:

• 매직 판별: SELF 매직 0x4F153D1D이 있으면 SELF 래퍼를 파싱, 없으면 순수 ELF로 취급.
• 세그먼트 매핑: 각 PT_LOAD 세그먼트를 게스트 메모리에 Map(va, size, ...). PS5 이미지 베이스는 0x0000000800000000.
• PS 전용 세그먼트: ProgramHeaderType enum에 표준 Load/Dynamic/Tls 외에 소니 확장 SceRela(0x60000000)·SceDynLibData(0x61000000)·SceProcParam·SceRelro가 있다.
• 동적 재배치: 표준 DT_* + PS 확장 DT_SCE_* 태그를 읽어, R_X86_64_JUMP_SLOT(7)·GLOB_DAT(6)·RELATIVE(8)·DTPMOD64(16, TLS) 재배치를 적용.
• 메타데이터: PS4의 param.sfo가 아니라 PS5의 param.json을 읽어 제목·타이틀ID·버전을 취득.

4-2. NID 해싱 + HLE 디스패치 — "집주인 대역"을 등록하는 법

게임이 sceKernelMapDirectMemory 같은 시스템 함수를 부르면, 이걸 SharpEmu의 C# 구현으로 연결해야 한다. 그런데 PS5 실행 파일에는 함수 이름이 아니라 NID라는 해시가 들어있다. 그래서 두 가지가 필요하다: (1) NID↔이름 대응표, (2) 이름으로 등록된 내 C# 함수를 찾는 디스패치 테이블.

SharpEmu의 scripts/generate_aerolib_binary.py에 실제 NID 계산식이 있다(소니 PS4/PS5 공용 소금값 518D64A6…):

# NID = 함수이름 + 고정소금 → SHA-1 → 앞 8바이트 → base64(+- 변형)
symbol = sha1( name.encode() + unhexlify('518D64A635DED8C1E6B039B1C3E55230') ).digest()
id_val = struct.unpack('<Q', symbol[:8])[0]      # 앞 8바이트를 리틀엔디언 u64로
nid    = base64encode(id_val, altchars=b'+-').rstrip(b'=')  # 11글자 NID

이 스크립트가 ps5_names.txt의 148,678개 함수 이름을 전부 NID로 계산해 12.3MB aerolib.bin(NID↔이름 대응표)을 만든다. 런타임에는 Aerolib.cs가 이 표를 임베드해서 로드한다. 거대한 조회표를 코드가 아니라 오프라인 생성물로 분리한 깔끔한 설계다.

그 다음, 내 C# 구현을 등록하는 방식이 이 레포에서 가장 우아한 부분이다. ModuleManager.RegisterFromAssembly가 리플렉션으로 [SysAbiExport] 애트리뷰트가 붙은 모든 메서드를 훑어 NID → 함수 디스패치 테이블을 자동으로 만든다:

// PS5 함수 하나를 C#으로 구현 = 애트리뷰트 붙인 메서드 하나 (실제 발췌)
[SysAbiExport(Nid="L-Q3LEjIbgA", ExportName="sceKernelMapDirectMemory",
              Target=Generation.Gen4|Generation.Gen5, LibraryName="libKernel")]
public static int KernelMapDirectMemory(CpuContext ctx) {
    // System V AMD64 ABI: 인자는 RDI, RSI, RDX, RCX, R8, R9 순서
    var inOutAddressPointer = ctx[CpuRegister.Rdi];
    var length              = ctx[CpuRegister.Rsi];
    var protection          = (int)ctx[CpuRegister.Rdx];
    var flags               = ctx[CpuRegister.Rcx];
    // ... 게스트 VA 범위를 예약하고 결과를 in/out 포인터로 돌려줌 ...
    // 반환값은 RAX에 기록됨
}

이렇게 등록된 함수가 589개. 새 시스템콜을 추가하려면 애트리뷰트 붙인 메서드 하나만 더 쓰면 끝이다. CpuContext는 게스트 레지스터 파일(GPR 16개 + XMM/YMM)을 흉내 낸 마샬링용 그릇으로, 실제 실행은 호스트 레지스터에서 일어나고 이 그릇은 HLE 경계에서만 채워진다.

4-3. 직접 실행 백엔드 — 관리형과 네이티브의 위험한 악수

Core/Cpu/Native/DirectExecutionBackend.cs(4,796줄, partial class로 5조각 분할)가 실제로 게스트 코드를 돌린다. 여기서 C#의 근본 문제와 마주친다: 가비지 컬렉터(GC)가 스택을 훑을 때, 관리형이 아닌 네이티브 게스트 프레임을 만나면 크래시한다는 것.

SharpEmu의 해법은 대담하다: 게스트 코드를 CLR 스레드가 아닌 원시 OS 스레드(CreateThread) 위에서 돌리고, 그 스레드의 실행 루프를 런타임에 손으로 emit한 x86-64 기계어로 만든다. 실제로 sub rsp,0x28 / WaitForSingleObject / call <진입 스텁> / SetEvent 같은 바이트를 코드가 직접 써넣는다. 이렇게 하면 게스트가 도는 동안 그 스레드에는 관리형 프레임이 하나도 없어 GC의 스택 워킹이 건드리지 않는다.

4-4. 라이브러리 호출이 C#에 도달하기까지 (import 브리징)

게스트가 sceKernelMapDirectMemory를 호출하는 순간을 추적하면 전체 그림이 완성된다. 로더가 미리 심어둔 스텁이 트램펄린을 거쳐 관리형 게이트웨이로 점프한다:

여기 0xCC 0xC3(int3; ret) 스텁이 영리하다. 아직 패치 안 된 함수를 게스트가 부르면 int3가 즉시 폴트를 내 "미구현 함수 호출"이 바로 잡힌다. 구현된 함수는 jmp 트램펄린으로 덮여 관리형 HLE로 우회된다.

4-5. 메모리 관리 — "아이덴티티 매핑"이 강제되는 이유

Core/Memory/PhysicalVirtualMemory.cs(1,091줄)가 게스트 메모리를 관리한다. 핵심 제약: 게스트 네이티브 코드가 게스트 포인터를 직접 역참조하므로, 게스트 가상주소(VA)에 실제 호스트 메모리를 바로 그 주소에 할당해야 한다. 이걸 아이덴티티 매핑이라 한다 — Win32 VirtualAlloc을 게스트 VA에 그대로 얹는다.

// 게스트 메모리 = 게스트 VA에 그대로 얹은 실제 호스트 메모리
// 정렬된 영역 목록 + 페이지 보호 맵을 RW 락으로 보호
List<MemoryRegion>                     _regions;        // 정렬된 영역
Dictionary<ulong, ProgramHeaderFlags>  _pageProtections; // 페이지별 권한
// kernel32: VirtualAlloc / VirtualProtect / VirtualQuery / FlushInstructionCache
// 큰 영역(≥1GiB)은 MEM_RESERVE만, 접근 시 VEH가 지연 커밋(lazy commit)

PS5는 메모리를 두 층으로 본다. SharpEmu도 이를 나눠 모델링한다:

5디렉토리 구조 해부

구조를 읽는 요령: 세 개의 별표(★) 파일이 시스템의 뼈대다 — SelfLoader.cs(파일→메모리), DirectExecutionBackend.cs(코드 실행), PhysicalVirtualMemory.cs(메모리 모델). 그리고 Libs/의 거대한 파일들은 "PS5 OS 함수를 하나씩 채워 넣은" 노가다 영역이라, 처음엔 건너뛰고 뼈대부터 읽는 게 낫다.

6학습 포인트

HLE vs LLE — "얼마나 정확히 흉내 낼 것인가"의 스펙트럼

에뮬레이션의 근본 선택이다. LLE(저수준)는 실제 펌웨어/하드웨어를 바이트 단위로 재현해 정확하지만 느리고 펌웨어가 필요하다. HLE(고수준)는 "이 함수가 하려던 일"을 새로 구현해 빠르지만, 함수 하나하나를 손으로 채워야 하고 미묘한 동작 차이가 버그가 된다. SharpEmu가 sceKernel* 589개를 HLE로 채우는 걸 보면, 이 트레이드오프가 코드량으로 실감난다. 에뮬·가상화·API 셰임(shim)을 다루는 모든 사람에게 보편적인 개념.

애트리뷰트 + 리플렉션 플러그인 레지스트리

[SysAbiExport]를 붙인 메서드를 리플렉션으로 자동 수집해 디스패치 테이블을 만드는 패턴은, 에뮬레이터를 넘어 플러그인 시스템·명령 핸들러·라우터·직렬화기 어디에나 쓰인다. "선언(애트리뷰트)과 등록(리플렉션)을 분리"하면, 새 기능 추가가 "메서드 하나 더"로 끝난다. C#·Java·Python 데코레이터 모두 같은 발상.

관리형 런타임에서 네이티브 코드 다루기 (고급)

[UnmanagedCallersOnly] · GCHandle · 손수 emit한 트램펄린 · GC 스택워크 제약 — 이건 C# 상급 주제의 집합이다. 대부분의 개발자는 평생 만질 일 없지만, "런타임이 내 발밑에서 무엇을 가정하는가"를 이해하는 데 이만한 사례가 없다. 상호운용(interop)·네이티브 AOT·게임 엔진 바인딩을 하는 사람에게 특히.

심볼 난독화와 역해싱 (NID)

이름을 해시로 감추고(소금+SHA-1), 에뮬레이터가 거대한 이름 사전으로 역대응시키는 구조. 역공학·바이너리 분석·심볼 복원의 축소판이다. "왜 그냥 이름을 안 쓰고 해시를 쓰나", "그 해시를 어떻게 되돌리나"를 손으로 재현(실습 참고)하면 리버싱 감각이 크게 는다.

거대한 파일을 다루는 법 — partial class 분할

8천 줄 백엔드를 .cs / .Imports / .Exceptions / .NativeWorker / .Diagnostics로 나눈 partial class는, "한 클래스인데 파일은 여러 개"로 관심사를 물리적으로 분리하는 실전 기법. 거대 코드베이스를 항해 가능하게 유지하는 정리술.

7하드웨어 · 시스템 요구사항

현실 점검: "게임을 돌려보고 싶다"는 목적이면 이 프로젝트는 아직 이르다(플레이 불가). 반면 "에뮬레이터가 어떻게 시작 파일을 로드하고 OS 함수를 대체하는지 코드로 보고 싶다"가 목적이면, 지금이 오히려 가장 읽기 좋은 시기다 — 코드가 아직 작고 뼈대가 선명하기 때문.

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크