JARVIS-MAGIC

업데이트 2.124

2026. 6. 16.

v2.124.0.0MINORJarvis-MAGIC

아이템 스택 상한 99→255: 신규 `ItemStackCapHook` 에서 `FfxHooksDll` (새로운 기능, 플래그로 제어됨)

(새로운 기능: 런타임 시 새로운 후크 + 바닐라 한도를 초과하여 스택 제한을 해제하는 라이터형 패치; 우리가 이 기능을 처음 다룬 사례) FFX_Inventory_AddItem). 이 발견(idalib MCP를 통해 입증된 바에 따르면 FFX_recon.i64 (2026-06-16): 슬롯당 99개 항목 및 중앙 클램프 제한이 하나의 함수 내에서 FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA 아파트 0x7905A0) — 두 개 push 63h** 제네릭 헬퍼에 데이터 전달하기 ** FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. 14개의 콜러(steal/drop/mix/shop/treasure/event/menu)는 모두 이 단일 함수를 통해 처리되며, 다른 경로에 clamp를 복사하여 붙여넣는 일은 없습니다. 로드 시 정규화 없음 (다음에서 입증됨: FFX_Btl_PrepareSaveCommandState@0x786BC0: 빈 슬롯만 초기화하며, 기존 카운트에 대해서는 오류 메시지를 표시하지 않습니다). 스토리지 (1바이트) QuantityBase+slot 저장 + byte[112] RAM에서 0xD30B5C)는 이미 재할당 없이 0..255를 지원합니다. 선택된 전략: 바이트-나로우 패치는 255에 도달하지 못합니다 (push imm8 6A FF -1인 경우 부호 확장 처리됨) → 트램폴린 + 스텁을 이용한 5바이트 우회 경로 (템플릿과 동일) NovaSuperDamageHook). 각 스텁: push imm32 <cap> ~~을 대체한다 push 63h, 2~~3바이트를 재전송한 후, 다음 경로를 통해 반환합니다. jmp rel32 ~~을 위해 0x00390622/0x00390652. 다음을 통해 설정 가능한 캡 FFXHOOKS_ITEM_STACK_CAP env (기본값 255, 1~~255 범위 내). 게이팅: item_stack_cap_255.flag (기본값은 off = 기본 동작 유지, 자연스러운 회귀 테스트). 패치 적용 전 검증된 센티넬 바이트: kExpectedNew[5] = {6A 63 6A 00 53} (사이트 #1 / 신규 슬롯) 및 kExpectedExist[5] = {6A 63 8D 04 1E} (사이트 #2 / 기존 슬롯). 두 번째 쓰기 작업이 실패할 경우 자동 롤백 (반쯤 설치된 상태로 두지 마세요). PolyHook 빌드 성공 (11/11 cpp, 새로운 ItemStackCapHook.cpp), 배포된 DLL (932352→935936 bytes, (새로운 후크의 +3584). 이름 변경 및 주석 .i64 적용된 사항 (IDA 황금률): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, 댓글은 0x79061D/0x79064D (트램폴린 레시피가 포함된 클램프 사이트). UI 평결 (스파이크 기준): safe-above-99-provavel (getter는 재클램핑 없이 원시 바이트를 반환함; 시각적 위험 = 2자리 레이아웃에서 "100" 이상일 때 오버플로우가 발생할 수 있으나, 포맷터는 %d (3자리 숫자를 입력해도 오류 발생 없음). Phase 3 UI 패치는 사전 적용되지 않음 — RT2 확인. Phase 4 RT2 6가지 시나리오 레시피 (세이브 편집 Quantity=200, 훔치기/버리기, 상점 구매, 혼합, 포션 사용, UI 렌더링)에서 docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 게임 내 테스트 필요 (Halyson). 문서: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. 새 파일: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. 재생된 파일: shared/ffx_addresses.h (새로운 RVA 10개 + 상수), dllmain.cpp (include + 플래그 활성화 기능 + InstallItemStackCapHook을 InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [이전: v2.123.5.1]

v2.124.0.1REVISIONJarvis-MAGIC

론소 마나 (지난 5회 RE): “바라 첼라” 이론은 무효 — 진정한 관건은 메뉴 트리의 매듭을 푸는 것 (`ResolveMenuTreeNode`), 게이지하지 마세요

(RE/doc + 이름 변경/주석 추가) .i64 실제; 아무런 동작 변경 없음, DLL은 그대로 — 다른 방에서도 사용할 수 있음). RT2의 hudSafe=24 (v2.123.4.1) 오류가 발생했으며, 로그를 통해 게이지 라인 전체(hudSafe 23/24)가 잘못된 이유를 확인할 수 있습니다: P0 디스패치 #1..#48, 부하=100, 최대=100 em TODOS os 48 frames (o pino persistente funcionou, a barra ficou genuinamente cheia todo frame) + bits 0x590=0x0D + IsOdReady -> 1 (até vanilla=1) + 311A no anel — e o OD continuou oculto / "esquerda" bloqueada. ⇒ charge==max NÃO é o gate. (Bônus: o log inunda 경고: 명령어 0~49에서 OD 링 헤더를 찾을 수 없음 — ScanForOdRingHeader procura no range errado; o header de OD é cmd282.) O gate REAL (provado por decompile idalib): FFX_Btl_UI_BuildCommandRing@0x7ACEC0 constrói o anel principal (Attack/Skill/Special) via FFX_Btl_UI_BuildMainCommandRingTree@0x7A07D0 só quando kind<=8; o anel Overdrive é kind=12 → PULA 7A07D0 e depende 100% de ResolveMenuTreeNode(2, 1, slot + 41) ≥ 0 (só então sub_7979E0 finaliza). Para Kimahri (slot 2) = Resolve(2,1,43), que retorna −1. A causa exata está em FFX_Btl_UI_WalkMenuBlobIndex@0x797420: idx=blob[2+treeId]; cnt=blob[1]; if(idx==0xFF || treeId>=cnt) return 0 → LookupMenuBlob=0 → 해=−1 → anel OD nunca exibe. Mapeamento das duas vias: principal=Resolve(2, **0**, slot+109) no blob g_FFX_MenuTreeBlob_MainRing (*0x112A994) — resolve OK (user vê); OD=Resolve(2, **1**, slot+41) no blob g_FFX_MenuTreeBlob_OdRing (*0x112A9B4) — Kimahri testa blob[45]. Ambos blobs são DADO ESTÁTICO do recurso system_01 (via FFX_Btl_UI_InitMenuBlobPointers@0x783ED0: blob = base + *(base+N)), idênticos com/sem OD → blob[2+treeId] é índice de nó, não bool (por isso o hudSafe=19 errou a semântica). Nada disso lê 0x5BC/0x5BD (charge/max). Renames+comentários .i64 aplicados e salvos (REGRA DE OURO): 0x112A9B4→g_FFX_MenuTreeBlob_OdRing, 0x112A994→g_FFX_MenuTreeBlob_MainRing, 0x112A9A8→g_FFX_MenuBlobBase_system01 + comentários em 0x797420(fórmula do gate), 0x7985A0, 0x7ACEC0, 0x7A07D0, 0x783ED0. EXPERIMENTO DECISIVO (próximo, precisa de 1 sessão DLL): DIAG no detour de ResolveMenuTreeNode quando a1==2&&a2==1 logando treeId, blobPtr=*0x112A9B4, cnt=blob[1], ``idx=blob[2+treeId], 바닐라의 결과 — **2가지 시나리오**(OD가 가득 찬 것으로 확인된 저장-편집 대 우리의 강제 시나리오) 및 **d iffar the idx/cnt** → 고정값을 정확히 표시합니다 (입력 blob[45]유효하거나, treeId를 리디렉션하거나, 또는case 3연산자별actor+0xF7C). **권장 사항:** 게이지 핀을 원래 상태로 되돌리거나 중화시키십시오. hudSafe=24(그 길은 아니다), 오직gateMin/drainCost(소비량이 이미 확정됨). 문서:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§11. [이전:v2.124.0.0`]

v2.124.0.2REVISIONJarvis-MAGIC

Build+deploy의 `ffx-hooks.dll` (DLL 해제): 다음의 고정 메뉴 바인딩을 구체화합니다. Nul Ward + Nul Ward 및 RT2용 아이템 스택 상한선 플래그; 오프라인 프리플라이트 GREEN

(운영: 이미 버전 관리된 코드의 재빌드+배포 + 플래그 생성; 이번 작업에서는 새로운 소스 코드 동작 없음 — menu-bound 수정 사항은 v2.123.4.0, 편집기의 LearnedMove 인코딩은 해당 항목 자체의 것입니다). Halyson이 DLL을 공개했습니다(Ronso Mana가 이 DLL 사용을 마쳤습니다). 조치: (1) build_hooks.ps1 -WithPolyHook -Release → 10/10 개의 후크가 컴파일되었으며, 다음이 포함됩니다 NulWardTeachHook.cpp 멀티사이트 수정 사항(cmp r32,140h/cmp eax,140h→322, PLACEMENT 루프를 포함한 모든 사이트에 패치를 적용합니다 81 FF=edi) 이전에는 코드 형태로만 존재했던; (2) 다음을 통해 배포 install_to_modules.ps1 -EnableApply -EnableTeach — 이전 DLL의 백업 (ffx-hooks.dll.backup-nul-ward-20260616-071450), 새로운 SHA 접두사 95E1D56A8B9269F7, 깃발 nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) 다른 레인의 요청에 따라 생성된 modules/item_stack_cap_255.flag (비어 있음) → 장전 ItemStackCapHook (스택 상한 99→255; 다른 레인의 훅, 이미 공유 DLL에 컴파일됨, 기본값 FFX_ITEM_STACK_CAP_EXTENDED=255). 게이트 --nul-ward-static 현재 판정: 통과 (exe 바이트 + 322 행 + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL 문자열 + 배포 플래그 + 새로운 클리어). RT2 게임 내 출시 (Nul Ward: 320/321 캐스팅 시 공격으로 전환되지 않음, 오프라인에서 이미 검증됨, 흰색 메뉴에 표기되지 않음 + 그리드 기반 학습 + 지속성; 아이템 스택 상한: 문서 §8의 6가지 시나리오 — 포션 100개 스택, 훔치기/드롭/혼합/상점/보물, 회귀 테스트 플래그 해제). 문서: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1

업데이트로 돌아가기

JARVIS-MAGIC

업데이트 2.124

2026. 6. 16.

v2.124.0.0MINORJarvis-MAGIC

아이템 스택 상한 99→255: 신규 `ItemStackCapHook` 에서 `FfxHooksDll` (새로운 기능, 플래그로 제어됨)

(새로운 기능: 런타임 시 새로운 후크 + 바닐라 한도를 초과하여 스택 제한을 해제하는 라이터형 패치; 우리가 이 기능을 처음 다룬 사례) FFX_Inventory_AddItem). 이 발견(idalib MCP를 통해 입증된 바에 따르면 FFX_recon.i64 (2026-06-16): 슬롯당 99개 항목 및 중앙 클램프 제한이 하나의 함수 내에서 FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA 아파트 0x7905A0) — 두 개 push 63h** 제네릭 헬퍼에 데이터 전달하기 ** FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. 14개의 콜러(steal/drop/mix/shop/treasure/event/menu)는 모두 이 단일 함수를 통해 처리되며, 다른 경로에 clamp를 복사하여 붙여넣는 일은 없습니다. 로드 시 정규화 없음 (다음에서 입증됨: FFX_Btl_PrepareSaveCommandState@0x786BC0: 빈 슬롯만 초기화하며, 기존 카운트에 대해서는 오류 메시지를 표시하지 않습니다). 스토리지 (1바이트) QuantityBase+slot 저장 + byte[112] RAM에서 0xD30B5C)는 이미 재할당 없이 0..255를 지원합니다. 선택된 전략: 바이트-나로우 패치는 255에 도달하지 못합니다 (push imm8 6A FF -1인 경우 부호 확장 처리됨) → 트램폴린 + 스텁을 이용한 5바이트 우회 경로 (템플릿과 동일) NovaSuperDamageHook). 각 스텁: push imm32 <cap> ~~을 대체한다 push 63h, 2~~3바이트를 재전송한 후, 다음 경로를 통해 반환합니다. jmp rel32 ~~을 위해 0x00390622/0x00390652. 다음을 통해 설정 가능한 캡 FFXHOOKS_ITEM_STACK_CAP env (기본값 255, 1~~255 범위 내). 게이팅: item_stack_cap_255.flag (기본값은 off = 기본 동작 유지, 자연스러운 회귀 테스트). 패치 적용 전 검증된 센티넬 바이트: kExpectedNew[5] = {6A 63 6A 00 53} (사이트 #1 / 신규 슬롯) 및 kExpectedExist[5] = {6A 63 8D 04 1E} (사이트 #2 / 기존 슬롯). 두 번째 쓰기 작업이 실패할 경우 자동 롤백 (반쯤 설치된 상태로 두지 마세요). PolyHook 빌드 성공 (11/11 cpp, 새로운 ItemStackCapHook.cpp), 배포된 DLL (932352→935936 bytes, (새로운 후크의 +3584). 이름 변경 및 주석 .i64 적용된 사항 (IDA 황금률): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, 댓글은 0x79061D/0x79064D (트램폴린 레시피가 포함된 클램프 사이트). UI 평결 (스파이크 기준): safe-above-99-provavel (getter는 재클램핑 없이 원시 바이트를 반환함; 시각적 위험 = 2자리 레이아웃에서 "100" 이상일 때 오버플로우가 발생할 수 있으나, 포맷터는 %d (3자리 숫자를 입력해도 오류 발생 없음). Phase 3 UI 패치는 사전 적용되지 않음 — RT2 확인. Phase 4 RT2 6가지 시나리오 레시피 (세이브 편집 Quantity=200, 훔치기/버리기, 상점 구매, 혼합, 포션 사용, UI 렌더링)에서 docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 게임 내 테스트 필요 (Halyson). 문서: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. 새 파일: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. 재생된 파일: shared/ffx_addresses.h (새로운 RVA 10개 + 상수), dllmain.cpp (include + 플래그 활성화 기능 + InstallItemStackCapHook을 InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [이전: v2.123.5.1]

v2.124.0.1REVISIONJarvis-MAGIC

론소 마나 (지난 5회 RE): “바라 첼라” 이론은 무효 — 진정한 관건은 메뉴 트리의 매듭을 푸는 것 (`ResolveMenuTreeNode`), 게이지하지 마세요

(RE/doc + 이름 변경/주석 추가) .i64 실제; 아무런 동작 변경 없음, DLL은 그대로 — 다른 방에서도 사용할 수 있음). RT2의 hudSafe=24 (v2.123.4.1) 오류가 발생했으며, 로그를 통해 게이지 라인 전체(hudSafe 23/24)가 잘못된 이유를 확인할 수 있습니다: P0 디스패치 #1..#48, 부하=100, 최대=100 em TODOS os 48 frames (o pino persistente funcionou, a barra ficou genuinamente cheia todo frame) + bits 0x590=0x0D + IsOdReady -> 1 (até vanilla=1) + 311A no anel — e o OD continuou oculto / "esquerda" bloqueada. ⇒ charge==max NÃO é o gate. (Bônus: o log inunda 경고: 명령어 0~49에서 OD 링 헤더를 찾을 수 없음 — ScanForOdRingHeader procura no range errado; o header de OD é cmd282.) O gate REAL (provado por decompile idalib): FFX_Btl_UI_BuildCommandRing@0x7ACEC0 constrói o anel principal (Attack/Skill/Special) via FFX_Btl_UI_BuildMainCommandRingTree@0x7A07D0 só quando kind<=8; o anel Overdrive é kind=12 → PULA 7A07D0 e depende 100% de ResolveMenuTreeNode(2, 1, slot + 41) ≥ 0 (só então sub_7979E0 finaliza). Para Kimahri (slot 2) = Resolve(2,1,43), que retorna −1. A causa exata está em FFX_Btl_UI_WalkMenuBlobIndex@0x797420: idx=blob[2+treeId]; cnt=blob[1]; if(idx==0xFF || treeId>=cnt) return 0 → LookupMenuBlob=0 → 해=−1 → anel OD nunca exibe. Mapeamento das duas vias: principal=Resolve(2, **0**, slot+109) no blob g_FFX_MenuTreeBlob_MainRing (*0x112A994) — resolve OK (user vê); OD=Resolve(2, **1**, slot+41) no blob g_FFX_MenuTreeBlob_OdRing (*0x112A9B4) — Kimahri testa blob[45]. Ambos blobs são DADO ESTÁTICO do recurso system_01 (via FFX_Btl_UI_InitMenuBlobPointers@0x783ED0: blob = base + *(base+N)), idênticos com/sem OD → blob[2+treeId] é índice de nó, não bool (por isso o hudSafe=19 errou a semântica). Nada disso lê 0x5BC/0x5BD (charge/max). Renames+comentários .i64 aplicados e salvos (REGRA DE OURO): 0x112A9B4→g_FFX_MenuTreeBlob_OdRing, 0x112A994→g_FFX_MenuTreeBlob_MainRing, 0x112A9A8→g_FFX_MenuBlobBase_system01 + comentários em 0x797420(fórmula do gate), 0x7985A0, 0x7ACEC0, 0x7A07D0, 0x783ED0. EXPERIMENTO DECISIVO (próximo, precisa de 1 sessão DLL): DIAG no detour de ResolveMenuTreeNode quando a1==2&&a2==1 logando treeId, blobPtr=*0x112A9B4, cnt=blob[1], ``idx=blob[2+treeId], 바닐라의 결과 — **2가지 시나리오**(OD가 가득 찬 것으로 확인된 저장-편집 대 우리의 강제 시나리오) 및 **d iffar the idx/cnt** → 고정값을 정확히 표시합니다 (입력 blob[45]유효하거나, treeId를 리디렉션하거나, 또는case 3연산자별actor+0xF7C). **권장 사항:** 게이지 핀을 원래 상태로 되돌리거나 중화시키십시오. hudSafe=24(그 길은 아니다), 오직gateMin/drainCost(소비량이 이미 확정됨). 문서:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§11. [이전:v2.124.0.0`]

v2.124.0.2REVISIONJarvis-MAGIC

Build+deploy의 `ffx-hooks.dll` (DLL 해제): 다음의 고정 메뉴 바인딩을 구체화합니다. Nul Ward + Nul Ward 및 RT2용 아이템 스택 상한선 플래그; 오프라인 프리플라이트 GREEN

(운영: 이미 버전 관리된 코드의 재빌드+배포 + 플래그 생성; 이번 작업에서는 새로운 소스 코드 동작 없음 — menu-bound 수정 사항은 v2.123.4.0, 편집기의 LearnedMove 인코딩은 해당 항목 자체의 것입니다). Halyson이 DLL을 공개했습니다(Ronso Mana가 이 DLL 사용을 마쳤습니다). 조치: (1) build_hooks.ps1 -WithPolyHook -Release → 10/10 개의 후크가 컴파일되었으며, 다음이 포함됩니다 NulWardTeachHook.cpp 멀티사이트 수정 사항(cmp r32,140h/cmp eax,140h→322, PLACEMENT 루프를 포함한 모든 사이트에 패치를 적용합니다 81 FF=edi) 이전에는 코드 형태로만 존재했던; (2) 다음을 통해 배포 install_to_modules.ps1 -EnableApply -EnableTeach — 이전 DLL의 백업 (ffx-hooks.dll.backup-nul-ward-20260616-071450), 새로운 SHA 접두사 95E1D56A8B9269F7, 깃발 nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) 다른 레인의 요청에 따라 생성된 modules/item_stack_cap_255.flag (비어 있음) → 장전 ItemStackCapHook (스택 상한 99→255; 다른 레인의 훅, 이미 공유 DLL에 컴파일됨, 기본값 FFX_ITEM_STACK_CAP_EXTENDED=255). 게이트 --nul-ward-static 현재 판정: 통과 (exe 바이트 + 322 행 + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL 문자열 + 배포 플래그 + 새로운 클리어). RT2 게임 내 출시 (Nul Ward: 320/321 캐스팅 시 공격으로 전환되지 않음, 오프라인에서 이미 검증됨, 흰색 메뉴에 표기되지 않음 + 그리드 기반 학습 + 지속성; 아이템 스택 상한: 문서 §8의 6가지 시나리오 — 포션 100개 스택, 훔치기/드롭/혼합/상점/보물, 회귀 테스트 플래그 해제). 문서: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1