도파민 탈옥 개발자가 파악하기 어려운 Spinlock Timeout Panic 문제에 대해 논의합니다.

문제를 제거하기 위해 도구를 사용해보십시오





그만큼 도파민 iOS 및 iPadOS 15.0-15.4.1을 실행하는 A12-A15 장치용 탈옥 도구는 현재 iPhone X보다 최신 장치에서 사용할 수 있는 최신 단일 탈옥 도구입니다. 그렇다면 이것이 대중적인 선택이라는 것은 놀라운 일이 아닙니다. 탈옥자 오늘.



  Lars Fröder는 도파민 탈옥의 Spinlock Timeout Panics에 대해 GitHub 페이지에 트윗했습니다.

그러나 Dopamine을 사용했거나 프로젝트가 시작된 이후로 프로젝트를 따라왔다면 프로젝트 수석 개발자 Lars Fröder가 던진 특정 단어를 꽤 많이 들어보셨을 것입니다. @opa334dev ) 및 사용자 모두: Spinlock.

실제로 Spinlock Timeout Panic이라고 하는 Dopamine 탈옥에 영향을 미치는 알려진 문제가 있으며, 이로 인해 결국 사용자의 장치에 분홍색 화면이 표시되고 겉으로는 도발되지 않은 방식으로 재부팅됩니다. 이 문제는 기술적인 용어로 다음과 같이 설명되었습니다.



dyld_shared_cache 실행 가능 페이지 위에 매핑하면 PPL에서 가끔 메모리 페이지의 스핀 잠금에 대한 시간 초과가 발생하여 커널 패닉이 발생하는 극단적인 경우 동작이 발생하는 것으로 보입니다.

후크 C 기능이 더 많이 설치되고 더 많은 프로세스가 주입될수록 이 동작이 더 자주 발생하는 것 같습니다.

이 문제는 연결된 모든 페이지를 연결하여 해결할 수 있는 것으로 보이지만 사용자 공간은 이러한 잠금을 사용할 수 없으며 연결된 비트를 직접 뒤집기 위해 커널 메모리에서 vm_page 개체를 찾는 것이 어려운 것으로 입증되었습니다.



나는 Dopamine 장치에서 이러한 문제 중 하나를 개인적으로 경험한 적이 없기 때문에 이것이 어떻게 나타나는지, 언제 발생하는지 설명하기가 어려웠습니다. 그들은 그것을 해결하려고 노력하고 있습니다.

Fröder의 반응은 나와 같은 기술 지식이 없는 사람들과 아마도 탈옥 커뮤니티의 많은 다른 사람들에게 통찰력이 있었고 그 이후로 GitHub 문제 페이지에 게시됨 대중이 볼 수 있도록. 아래에 인용된 전체 응답은 Spinlock Timeout Panic 문제에 대한 Fröder의 이해를 보여줍니다.

다음은 문제에 대한 현재 최선의 이해를 바탕으로 문제에 대한 보다 심층적인 설명을 시도한 것입니다. 기본적으로 검증이 불가능한 가정을 기반으로 한다는 점을 명심하세요.



따라서 다중 스레드 시스템에서는 두 스레드가 서로 간섭하는 것을 방지하기 위해 '잠금'이 사용됩니다. 이를 통해 하나의 스레드가 잠금을 획득하고 수정하고 잠금을 해제할 수 있습니다. 잠겨 있는 동안 잠금을 획득하려는 다른 스레드는 개체가 다시 잠금 해제될 때까지 기다립니다.

스핀록은 본질적으로 동일하며 성능 관련 작업에 사용되며 주요 차이점은 다른 스레드가 잠금을 획득하려고 시도하는 동안 잠금이 너무 오래 걸리면 스핀록이 시간 초과될 수 있다는 것입니다. 따라서 잠금을 획득하고 개체가 이미 잠겨 있으면 몇 틱 동안 대기하고 해당 시간 내에 개체가 잠금 해제되지 않으면 시간 초과됩니다.



이 메커니즘 자체는 문제가 되지 않습니다. 문제는 다음과 관련이 있습니다. 메모리 페이지. 모든 메모리 페이지(RAM의 16kB 영역을 설명)에는 스핀록이 있으므로 여러 프로세스가 동시에 동일한 페이지를 얻으려고 할 때 문제가 없습니다.

특정 페이지는 여러 프로세스에 매핑될 수 있으며(예: 둘 다 동일한 라이브러리를 로드하는 경우) 메모리를 절약하기 위해 동일한 페이지를 재사용합니다. 조정은 프로세스별로 이러한 메모리를 덮어쓰려고 하므로 먼저 기존 매핑의 프로세스별 복사본을 만들고 그 위에 매핑해야 합니다. 한 페이지는 한 프로세스에서 수정되고 다른 프로세스에는 재고가 남아 있을 수 있습니다. 이 문제는 dyld_shared_cache 내부에 있는 페이지 위에 매핑할 때 특히 발생하는 것 같습니다.



문제는 이제 Apple이 이런 종류의 후킹을 테스트한 적이 없으며 분명히 많은 프로세스에서 이를 수행할 때 원본 페이지(공유 매핑 중 하나)가 적극적으로 사용되지 않기 때문에 페이지 아웃될 수 있다는 것입니다. . 페이지를 페이지 아웃하면 기본적으로 RAM에서 해당 페이지가 제거되며 다시 액세스하면 다시 로드됩니다. 스톡 시스템에서는 연결된 것이 없기 때문에 이런 일이 발생하지 않습니다.

이제 근본 원인은 이전에 페이지 아웃된 공유/실행 가능 페이지를 다시 페이지로 넣으려고 시도하는 것 같습니다. 이로 인해 한 스레드가 스핀록을 가져오고 스핀록이 있는 동안 다른 컨텍스트로 선점되는 선점 문제가 발생합니다. 동일한 스핀록(선점은 본질적으로 하나의 스레드가 현재 사용 중인 경우에도 다른 스레드에 사용될 수 있도록 허용하는 메커니즘입니다. 항상 한 번에 실행되어야 하는 코드 조각이 있는 경우 코드는 이를 명시적으로 비활성화했다가 다시 활성화해야 합니다) . 따라서 Apple이 선점을 올바르게 비활성화하지 않는 이 특정 동작에서만 호출되는 하나의 코드 경로가 있는 것 같습니다. 이로 인해 하나의 스레드가 동일한 스핀록을 두 번 사용하게 되어 이전 컨텍스트가 더 이상 실행되지 않고 시간 초과가 발생합니다. 스핀락을 다시 잠금 해제할 수 없습니다.



이를 완화하기 위해 Spinlock 관련 변수를 조작하여 시간 초과에 필요한 임계값을 높이려고 시도했지만 불행히도 Apple은 그와 관련된 모든 것이 KTRR로 보호되어 우회가 없기 때문에 우리를 망쳤습니다. 적절한 수정은 페이지 아웃이 발생하지 않도록 덮어쓰기 전에 연결될 모든 페이지를 '연결'(페이지를 연결하면 페이지 아웃되는 것을 방지)하는 것입니다. 따라서 코드 경로는 다음과 같습니다. 문제가 발생하지 않습니다. 지금까지 여러 가지를 시도했지만 사용자 공간에서 이러한 배선을 얻는 것이 사실상 불가능한 것 같으므로 커널 내부에서 수행해야 합니다. 불행히도 문제를 일으키는 이 특정 공유 매핑과 관련된 구조는 매우 복잡하며 연결을 적용할 올바른 페이지 개체를 얻는 방법을 아직 찾지 못했습니다.

Spinlock Timeout Panic 문제는 Dopamine이 처음 사용 가능해졌을 때부터 발생했으며 오늘날까지 계속해서 발생하고 있습니다. 많은 시도에도 불구하고 문제를 해결하려면. 하지만 더 많은 사람들이 보고 기여할 수 있도록 대화를 여는 것이 올바른 진전입니다. 더 많은 사람들이 문제와 가능한 해결책을 브레인스토밍하는 것이 더 쉬워지기 때문입니다.

Fröder는 후속 의견에서 문제를 방지하기 위한 다음 아이디어를 설명합니다.

따라서 이 문제를 해결하기 위한 다음 단계는 커널 메모리에서 DSC 페이지의 vm_page 구조를 찾는 것입니다. 지금까지 그러한 구조를 찾으려는 모든 시도는 실패했습니다.

아직 나에게 직접적인 영향을 미치지는 않았지만 Fröder가 Spinlock Timeout Panic 문제를 해결할 수 있는지 보는 것은 정말 흥미로울 것입니다. C 기능을 연결하는 탈옥 조정을 더 많이 설치하는 사용자에게 더 널리 퍼진 것 같습니다. 내 테스트 장치에 문제를 유발하는 조정 기능이 많이 설치되어 있지 않을 수도 있지만, 수많은 탈옥 장치를 설치하는 사람들이 많다는 것을 알고 있습니다. 탈옥 조정 – 나보다 더.

다음도 참조하세요. Dopamine을 사용하여 iOS 및 iPadOS 15.0-15.4.1을 실행하는 A12-A15 장치를 탈옥하는 방법

Dopamine 탈옥을 사용하는 동안 갑자기 재부팅하기 전에 분홍색 화면으로 설명되는 Spinlock Timeout Panic의 영향을 받은 적이 있습니까? 아래 댓글 섹션을 통해 알려주세요.

Top