REA 네이티브 분석: ‘File too large’ 오류는 왜 발생할까요?

01. 오류를 진입점으로 사용하기

애플리케이션이 파일을 거부하며 화면에 ‘File too large’라고 표시합니다. 바이트 수, 디코딩된 픽셀 수, 압축 크기, 서비스 한도 중 무엇을 뜻할까요? 자신의 구현을 바꾸기 전에 판단 로직을 파악하세요.

대상에서 정확한 메시지 하나를 고르세요. 네이티브 엔진이 분석한 문자열에서 검색하세요. 결과가 없다고 메시지가 없다는 뜻은 아닙니다. 현지화되거나 인코딩되었거나 런타임에 조합되거나 실행 파일 밖에 저장될 수 있습니다.

npx -y [email protected] search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. 문자열을 사용하는 함수 찾기

검색 결과의 주소로 참조를 확인하세요. 참조는 실제 보호 조건이 아니라 일반적인 오류 표시 헬퍼를 가리킬 수 있습니다. 오류를 보고할지 결정하는 분기를 찾을 때까지 호출자를 따라가세요.

아래 자리표시자는 자신의 바이너리에 대해 반환된 주소로 바꿔야 합니다. 다른 빌드의 주소를 그대로 사용할 수는 없습니다.

npx -y [email protected] xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y [email protected] decompile "/absolute/path/program" --procedure="RETURNED_FUNCTION_ADDRESS" --provider ghidra --format json

03. 단위를 포함해 비교 조건 파악하기

비교하는 양쪽 값을 식별하세요. 크기 값의 출처, 비교 전에 산술 연산이 수행되는지, 분기가 초과인지 이상인지를 추적하세요. 이 세부 사항이 경계 사례를 결정합니다.

디컴파일된 이름과 자료형은 잠정적인 가설로 보세요. 결과가 불완전하다면 선택한 함수의 명령어와 피호출 함수를 확인하세요. 의사 코드가 단순해 보여도 부호 여부, 정수 비트 폭, 변환 순서에 따라 결과가 바뀔 수 있습니다.

반환된 함수 근거를 사용해 이 오류를 발생시키는 분기를 설명하세요. 비교되는 값을 입력까지 거슬러 추적하세요. 임계값, 단위, 부호 여부, 정확한 비교 연산을 식별하세요. 디컴파일 결과가 불완전하면 명령어와 관련 헬퍼를 분석하세요. 주소를 명시하고 확인되지 않은 자료형은 추측하지 말고 미해결로 표시하세요.

04. 정상 사례뿐 아니라 경계 확인하기

파악한 규칙이 임계값 L을 사용하면 입력의 실제 단위로 L−1, L, L+1을 테스트하세요. 애플리케이션이 입력을 받는 범위에서 0과 잘못된 형식의 입력도 테스트하세요. 직접 통제하는 프로그램 복사본에서만 실행하세요.

파일 크기 보호 조건이라면 파일 바이트 수와 관찰된 결과를 기록하세요. 디코딩된 이미지에 대한 보호 조건이라면 파일 바이트 수만 바꿔서는 관련 조건을 검증하지 못할 수 있습니다. 같은 입력을 대체 구현과 비교하고 불일치를 저장하세요.

• L−1: 허용되나요, 거부되나요?
• L: 같은 값이면 통과하나요?
• L+1: 어떤 오류가 반환되나요?
• 잘못된 형식의 입력은 다른 분기에서 먼저 실패하나요?

05. 근거 범위 안에서 결론 내리기

최종 결과물은 파악한 규칙 하나와 그 규칙에 실행한 테스트입니다. 이 글을 위해 특정 대상에 이 절차를 실행한 것은 아닙니다. 오류 문구는 자신의 사례로 바꿔 사용할 시나리오입니다.

같은 원칙을 적용한 실제 예제로 REA 프로젝트의 DX-Ball 소리 패닝 함수 분석이 있습니다. 보고서는 입력별 차등 검증 3,205건과 별도의 63바이트 컴파일러 결과 일치를 구분합니다. 어느 주장도 게임 전체를 재구현했다는 뜻은 아닙니다. 해당 분석은 연결된 공식 네이티브 가이드와 사례 연구를 확인하세요.