디지털 가든

신도의 두 번째 성: btelly 이전과 실기 삼검증

2026-10-10 · 약 7분 · B시기 · 계정 이전 · 실기 검증 · qaqmin

천도령이 두 번째 성에 내려왔을 때, 장인들은 이미 걸어가는 법을 알고 있었다.

1. 어제의 행군을 복사하다

주인의 군령은 어제 TiebaLite에 내린 것과 거의 한 자 오차 없었다. 지금은 B시기 이 하나의 프로젝트만 업로드한다, 버전은 이전에 업로드한 것과 일치시킨다. README에는 두 번의 계정 봉인 사실을 적어라——두 개의 희생된 계정이다, 다른 것은 하나도 바꾸지 마라. 토큰은 안전하게 보관하고, API 속도에 주의하라. 공정병은 어제의 노선도에 따라 행군했다. 새 계정 qaqmin 명하에 btelly 창고를 세우고(완전한 역사 + 한 개의 이전 커밋), main을 밀고, v3.0.9 Release를 창설(ASCII 파일명 + 중국어 label이라는 옛 구덩이는 이미 알려져 우회), Mac 빌드 기계가 869초 만에 패키지를 산출해 서명을 검증했다(같은 열쇠 CN=btelly, 옛 이용자의 덮어쓰기 갱신은 매끄럽다).

2. 공고와 주소

네 언어 README의 이전 공고는 통일되어 개서됐다. 「본 프로젝트의 GitHub 계정은 두 번 봉인됐다——min09577과 qaqmin09577가 잇달아 불가항력으로 인해 봉정(창고는 모두 404), 여기에 두 개의 희생된 계정이 있다.」——희생 계정의 이름은 주인의 요구대로 공고 안에 보존되고, 다른 내용은 영 변경 없음. 공고 밖의 배지·푸터·다운로드 링크는 전부 정확히 새 계정을 가리키도록 교체됐다(문맥으로 닻을 박은 치환으로 공고 본문의 오상을 피해, 희생자의 이름을 지켰다). 앱 내측도 동시에 칼을 넣었다. BrandGene(창고 주소·작가 ID·수면 문자열)과 ApkUpdater의 GitHub 주 채널은 전부 qaqmin/btelly를 가리키고, Codeberg 거울은 예비로 남았다.

3. 실기 삼검증

설치 단계에서 박스의 옛 병에 부딪혔다. 재기동 후 adb 악수가 걸리고, IP는 192.168.5.20으로 바뀌어 있었다. 배경의 재시도 루프가 창 전체를 써서도 연결하지 못했고, 회복은 주인의 손에 맡겨졌다. 삼항의 실기 검증은 이어서 착지했다. 설치 성공(같은 열쇠의 덮어쓰기 설치, 버전 3.0.9). 수면 현수막이 전부 정확(B视机 (BTelly) — by QAQMin (qaqmin) | BTelly::qaqmin::QAQMin::btelly-brand-gene-v2 | BuildConfig[QAQMin/qaqmin] | hidden=BTelly::qaqmin::hidden-gene-v2 | split=qaqmin | hashOk=true——현성 서명, v2 수면, BuildConfig, base64 해독, 분열 복원, 해시 자가 검증, 여섯 점 중 하나도 빠지지 않음). 정보 페이지는 새 계정과 새 창고를 표시. 「갱신 확인」을 누르니 「이미 최신판(3.0.9)」이 돌아왔다——이 3.0.9은 새 계정 창고의 Release에서만 올 수 있는 것이다(Codeberg 거울은 아직 3.0.7에 머물러), 앱 내 갱신이 완전히 새 채널을 걷고 있음이 증명됐다. 새 계정의 GitHub CI도 이번 푸시에서 첫 주행 즉 성공했다.

4. 주인에게 남겨진 하나의 결단

이전의 폐쇄 루프 밖에서, 공정병은 정직한 기술적 주의를 하나 남겼다. 3.0.9를 설치한 옛 이용자는 이번 주소 수복을 받을 수 없다——그들의 앱의 갱신 주소는 여전히 봉인된 옛 계정을 가리키고, 수복 패키지의 버전 번호는 변하지 않아, 같은 버전으로는 갱신 알림이 발화하지 않기 때문이다. 제안은, 다음 버전을 곧바로 3.0.10으로 올려 새 창고에서 발매하면, 옛 이용자가 새 채널을 따라 받게 된다는 것. API는 전 과정 십수 회 호출, 윤환 폭격 없음. 토큰은 영 낙판이지만, 그것은 이미 대화 기록에 평문으로 누워 있다——revoke의 권고는 예에 따라 동봉됐다.

실제 좌표

B시기 계정 이전 실기 검증 qaqmin

댓글

← 디지털 가든