O meni:

Sem še relativno mlad (v '30 letih) inženir informatike iz Ljubljane. Teme, ki me najbolj zanimajo: dogodki po svetu (novice, politika), zgodovina, znanost (sploh vesolje)

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:CachesTempchrome_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:CachesTempchrome_2283 OR copy it to backup path B:CachesTemp2306chrome_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:WINDOWSTemp
set TMP=D:WINDOWSTemp

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:SettingsivanekLocalDataGoogleChromeApplication” 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:settingsivaneklocaldatagooglechromeapplication” (tam kjer “d:…” pa “d:windowssystem32”), skrajšal pa sem preprosto zato, da niso (že tako dolge) vrstice še daljše.

GetProcAddress(0x7C900000 [d:…NTDLL.DLL], “NtSetInformationProcess”) called from “d:……CHROME.EXE” at address 0x00403DF2 and returned 0x7C90E62D by thread 1.

LoadLibraryExW(“d:…….2.149.29chrome.dll”, 0x00000000, LOAD_LIBRARY_AS_DATAFILE) called from “d:…VERSION.DLL” at address 0x77C013C2 by thread 1.

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

LoadLibraryExW(“d:…….2.149.29chrome.dll”, 0x00000000, LOAD_LIBRARY_AS_DATAFILE) returned 0x00990001 by thread 1.

LoadLibraryExW(“d:…….2.149.29chrome.dll”, 0x00000000, LOAD_LIBRARY_AS_DATAFILE) called from “d:…VERSION.DLL” at address 0x77C016AF by thread 1.

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

LoadLibraryExW(“d:…….2.149.29chrome.dll”, 0x00000000, LOAD_LIBRARY_AS_DATAFILE) returned 0x00990001 by thread 1.

LoadLibraryExW(“chrome.dll”, 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from “d:……CHROME.EXE” at address 0x00402734 by thread 1.

Loaded “d:…….2.149.29CHROME.DLL” at address 0x01000000 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_USERSoftwareGoogleUpdateClients{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 Comment on “Kako mi je uspel Google Chrome updejt”

  1. tadej pravi:

    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:WINDOWSTemp” oz.
    “7za.exe x patch.7z -oD:WINDOWSTempTmp” ukazoma) iz “B:CachesTempchrome_28003sourceChrome-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


Komentiraj