Hallo Leute, leider habe ich, wie so viele, ein Problem damit das Microsoft bei Ihren Mixed Reality Headsets einen restriktiven Kurs fährt und die "Ultra" Einstellung bei Prozessoren unter 4 Cores nicht erlaubt. Ich habe ein Notebook mit einem i7-7600U Prozessor welcher 4 Logical Cores und 2 Physical Cores besitzt. Kennt sich hier jemand mit reverse engineering aus? Folgendes habe ich bis jetzt: Beim ersten Start der Mixed-Reality-Software ist die MixedRealityPortal.Brokered.dll für die Ermittlung der Cores zuständig. Diese schreibt in folgendes Verzeichnis eine xml Datei mit den ermittelten Daten: C:\Users\XXXAppData\Local\Packages\Microsoft.Windows.HolographicFirstRun_cw5n1h2txyewy_bak\LocalState\DiagOutputDir\ MrrEvaluation.xml Dies geschieht aber nur bei einem Erststart der Software, also einer Erst-installation. Wenn man Evaluirungs-Screen einmal mit dem "weiter" Button beendet wird diese Datei nicht mehr aktualisiert. Jetzt zum Code. Ich benutze x64dbg und Ida7 free. Leider war es für mich nicht möglich die MixedRealityPortal.exe mit meinem debugger x64dbg zu debuggen. Also habe ich mir den Mixed-Reality-Checker runtergeladen und dort Veränderungen im Code durchgeführt. Vieles bei der Ermittlung der Cores ist hier identisch. Es gibt in dem Checker sogar einen Bereich in dem die Ultra Abfrage stattfindet. Dies ist bei Adresse 75D2 im Hex oder wenn jemand IDA nutzt im sub_180007FB0. ABER! Genau diese Abfrage gibt es nicht in dem MixedRealityPortal, diese gibt es nur bei dem Mixed-Reality-Checker. Es gibt eine Abfrage über die CPUID nach der Bezeichnung des Prozessors. Ich denke dass auch hier die Kerne ausgelesen werden. Habe dies aber noch nicht gefunden. In der MixedRealityPortal.Brokered.dll wird in dem sub_18002DA20 die Kerne abgefragt. Das ist hier der Code: loc_18002DB5D: mov rax, [rbx] mov rcx, rbx mov rax, [rax] call csff_18006DAC0 mov eax, eax mov [rsp+540h+var_4D8], rax <-- Logical Cores [rsp+540h+var_4D8] mov rax, [rbx] mov rcx, rbx mov rax, [rax+8] call csff_18006DAC0 mov eax, eax mov [rsp+540h+var_4D0], rax <-- Physical Cores in Adresse [rsp+540h+var_4D0] xor ebx, ebx Vor jedem CALL steht hier ein mov rax,[xxx] Das bedeutet das in dem CALL später auf eine bestimmte Adresse "gejumpt" wird um dann entweder die LogicalCores oder die Physical Cores abzufragen. Dies geschieht dann unter folgenden subs: Logical Cores: sub_180048E78 proc near push rbx sub rsp, 20h mov rax, [rcx-78h] mov rbx, rcx add rcx, 0FFFFFFFFFFFFFF88h movsxd rdx, dword ptr [rax+8] add rcx, rdx call sub_18005DFD8 mov rax, [rbx-68h] sub rax, [rbx-70h] sar rax, 4 add rsp, 20h pop rbx retn sub_180048E78 endp PhysicalCores: sub_180048EA8 proc near push rbx sub rsp, 20h mov rax, [rcx-78h] mov rbx, rcx add rcx, 0FFFFFFFFFFFFFF88h movsxd rdx, dword ptr [rax+8] add rcx, rdx call sub_18005DFD8 mov eax, [rbx-48h] add rsp, 20h pop rbx retn sub_180048EA8 endp Wenn man nun folgendes Patched bekommt man für die PhysicalCores den gleichen Wert wie für die LogicalCores: loc_18002DB5D: mov rax, [rbx] mov rcx, rbx mov rax, [rax] call csff_18006DAC0 mov eax, eax mov [rsp+540h+var_4D8], rax <-- Logical Cores mov rax, [rbx] mov rcx, rbx mov rax, [rax+8] <-- patchen zu mov rax, [rax] call csff_18006DAC0 mov eax, eax mov [rsp+540h+var_4D0], rax <-- Physical Cores xor ebx, ebx Dadurch wird bei beiden CALLS zur gleichen Adresse gesprungen und dadurch die Abfrage gleich gestellt. Nach diesem Patch ist in der Datei MrrEvaluation.xml nun auch folgendes: <Attribute Name="LogicalCores" Status="Ok" ActualValue="4" TargetValue="4" /> <Attribute Name="PhysicalCores" Status="Ok" ActualValue="4" TargetValue="2" /> Leider bin ich hier am Ende meines Lateins. Obwohl nun das Programm denkt das mein Notebook 4 Physical Cores hat ist es nicht möglich die "Ultra" Einstellung freizuschalten. Ich schließe daraus dass es noch einen weiteren Check gibt, oder die Core Anzahl noch irgendwo anders gespeichert werden. Ich habe natürlich noch mehr gefunden. Das sprengt aber den Rahmen hier. Ich hoffe das sich hier jemand meiner Arbeit anschließen kann. -e
Deinen Ehrgeiz in Ehren, aber hast du mal dran gedacht dass es einen Grund gibt warum Ultra nicht auf 2 Kernen freigegeben ist? Ich denke falls du es am Ende doch hinbekommst wirst du dir denken: Mensch soviel Mühe und das läuft einfach nicht gescheit. Sei mal ehrlich... DualCores sind schon ziemlich antiquiert.
Bist Du sicher das die Datei MixedRealityPortal.Brokered.dll eine mit nativem Code erzeugte DLL ist? der Name klingt für mich eher nach .NET
Das hätte ich auch vermutet. Probier mal it Jetbrains DotPeek zu dekompilieren. Er löst zwar Lambda Expressions nicht korrekt auf aber trotzdem sieht man da mal was, falls es eine .NET Assembly ist und nicht obfuskiert wurde.
Danke sehr. Leider keine Net file Sonst wäre ich vielleicht etwas weiter. Ich denke das mein i7 Dual Core mit meiner gtx1060 zumindest für den Anfang ausreichen könnten. Dieser Patch sollte sich eher an die Notebook Anwender richten. Dort sind meist nur 2 Core Prozessoren verbaut. Habe zuhause natürlich noch ein 4 Core Desktop-PC und dort läuft alles sehr gut. Ich vermisse nur die 90FPS. Das ist wirklich ein riesen Unterschied. Zuhause benutze ich die Brille an meinem Desktop-PC, doch auf meinem Notebook ist die FPS Begrenzung wirklich eine Zumutung. mfg -e
Vielleicht gibt es ja Tools die deine Hardware Specs faken/maskieren. Trotzdem glaube ich nicht dass du mit dem Ergebnis zufrieden sein wirst.
WindowsForms wäre ja .NET, also wahrscheinlich nicht. Es ist sicher ein UWP-Programm, weil das gnaze ja auch nur auf Windows 10 läuft. Es ist auch sehr unwahrscheinlich dass Microsoft bei einer neuen Plattform (sowohl Hard- als auch Software) ein Tool schreibt was mit einer bereits in der 2. Generation veralteten GUI-Technik arbeitet.
Ich mein ob es ein Fenster mit Windows-Steuerelementen ist oder etwas im HMD Bei einem Normalen Window-Fenster könntest du mit peziellen Programmen mal versuchen das Control ausfindig zu machen, einfach enablen und schauen ob es damit funktioniert
