Kako mi je uspel Google Chrome updejt

Za danes pa ena res hudo hard-core objava o tem, kako sem s pomočjo programa Dependency Walker najdel način, kako v moji specifični situaciji (za več o tem glej spodaj) updejtati svojo inštalacijo spletnega brskalnika Google Chrome (o katerem sem prvič pisal v tej objavi) iz stare različice 0.2.149.29 v novo različico 0.2.149.30.

Namreč, gre za to, da imam jaz zelo posebno/specifično skonfiguriran operacijski sistem, konkretno, svoj “Temp” direktorij (to se naštima s TMP in TEMP “User variables” v Advanced tabu pod “System” v Control Panel) imam lociran na RAM-drajvu/disku, ki pa ima samo 64 MB prostora (glej tudi tole objavo za detajle), tako da ko je Chrome updejt proces probal “ekstraktati” vsebino “patch.7z” oz. “chrome.7z” fajlov zdownloadanih v “B:\Caches\Temp\chrome_2283\” direktorij (notri pa je bil tudi “source” direktorij s pod-direktorijema “Chrome-bin” in “0.2.149.30″, ta zadnji pa še “Locales”, “Resources”, “Themes” in “Dictionaries” pod-direktorije, seveda, pri čemer so imeli nekateri od njih noter tudi sami fajle, npr. updejtano “chrome.dll” itd.), mu to enostavno ni uspelo in sem v fajlu “chrome_installer.log” dobil tole error-sporočilo spodaj.

[0920/173541:ERROR:main.cc(167)] error during uncompression: 112
[0920/173541:ERROR:delete_tree_work_item.cc(68)] can not delete B:\Caches\Temp\chrome_2283 OR copy it to backup path B:\Caches\Temp\2306\chrome_2283

Torej, ponavadi sem se temu problemu izognil tako (konkretno npr. v primeru Prevx programa), da sem inštalacijski fajl zagnal preko “cmd.exe” programa (ali t.i. “command prompt” oz. “DOS okno”), v katerem sem pred tem začasno spremenil TMP/TEMP “Environment variables” takole.

set TEMP=D:\WINDOWS\Temp\
set TMP=D:\WINDOWS\Temp\

Ampak ker nad updejt procesom od Google Chrome-a nimam direktnega “nadzora”, to v tem primeru ni prišlo v poštev. Tako je bilo edino, kar sem lahko naredil to, da sem z CLI varianto programa 7-Zip “ekstraktal” vsebino “chrome.7z” fajla nekam na trdi disk in s temi novimi/updejtanimi fajli prepisal ta stare v “D:\Settings\ivanek\Local\Data\Google\Chrome\Application\” direktoriju.

Problem pa je nastal potem, ko sem poskusil program prvič (po tem mojem “posebnem” updejtu) zagnati, pa je bil proces takoj v trenutku terminiran. Zato sem, priznam, bolj kot ne iz čiste radovednosti (in ne da bi mislil, da mi bo to pomagalo najti rešitev) program “vrgel” v zgoraj omenjeni Dependency Walker program in ga “sprofiliral”. In ne boste verjeli, tako sem odkril, da “LoadLibraryExW” funkcija v “version.dll” dll-ju kliče “chrome.dll” dll pod starim “.2.149.29\” (in ne novim “.2.149.30\“) direktorijem. Tule spodaj imate del log-a, aja pa še to, tam, kjer vidite “d:\…\…\” zgoraj je bilo v originalu “d:\settings\ivanek\local\data\google\chrome\application\” (tam kjer “d:\…\” pa “d:\windows\system32\”), skrajšal pa sem preprosto zato, da niso (že tako dolge) vrstice še daljše.

GetProcAddress(0×7C900000 [d:\...\NTDLL.DLL], “NtSetInformationProcess”) called from “d:\…\…\CHROME.EXE” at address 0×00403DF2 and returned 0×7C90E62D by thread 1.

LoadLibraryExW(”d:\…\….2.149.29\chrome.dll”, 0×00000000, LOAD_LIBRARY_AS_DATAFILE) called from “d:\…\VERSION.DLL” at address 0×77C013C2 by thread 1.

Mapped “d:\…\….2.149.29\CHROME.DLL” as a data file into memory at address 0×00990001 by thread 1.

LoadLibraryExW(”d:\…\….2.149.29\chrome.dll”, 0×00000000, LOAD_LIBRARY_AS_DATAFILE) returned 0×00990001 by thread 1.

LoadLibraryExW(”d:\…\….2.149.29\chrome.dll”, 0×00000000, LOAD_LIBRARY_AS_DATAFILE) called from “d:\…\VERSION.DLL” at address 0×77C016AF by thread 1.

Mapped “d:\…\….2.149.29\CHROME.DLL” as a data file into memory at address 0×00990001 by thread 1.

LoadLibraryExW(”d:\…\….2.149.29\chrome.dll”, 0×00000000, LOAD_LIBRARY_AS_DATAFILE) returned 0×00990001 by thread 1.

LoadLibraryExW(”chrome.dll”, 0×00000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from “d:\…\…\CHROME.EXE” at address 0×00402734 by thread 1.

Loaded “d:\…\….2.149.29\CHROME.DLL” at address 0×01000000 by thread 1. Successfully hooked module.

In tako sem pomislil, če ta “string” ni “hard-codan” nekje v samem .exe fajlu, potem je možno, da se odgovor skriva v Windows registry-ju. In res, pod “HKEY_CURRENT_USER\Software\Google\Update\Clients\{8A69D345-D564-463c-AFF1-A69D9E530F96}” sem našel en entry z Value name: “pv” in Value data: “0.2.149.29″ in ko sem spremenil slednjemu vrednost v “0.2.149.30″ sem lahko normalno zagnal Google Chrome program.

P.S. – Če vas morda zanima, podobne hard-core računalniške objave na tem blogu so bile še tale objava (in še link do drugega dela), v katerih sem pisal o t.i. “trimanju” .exe fajlov in o razliki med navadnimi linki in t.i. “junction point-i” (oboje seveda v MS operacijskih sistemih), pa tudi tale objava o hekanju TCPIP drajverja bi spadala zraven.

Tadej

One Response to “Kako mi je uspel Google Chrome updejt”

  1. tadej says:

    Jah, tokrat pa mi je vso stvar (updejt iz verzije 0.4.154.29 v 1.0.154.36) še veliko bolj elegantno izpeljati (glej tudi tale twit), namreč tokrat mi ni bilo treba kopirati novih fajlov (prej “ekstraktanih” s “7za.exe e chrome.7z -oD:\WINDOWS\Temp\” oz.
    “7za.exe x patch.7z -oD:\WINDOWS\Temp\Tmp\” ukazoma) iz “B:\Caches\Temp\chrome_28003\source\Chrome-bin\” direktorija na mojem RAM-drajvu/disku (s samo 64 MB kapacitete) na lokacijo Google Chrome inštalacije.

    Ne, tokrat mi je dejansko uspelo, da sem preko “cmd.exe” (ali t.i. “DOS okna”) najprej začasno spremenil TMP/TEMP “Environment variables” (kako se to naredi, glej zgoraj v objavi), nato pa zagnal “chrome_updater.exe”; tokrat je očitno med procesom updejtanja zagnani “setup.exe” obdržal TMP/TEMP nastavitve in tako je bil updejt kot rečeno v celoti izpeljan brez zapletov!!

    Tadej

Leave a Reply