NerdNavis_AiDev
/
BurningTimesAi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
BurningTimesAi/공유/기획/GodDem/2026-08-22_원작스테이지_재추출_원본_v1.md

21 KiB
Raw Permalink Blame History

원작 Wild Survival 스테이지 트랙 재추출 원본 SOT v1

작성: 개발팀장 2026-08-22 · 근거: 원작 APK(com.and.wild.sur.victory v862) teamwavepassreward·wildernesspk·wildernesspkconstant 재복호화 실측 + 전체 2938 번들 TextAsset 전수 스캔 트리거: C 스테이지 설계 v1(balance-designer)이 teamwavepassreward dif54 이후 반복 여부를 🔴 미해소로 남기고 "유한+동결"을 재해석 진행 — 청사진v1이 이를 P3-C 선행 조건으로 문자 명시. PD "우선 원작처럼 맞춰 전체 밸런싱 동일성"·"총 스테이지 구성 원작 동일"(2026-08-22) 정합 위해 원작 스테이지 데이터로 유한/무한 확정. PD 지시: "우선 원작처럼 맞춰 전체 밸런싱 동일성 확인 후 추후 변경할 부분을 지시"(2026-08-22) 관계: 2026-08-20_원작밸런스_해독_매핑_v1.md(이하 매핑v1) §2-8 teamwavepassreward 절의 원본 재확정 + 반복 여부 신규 확정. 본 문서가 스테이지 트랙에 한해 매핑v1보다 상위 SOT. 2026-08-22_원작배율_재추출_원본_v1.md·2026-08-22_원작장비_재추출_원본_v1.md와 동일 파이프라인·동일 known-plaintext 키 유도. 표기 규칙(C5·C44): 🟢확정(원작데이터 직접 실측) · 🟡추정(형태·정황 근거) · 🔴미확정. 원작 데이터는 참고 수치만 기재 — 원본 파일·복호화본·XOR 키 레포 미커밋(§8).

0. 결론 요약 — ★ 반복 여부 확정

질문 (C 설계 v1 🔴 미해소) 재추출 판정 근거
teamwavepassreward dif54 이후 무한 반복인가? 🟢 아니다 (무한 반복 데이터상 배제) dif 1~54로 끝나는 유한 authored 테이블. dif55+ 행 부재. loop/next/repeat/cycle 필드가 스키마에 없음. dif54 이후를 위한 추가 보상 데이터를 원작이 애초에 정의하지 않았다(§3).
그럼 원작 스테이지는 유한 설계인가? 🟢 유한 설계 확정 보강 결정 증거: 별개 스테이지 모드 wildernesspk(52스테이지)의 next_id 체인이 1052→0으로 명시적 종료(§4). 원작 스테이지 진행 모드는 데이터 차원에서 유한.
"54 도달 후 동결 vs 완전종료 vs dif1 리플레이" 중 정확히 무엇? 🟡 teamwavepassreward만으로는 미판정 (소비 코드 난독화) teamwavepassreward는 보상 lookup이라 소비 모드의 반복 동작을 담지 않음. il2cpp Beebyte 난독화로 명령어 확증 차단(이전 재추출과 동일 한계). 확정 가능한 것 = "보상 성장은 dif54에서 종료".
C 설계 v1의 "유한 캡(54)" 방향은 원작 정합? 🟢 정합 확정 원작 데이터에 무한 반복 스테이지 구조 증거 전무. 🔴 블로커는 "원작=유한 설계, 무한 아님"으로 해소. "54 이후 동결(clamp)"은 원작이 54 이후를 미정의하므로 GodDem 재량의 안전 구현이며 원작과 모순 없음(§6).
6스텝×9챕터 구조 🟢 정확 일치 기본수열 [2,50,100,200,350,500]이 9챕터 전부 정확 반복(§2-2).
등급배율 [1.0,1.2,1.6,2.0] 🟢 정확 일치 (base≥50) base≥50에서 반올림 완전 정합. base=2(9개 chapter-opener)만 [1.0,1.5,2.0,2.5]로 변형 — 매핑v1 서술 정확 재확인(§2-3).
wildernesspk 스테이지 수·보상 🟢 52스테이지·골드 10000+200/스테이지 dj_1001=10000+200×(n−1), dj_6001=200+20×(n−1) 완전 정합(§4).
EnemyWaveBalance 🟢 원작 부재 (GodDem 자산 확정) config 번들·전체 APK 모두 없음. 청사진 "StageBalance는 GodDem 자산" 재확인(§5).
monsterteam[10001~10052] 🟢 정의 테이블 부재 재확인 + 신규 규명 전체 2938번들 스캔: monsterteam 정의 없음(monsterteamattr만). 단 wildernesspk가 [10001]~[10052]를 FK로 참조 → 정의는 client 밖(서버측 추정)(§5).

총평: C 설계 v1이 🔴로 남긴 "dif54 이후 반복 여부"는 재추출로 **"원작은 유한 설계 — 무한 반복 아님"**으로 확정된다. teamwavepassreward(유한 보상 테이블·loop 필드 없음)·wildernesspk(next_id=0 명시 종료)가 모두 유한을 가리킨다. C v1의 "유한 캡(54)" 방향은 원작 정합이며, 청사진이 P3-C 선행 조건으로 지목한 항목이 데이터로 해소된다. 남는 미확정은 "54 도달 후 소비 모드가 리플레이 허용인지 완전 종료인지"의 미시 동작뿐이며(난독화 차단), 이는 CSV 유한 테이블 구현(C v1)에 영향 없다.

1. 재복호화 결과 (재현 성공)

항목 값
원작 APK C:\Users\sw\Downloads\Wild+Survival+-+Idle+Defense_862_APKPure\UnityDataAssetPack.apk (236MB)
config 번들 assets/yoo/DefaultPackage/60f4b8a79e0efed6b5ada257fb5d9ea8.bundle (config TextAsset 203종)
암호 방식 TextAsset 내용에 22바이트 반복 XOR (자산마다 위치 0 리셋)
키 유도 known-plaintext: 공통 JSON 헤더 22B({\r\n "data": [\r\n {\r)와 암호문 XOR로 결정 유도. 자산 199/203 선두 22B 공통 = 정확히 키 1주기(이전 재추출과 동일 수치). 🚫 키 평문 미보존(scratchpad 한정·작업 후 정리)
검증 teamwavepassreward 216행·wildernesspk 52행·wildernesspkconstant 11행 = 매핑v1 행수와 정확 일치(강력 검증)
전체 스캔 2938 번들 전수 로드(18s, 오류 0) → TextAsset 총 257종 확인(이전 재추출 "2938/257" 정확 재현)

재현 방법(요약, 키 비공개): ① zipfile로 APK에서 config 번들 추출 → UnityPy(1.25.3) 로드 ② TextAsset raw bytes 획득 ③ known-plaintext 헤더로 키 1주기 유도 ④ XOR 복호 → JSON 파싱. libil2cpp 네이티브 리버싱 불요(배율·장비 재추출과 동일 경로).

2. teamwavepassreward 구조 (216행 = 54 dif × 4 wave)

스키마: id, dif, wave, wave_need, reward, activityid, activityrewards — 7열. (매핑v1 "웨이브 보상 티어" 성격 재확인 — HP/난이도 스케일링 테이블이 아니라 보상 티어 lookup 테이블이다.)

  • id 체계: [dif][00][wave] (예: 1001=dif1 wave1, 54004=dif54 wave4).
  • dif = 1~54 연속(54종). wave = 1~4(4종). 216 = 54×4.
  • wave_need = wave별 고정: wave1=50 / wave2=80 / wave3=100 / wave4=999.
  • activityid = 3088 전 행 동일 · activityrewards = dj_19007_2; 전 행 동일.

2-1. reward 구성 (dif1 wave1 예시)

db_2004_12; sl_3901_2; sl_3902_17; sl_3903_12; cj_4001_10;

4개 통화/아이템 구성: db_2004(챕터 단조증가) · sl_39XX(챕터별 고유·기본수열) · cj_4001(고정 10).

2-2. 기본수열 [2,50,100,200,350,500] — 9챕터 정확 반복 🟢

주 보상 아이템(sl_39XX 첫째)의 wave1 값이 6스텝 주기로 9회 반복:

챕터 dif 범위 주 sl 아이템 wave1 수열
1 1~6 sl_3901 [2, 50, 100, 200, 350, 500]
2 7~12 sl_3905 [2, 50, 100, 200, 350, 500]
3 13~18 sl_3906 [2, 50, 100, 200, 350, 500]
4 19~24 sl_3907 [2, 50, 100, 200, 350, 500]
5 25~30 sl_3908 [2, 50, 100, 200, 350, 500]
6 31~36 sl_3909 [2, 50, 100, 200, 350, 500]
7 37~42 sl_3910 [2, 50, 100, 200, 350, 500]
8 43~48 sl_3910 [2, 50, 100, 200, 350, 500]
9 49~54 sl_3910 [2, 50, 100, 200, 350, 500]

9챕터 전부 [2,50,100,200,350,500] 완전 일치 🟢. 챕터 경계(6단위)의 직접 근거 = 기본수열 6스텝 주기(C v1 §13 기각안4의 "6스텝 주기" 근거 데이터 확증).

보상 아이템 ID 챕터별 교체(반복 여부 관련 중요 정황): ch1~ch6은 챕터마다 고유 sl 아이템 3종(3901/02/03 → 3909/15/21). ch7·8·9는 sl_3910/3916/3922 공유(마지막 3챕터 아이템 통합). → 보상 다양성은 ch1~6에서 아이템 종류로, 후반은 db_2004 단조증가로 차등.

2-3. 등급배율 [1.0,1.2,1.6,2.0] — wave 1~4 🟢

base × [1.0, 1.2, 1.6, 2.0] 반올림:

dif(예) base wave 1~4 실측 배율
dif3 100 [100,120,160,200] [1.0,1.2,1.6,2.0]
dif4 200 [200,240,320,400] [1.0,1.2,1.6,2.0]
dif5 350 [350,420,560,700] [1.0,1.2,1.6,2.0]
  • base≥50 구간: [1.0,1.2,1.6,2.0] 반올림 완전 정합(불일치 0).
  • 예외 = base=2 (chapter-opener dif 1,7,13,…,49의 9개): [2,3,4,5] = 배율 [1.0,1.5,2.0,2.5]. base=2가 너무 작아 정수 반올림이 [1.0,1.2,1.6,2.0]과 달라지는 부산물. 총 27건 불일치 = 9 chapter-opener × 3 wave(w2·w3·w4) — 매핑v1 "dif≡1(mod6) 9개 그룹만 [1.0,1.5,2.0,2.5]" 서술과 정확 일치. **설계 의도 배율은 [1.0,1.2,1.6,2.0]**이며 base=2 반올림 변형일 뿐.

2-4. db_2004 (챕터 단조증가 통화) 🟢

dif1~6=12, dif7~12=13, dif13~18=14, ... dif49~54=20   (챕터당 +1, dif54에서 cap 20)

챕터별 [12,13,14,15,16,17,18,19,20]. 후반 챕터 보상 차등의 주 축(sl 아이템이 ch7~9 공유되므로). cj_4001은 전 dif 고정 10.

3. ★ 반복/유한 판정 — teamwavepassreward (핵심 deliverable)

3-1. 데이터가 확정하는 것 🟢

  1. 테이블은 dif 1~54로 유한 종료. dif55, dif56… 행이 존재하지 않음.
  2. loop/next/repeat/cycle/end 필드가 스키마에 없음 — 7개 컬럼(id·dif·wave·wave_need·reward·activityid·activityrewards) 어디에도 "다음 dif로 순환" 또는 "무한 계속" 지시자 부재.
  3. dif54 이후를 위한 추가 보상 데이터를 원작이 정의하지 않음 → 어떤 소비 모드든 dif55+에서 본 테이블로부터 받을 보상이 없다.
  4. → "무한 반복(스케일링) 스테이지" 가설은 데이터상 명백히 배제. 보상 성장은 dif54에서 끝난다.

3-2. 데이터가 확정하지 못하는 것 🟡 (정직 고지)

  • teamwavepassreward는 보상 lookup 테이블이다. "dif54 도달 후 게임이 (a)완전 종료 (b)dif1부터 리플레이 (c)dif54 동결" 중 무엇을 하는지는 소비 모드 코드의 영역이며 본 테이블에 담기지 않는다.
  • 소비 코드는 il2cpp Beebyte 난독화 + 네이티브 컴파일로 명령어 확증 차단(이전 배율·장비 재추출과 동일 한계).
  • 즉 "무한 반복 아님"은 🟢 확정이나, "54 이후 정확한 미시 동작"은 🟡 미확정. 단 이 미시 동작은 C v1의 CSV 유한 테이블 구현에 영향 없다(어느 쪽이든 CSV는 dif1~54만 정의하면 됨).

3-3. 보강 결정 증거 — wildernesspk의 명시적 유한 종료 🟢

teamwavepassreward가 담지 못한 "유한/무한"을, 별개 스테이지 모드 wildernesspk가 명시적으로 답한다: next_id 체인이 1001→1002→…→1052→0으로 종료(§4). 원작의 선형 스테이지 진행 모드는 데이터 차원에서 반복 없이 유한 종료하도록 설계됨이 증명된다. → 원작의 스테이지 설계 철학 = 유한. teamwavepassreward의 유한 authored 구조와 정합.

4. wildernesspk (52 스테이지 선형 캠페인) — next_id=0 유한 종료 🟢

스키마: id, boss_id, next_id, need_level, need_stars, monsterteam, win_rewards, sweep_rewards1/2/3, activityid, activityrewards — 12열. 52행(id 1001~1052).

teamwavepassreward(웨이브 보상 티어, 54dif)와 다른 모드다 — wildernesspk는 보스·몬스터팀·소탕(sweep) 보상을 갖는 선형 스테이지 캠페인(아레나형, §4-3 상수 참조).

4-1. ★ next_id 유한 종료 터미네이터 🟢

1001→1002→1003→ … →1051→1052→0

마지막 스테이지(1052)의 next_id = "0" = 명시적 종료 마커. teamwavepassreward에 없던 "다음 스테이지 포인터"가 wildernesspk엔 있고, 0으로 끝난다 → 데이터 차원의 유한 증명(반복 아님).

4-2. 보상 곡선 🟢

보상 산식 범위
win dj_1001 (골드) 10000 + 200×(n−1) 10000(s1) ~ 20200(s52)
win dj_6001 200 + 20×(n−1) 200 ~ 1220
win dj_16001 (등급 아이템) 1(s1~10) → 2(s11~20) → 3(s21~52) 10단위 breakpoint
sweep_rewards1/2/3 win의 소탕 축소분 (dj_1001·dj_6001 저배율) 3단 소탕 티어

task 힌트 "골드 10000+200/스테이지" = dj_1001 정확 확정 🟢.

4-3. 진입 게이트·구조

  • need_level: 3 → 13 (스테이지 진행에 캐릭터 레벨 게이트).
  • need_stars: 대부분 0, 3곳만 비영(s1041=92, s1046=107, s1051=122) — 특정 스테이지 진입에 누적 별 요구(챕터 관문 추정).
  • boss_id: 15종(519·600·604·606·607·608·609·610·612·616·618·619·622·625·629) 재사용.
  • monsterteam: [10001]~[10052] 52종 참조(§5).

4-4. wildernesspkconstant (11행) — 아레나형 모드 상수

clear_cd · fatigue_value(20) · fatigue_consume(1) · defeat_cd(600) · battleItemRecoverCD(10800) · battleItemRecoverLimit(3) · battleUseItem(dj_15001) · freeUseItem(dj_15002) · arena_open_stime(Monday 4) · arena_open_etime(Sunday 23) · dayFreeCnt(1).

  • 주간 개방(Monday~Sunday)·피로도·일일 무료횟수 = 시간 게이트형 아레나/PvE 진행 모드.
  • max stage/loop 상수 없음 — 유한성은 §4-1 next_id=0로 인코딩(상수 아님).

5. EnemyWaveBalance 부재 + monsterteam[10001~10052] 재확인

5-1. EnemyWaveBalance 🟢 부재 (GodDem 자산)

  • config 번들 203종·전체 2938번들 257 TextAsset 어디에도 EnemyWaveBalance/enemywave 없음.
  • 청사진v1·C v1 "EnemyWaveBalance·StageBalance는 GodDem 자체 자산" 재확인. 원작 웨이브/스테이지 절대 몬스터 스탯은 client 데이터에 없다 → GodDem 챕터 곡선(C v1 §3)은 창작이 유일 경로(4:1 비율·S3 앵커 위 창작) — 재추출로 재확증.

5-2. monsterteam[10001~10052] 🟢 정의 부재 재확인 + 신규 규명

  • 전체 2938번들 전수 스캔: 이름이 정확히 monsterteam인 TextAsset 없음. monster 포함은 5종(A80KillMonsterTopRank-A/C·A80TopRankingShop_KillMonster·CrossMonsterKillPointConfig·monsterteamattr)뿐 — 몬스터 팀 정의 테이블 부재 확정(이전 재추출 승계 재확인).
  • ★ 신규 규명: wildernesspk가 monsterteam 컬럼에서 [10001]~[10052]를 FK로 참조한다(§4). 즉 10001~10052 ID는 실제 사용되나 정의 테이블이 client 밖(서버측 추정)이다. → "부재"의 정확한 성격 = 참조는 존재, 정의는 서버측/client 미포함. 몬스터 절대 스탯 이식 원천 불가 결론은 불변, 단 "ID 자체가 없다"가 아니라 "정의가 client에 없다"로 정밀화.

6. C 설계 v1과 원작의 괴리 (balance-designer 인계 핵심)

항목 C v1 (설계) 원작 재추출 (확정) 괴리 성격
dif54 이후 반복 여부 🔴 미해소 → "유한+동결" 재해석 진행 🟢 유한 설계 확정(무한 반복 배제) 🔴 해소. C v1 방향이 원작 정합으로 확증
총 스테이지 수 54(teamwavepassreward dif) teamwavepassreward=54dif · wildernesspk=52스테이지(별개 모드) 모드 구분 필요(§7-2) — C v1의 54 채택은 웨이브 보상 티어 기준
6스텝×9챕터 채택 🟢 기본수열 6스텝×9주기 정확 일치 정합
등급배율 [1.0,1.2,1.6,2.0] 🟢 base≥50 정합, base=2만 [1.0,1.5,2.0,2.5] 반올림 변형 C v1이 "기본 수량 충분히 크게 잡아 배율 일관 유지"(매핑v1 §193) 판단 = 재추출로 유효 확인
몬스터 HP 스케일링 챕터별 StageStep 창작(2.1→1.02) 원작 절대 스탯 부재(EnemyWaveBalance·monsterteam 정의 없음) 창작 불가피 재확인 — 원작엔 이식할 HP 곡선 자체가 client에 없음
Stage55+ 처리 "dif54 동결(clamp)" 제안(PD 확인 필요) 원작이 54 이후 미정의 동결은 GodDem 재량 안전 구현 — 원작과 모순 없음(원작엔 55+ 개념 자체 부재)
골드 보상 이식 킬당 산식 무변경(원작 이산 보상 미채택) wildernesspk=클리어당 이산 골드(10000+200/s), teamwave=웨이브패스 이산 C v1 "구조가 달라 미이식" 판단 유효 — 원작 골드는 이산 클리어 보상, GodDem은 연속 처치 보상

7. balance-designer C v2 재산정 인계 노트

  1. 🔴 블로커 해소: "dif54 이후 반복 여부"는 재추출로 "원작=유한 설계, 무한 반복 아님" 확정. C v1 §0·§6·§7이 "팀장·PD 확인 필요"로 상신한 3건 중 (b) 재추출 미해소 항목은 데이터로 해소된다 — C v2는 "유한 캡(54)"을 원작 정합 근거와 함께 확정 가능. 단 (a) 유한화 방향 자체·(c) 55+ 동결 처리는 여전히 PD 결정 영역(원작이 유한임은 확정됐으나, GodDem이 원작 유한성을 채택할지·55+를 어떻게 처리할지는 설계 선택 — 원작 데이터가 강제하지 않음).

  2. ★ 54 vs 52 모드 구분 (C v2 명시 권고): 원작엔 유한 스테이지 트랙이 2종 존재 — ⓐ teamwavepassreward(54 dif × 4 wave, 웨이브 보상 티어, C v1이 채택) ⓑ wildernesspk(52 스테이지 선형 보스 캠페인, next_id=0 유한). GodDem Survival(웨이브 기반)엔 ⓐ가 형태 근접하나, PD "스테이지"가 ⓑ(선형 52 캠페인)를 지칭했을 여지도 배제 불가. C v2는 어느 모드를 이식 기준으로 삼는지 명시할 것(현 C v1은 ⓐ 54 기준).

  3. teamwavepassreward는 보상 테이블 — HP 아님: C v1이 54dif·6×9 **형태(shape)**를 스테이지 골격으로 차용한 것은 유효하나, teamwavepassreward는 보상 티어 lookup이지 몬스터 HP 곡선이 아니다. HP 스케일링(챕터 StageStep)은 원작에 이식원이 없어(§5) GodDem 창작이 유일 경로 — 재추출로 재확인. C v2 챕터 곡선은 계속 플레이테스트 튜닝 대상.

  4. 등급배율 이식: [1.0,1.2,1.6,2.0]이 설계 의도. GodDem은 기본 수량을 base≥50 이상으로 잡아 배율 일관 유지(base=2 반올림 변형 회피) — C v1 판단 유효.

  5. 원본값 확정분 (C v2 참조):

    • teamwavepassreward 기본수열: [2,50,100,200,350,500] (9챕터 불변) · 등급배율 [1.0,1.2,1.6,2.0] · db_2004 챕터 [12…20].
    • wildernesspk 골드: 10000+200×(n−1)(n=1~52) · dj_6001 200+20×(n−1).
    • wave_need(teamwave): wave1~4 = 50/80/100/999.

8. 저작권·키 취급 (PD 방침 준수)

  • 원작 데이터는 참고 수치만 본 문서에 기재. 원본 파일·복호화본(dec_*.json)·추출 스크립트는 scratchpad 한정(C:\Users\…\Temp\claude\…\scratchpad, 레포 외부) — 작업 완료 후 정리.
  • 22바이트 XOR 키는 **작업용 임시 유도(known-plaintext)**만 — 본 문서·조직 기록에 평문 미기재.
  • 레포 커밋 금지 확인: 복호화 원본은 Temp 하위(레포 외부)라 자동 미커밋. GodDem 레포(E:\NerdNavis\GodDem) 수정 0건(데이터 추출만). 본 문서(참고 수치 전용)만 BurningTimes 레포 산출.
  • 재해독 필요 시 원작 APK에서 §1 방법으로 재추출(공개 JSON 헤더 known-plaintext로 키 재유도 결정·재현 가능).

9. 실측 검증 요약 (C5·C23·C44 — 정직 보고)

검증 항목 결과 근거
config 번들 복호화 🟢 성공 헤더 정상 JSON, 행수 매핑v1 일치(216/52/11)
teamwavepassreward 216행 = 54dif×4wave 🟢 정확 dif 1~54 연속·wave 1~4 실측
기본수열 [2,50,100,200,350,500] 9챕터 반복 🟢 정확 일치 9챕터 전부 실측 True
등급배율 [1.0,1.2,1.6,2.0] 🟢 정합(base≥50) base=2 27건은 반올림 변형(매핑v1 정확 재확인)
teamwavepassreward loop/next 필드 🟢 부재 확정 7개 컬럼 전수 — 반복 지시자 없음
wildernesspk next_id=0 유한 종료 🟢 확정 1052 next_id="0" 실측
wildernesspk 골드 10000+200/스테이지 🟢 정확 dj_1001 산식 완전 정합
EnemyWaveBalance 부재 🟢 확정 config·전체 2938번들 없음
monsterteam 정의 부재 + FK 참조 존재 🟢 확정 2938번들 전수 스캔(monsterteamattr만) + wildernesspk [10001~10052] 참조
재추출 실패·부분 확정 "54 이후 소비 모드 미시동작"만 🟡 il2cpp 난독화 차단(§3-2). 무한 반복 배제·유한 설계는 🟢 확정

미확정/한계(정직 고지): "dif54 도달 후 소비 모드가 완전 종료/리플레이/동결 중 무엇인가"의 미시 동작은 teamwavepassreward(보상 lookup)에 담기지 않으며 소비 코드 il2cpp Beebyte 난독화로 확증 차단. 단 (1)무한 반복 스케일링 배제 (2)원작 유한 설계 (3)wildernesspk 명시 유한 종료는 데이터로 🟢 확정되며, 이 미시 동작 미확정은 C v1의 CSV 유한 테이블 설계·구현에 영향 없다(CSV는 dif1~54만 정의하면 충족).