업데이트 방법을 적은 게시글이 용량 초과라서 아래 부분은 별도 게시글로 작성합니다.

--------------------------------------------------------------------------------------------------

여기서부터는 혹시나 해당 값을 찾은 과정에 관심 있을 분들을 위한 내용입니다. 업데이트만 하실 거면 안 보셔도 돼요!

먼저 무한부팅이 걸렸을 때의 logcat 중 눈에 띈 부분이 있었습니다.

10-31 22:03:45.774  1034  1034 I bootstat: Canonical boot reason: shutdown,region_error

region_error에 의해 shutdown이 되었다고 해석할 수 있는 상황이었습니다.

혹시나 해서 region_error를 bootstat 실행파일이 구글 소스에도 가지고 있나 확인을 해보았는데 없었기 때문에 레노버가 넣은게 맞구나 확신을 했었네요.

그래서 region 관련해서 혹시 다른 로그가 있나 싶어서 살펴본 결과

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[0] = 26 ,&

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[1] = ca ,ʍ

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[2] = 1a ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[3] = 01 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[4] = 00 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[5] = 00 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[6] = 00 ,

10-31 22:03:20.792  1503  1513 D CheckRegion: nv flag:

10-31 22:03:20.792  1503  1513 E CheckRegion: checkRegion: region not match.

위와 같이 일부 눈에 띄는 로그가 있었습니다. 특히 region not match가 눈에 확 들어왔습니다.

해서 0923 QFIL용 롬파일의 super_2.img 파일에서 system 파티션을 추출하여 해당 로그를 발생시키는 파일을 찾아냈고, 그게 libcheckregion.so였습니다.

(이 파일은 5월 글로벌롬에 없고 부팅 logcat에도 해당하는 로그가 발생하지 않았습니다.)

위 라이브러리가 하는 역할을 알아보기 위해 해당 파일을 디컴파일을 해보니 다음과 같은 부분이 보였습니다. (Ghidra 디컴파일러 사용)

이쪽은 ro.boot.target.region property 값에 따라 Region을 확인하는 부분이었습니다.

코드가 보는 값은 unknown(75 6E 6B 6E 6F 77 6E), PRC(50 52 43), ROW(52 4F 57), RESET(52 45 53 45 54) 등이었습니다.

여기서 특히, PRC면 bVar8에 1의 값을, ROW면 2의 값을 넣는 부분에 집중하였습니다.

왜냐하면 5월 글로벌 롬에서 adb를 통해 getprop을 수행해봤더니

[ro.boot.name]: [LenovoTB-J606F_PRC]

[ro.boot.target.region]: [ROW]

위와 같이 PRC와 ROW가 공존하는 걸 봤었기 때문입니다. 검색해보니 PRC가 중국, ROW가 중국 외 국가를 의미하더군요.

그리고 최종적으로 local_2ec와 local_250 값을 비교하여 다르면 region not match를 로그로 출력하는 것을 볼 수 있습니다.

이때 local_2ec에 저장된 값은 PRC일 경우 1, ROW일 경우 2인 상황이었고 local_250값은 vendor.lenovo.hardware.factory@1.0.so에서 가져오는 식이었습니다.

그리고 vendor.lenovo.hardware.factory@1.0.so 라이브러리를 보자마자 딱 생각이 난게 위의

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[0] = 26 ,&

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[1] = ca ,ʍ

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[2] = 1a ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[3] = 01 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[4] = 00 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[5] = 00 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[6] = 00 ,

이 로그였습니다. 아마 QCN을 읽게 해주는 라이브러리일 거라 예상이 되는 부분이었습니다.

확신을 가지기 위해 checkRegion 함수를 system 파티션에서 검색을 해보니 libbootanimation.so가 해당 함수를 실행하는 걸 확인할 수 있었습니다.

보시다시피 service.bootanim.exit가 0이 아니면, 즉 부트애니메이션이 끝나면 Region Check 코드 영역으로 들어오는 것을 볼 수 있었습니다.

checkRegion에 실패하고 Region Error 그림파일을 아직 보여주지 않고 있다면 보여주고 10초(10000000us) 뒤에 reboot을 날리는 걸 볼 수 있네요.

여기까지 살펴본 이후에 처음에는 위 로그의 26 ca 1a 01 값이 어딘가에 저장되어 있을 거라 예상해서 별짓을 다 해봤네요.

QFIL로 모든 파티션을 다 Read해서 확인해보기도 하고, 백업한 QCN을 열심히 털어보기도 했는데 감을 못 잡았었습니다.

그러다가 중국 국가코드로 저장한 QCN과 한국 국가코드로 변경 후 저장한 QCN을 비교해봤는데 여기서

이걸 발견하고 머리를 탁 쳤네요. 바로 CNXX(43 4E 58 58)와 KRXX(4B 52 58 58)이었습니다.

국가코드 변경할 때 의문의 X X설정도 위의 NV item에 저장되는 값이었던 거였습니다. ([ro.boot.countrycode]: [CNXX])

심지어 제가 가린 부분은 태블릿의 시리얼 넘버와 lenovo psn(??)을 포함하고 있었습니다.

이 시점에서 사실 이름 때문에 의심하고 있었던

이 NV item에 대한 확신을 하게 됩니다. 위 국가코드의 경우 FACTORY_DATA, 의심하던 item은 OEM_ITEM이니까요.

그리고 다시 위 로그를 보는 순간 또 깨달은 부분이 있습니다.

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[0] = 26 ,&

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[1] = ca ,ʍ

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[2] = 1a ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[3] = 01 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[4] = 00 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[5] = 00 ,

10-31 22:03:20.791   836   836 I NvProxy-TAG-JNI: android_native_read_FactoryNV tmp[6] = 00 ,

6858 = 0x1ACA 이었기 때문입니다. 0x26은 찾아보니 NV item Read 명령에 해당하는 부분이었습니다.

따라서 위 로그는 '1ACA 번지의 값을 Read(0x26)했더니 값이 1이에요' 라고 알려준 거였죠.

이를 바탕으로 QFIL을 통해 QCN을 백업하고 해당 값을 1에서 2로 수정한 뒤 복원을 하였고 그 결과는 성공이었습니다.

사실 국가코드 변경 메뉴가 별도로 없었다면 저 2497 주소의 국가코드도 아마 직접 수정해줬어야 하지 않았을까 싶네요.

마지막으로 ####6030#이 정말로 해당 NV item을 바꾸는게 맞는지 확인을 하기 위해 system 파티션을 또 뒤져본 결과

(JADX로 열어본 system/app/EngineeringCode/EngineerCode.apk)

위와 같이 setCountryCode가 수행될 때 역시나 레노버 라이브러리를 거치는 걸 확인할 수 있었습니다.

그리고 위의 함수가 writeCountryCode 함수에 의해 불린 후 아래와 같이 강제 공장초기화 명령을 날린다는 걸 통해 확신을 얻었네요.

덤으로 ANDROID 10 박스 버전 P11이 문제 없이 업데이트가 가능하다고 생각되는 상세이유를 보면 다음과 같습니다.

처음에 NV값이 -0x67인지를 보는데 unsigned로는 0x99에 해당합니다. 이게 RESET 값인 것 같네요.

다음으로 0x00이면 역시 마지막 코드로 진행이 되겠네요.

따라서 NV에 0x00값이나 0x99값이 들어있으면 마지막의 로그처럼 값을 현재 롬에 맞춰서 쓰지 않을까 싶습니다.

-> 0520 글로벌롬에서 값을 0x99이나 0x00으로 쓰고 0805 글로벌롬으로 QFIL 돌렸더니 저 값이 0x2로 바뀐 걸 확인했습니다. 가설이 맞았네요!

    0x00도 되긴 하니까 업체들은 NV item 이것저것 밀어보다가 발견한 것 같기도 하네요. 그러다 블투 주소나 시리얼 날려먹는 그런 시나리오가 나오네요.

    11-03 11:47:52.058  1531  1556 D CheckRegion: nv flag: 0x99

    11-03 11:47:53.309  1531  1556 D CheckRegion: nvRegion is empty or reset, set nv to ROW, result: 1

감사합니다!