Egyéb újdonságok:
- A beállítási panelen eddig a gyorsítótár által foglalt helyet nem frissítette, ha nyitva volt a panel (kivéve, ha ürítettük). Mostantól egy timer frissíti 5 másodpercenként.
Bugfixek:
- Kiderült, hogy az audio-only streamekre nem vonatkozik a throttle, csak a video-only és audio/video-ra, szóval innentől a throttle alapjáni autoselect a kombinált formátumoknál (x+y, külön audio, külön videostream) nem veszi figyelembe az audio bitrátát. Ugyanezen okból kifolyólag az audio/video stream-eket en-bloc kihagyja a keresésből.
Bugfixek:
- Az 1.8.0-ában, vagy az 1.9.0-ában bekerült egy bug, minek köszönhetően a konkrét letöltéskor is az utoljára jobbklikkelt tab streamjeinek URL-je lett kiválasztva, nem csak jobbklikk/copy download command esetén.
Letöltések:
- FreeBSD AMD64
- Linux AMD64
- Linux i686
- OpenBSD AMD64
- Solaris AMD64
- Manual
- Online manual
(Az SHA1 ellenőrzőösszegeket a letöltőoldalon kiírja a rendszer.)
Még egyszer köszönet s_balazs-nak, aki felhívta a figyelmemet arra, hogy a Kodi ki tudta kerülni a dolgot, valamint köszönet bra-ket-nek és ttasi-nak a beágyazható JS engine-ok tippjeiért; ha a kugli tovább keményít, még lehet, hogy kénytelen leszek a cipherek miatt beágyazni egy lightweight JS interpretert. (Az a párszáz kB nem akkora katasztrófa, futni meg csak akkor fog, amikor kinyitunk egy lapot és decipherelni kell a különféle signature-öket, azt a párszáz ms delay-t meg ki lehet bírni egyszer per betöltött lap...)
Ugyanitt Mac Mini 2009-es kerestetik, hogy buildelhessek OSX verizót is. (Mindegy, hogy early, vagy late, csak legyen benne 2 GB RAM, hogy fusson rajta a 10.11.)
* UPDATE: A kugli megörvendeztetett az egyik decipher funkciójának egy olyan variánsával, ami eltért a többi zagyválási mechanizmusától. Lekezelve. Letöltés a linkeken.
* UPDATE #2: A kugli ismét megörvendeztetett ugyanannak a decipher funkciójának a kettébontásával, hogy ugyanazt két lépésből csinálja. Lekezelve. Letöltés a linkeken.
* UPDATE #3: A kugli ismét megörvendeztetett egy új variánssal, mondjuk ennek elvileg működnie kellett volna, csak a lekezelésben a múltkor egy dolog nem lett átírva. Javítva. Letöltés a linkeken.
* UPDATE #4: A kugli kezdi túlzásba vinni a taknyolást... Eddig az átadott szekunder paraméterek mindig vagy integerek voltak, ha valamelyik normál függvénynek küldte, vagy stringek, ha valamelyik wtf-nek. Most azonban egy funkció volt átadva. Igaz, hogy egy olyan függvénynek, ami egy wrapper volt a push-ra, dehát ugye itt ez nem derül ki, hiszen, hogy melyik függvény van meghívva, az obfuszkálva van. Lekezelve.
* UPDATE #5: Egyre durvább gányolásokat zúznak bele ebbe a trutymó-cipherbe. Csak a fejem fogtam, már felsorolni se nagyon tudom... Pl. wtf-be mehet maga a bemeneti eredeti cipherstring, mint salt. Lekezeltem mindent, egy bugot is javítottam, ami valamelyik előző ilyen lekezeléskor keletkezett.
* UPDATE #6: Most meg ad-hoc módon elkezdték az eddig simán leírt integereket normálalakban felírni... Ez is lekezelve.
- TCH blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
A forras kinn van valahol? Egyszeruen kivancsiva tettel, hogy mi lett a megfejtese annak az obfuszkalt mocsoknak. :)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Nem, nem publikus a forrás.
De egyébként kb. arról van szó, hogy a decipheringet tkp. úgy oldották meg, hogy a számokat, szövegeket és a deciphering funkciókat begyúrták egy tömbbe. Öt adattípus lehetséges:
- integer
- string
- deciphering funkció (ld. lejjebb)
- referencia a szignatúrára
- referencia saját magára (ezt
null-lal jelölik és utólag töltik fel)
Amennyiben funkció az adott elem, akkor abból hatféle van (amit persze többféleképpen oldanak meg, de a végeredmény az egyes variánsok közt nem tér el), amit a szignatúrán és a deciphering tömbön csinálhat:
- egy adott töréspont mentén a lista két felének megcserélése
- a lista nulladik elemének cserélése egy adott sorszámú elemével
- a lista összes elemének fordított sorrendezése
- egy adott elem beszúrása a lista végére (stringgé konvertált integer, ha a szignatúrával csinálja és string, integer, vagy funkció, ha a tömbön)
- egy tetszőleges elem eltávolítása a listából
- egy "kutyuló" művelet (amit én csak
"wtf"-nek hívok, a kódban is így hivatkozok rá), ami csak a szignatúrán dolgozik és először egy jól megkavart - és változó lépésekből felépített - ciklussal összerak egy karaktertömböt, majd abból és egy bemeneti paraméterben kapott másik stringből másolgatva/keresgetve cserél le karaktereket a szignatúrában.
A tényleges végrehajtás úgy történik, hogy fogja a tömböt és annak egyes elemeire hivatkozva hajtja végre az egyes műveleteket. (c[x](c[y], c[z])) A hívás hivatkozása (x) csak olyan elemre mutathat, amiben deciphering funkció van. Az első paraméter hivatkozása (y) az csak olyan elemre mutathat, ami vagy a szignatúrának (b), vagy a tömbnek (c) a referenciáját tartalmazza. A második paraméter hivatkozása (z) az mutathat integerre, stringre, vagy funkcióra, de ez utóbbira csak akkor, ha az első paraméter a tömböt jelölte, pl. amikor beszúrják valamelyik funkciót a deciphering tömbnek a végére még egyszer.
Egyébként nehogy azt hidd, hogy valami hiperelegáns módon oldottam meg; kb. bizonyos szintig emulálom a jávaszkript működését, pl. a deciphering tömböt egy record (C-s struct Pascalos megfelelője) tömbbel, ami tárolja, hogy az adott elem a fenti öt típus közül melyik és ha funkció, akkor a fenti hat közül melyiket jelenti, valamint, ha "wtf", akkor - mivel annak változik a belseje (hogy rohadna meg a kugli) - hogy milyen parancsok vannak abban a bizonyos switch-ben; amiken a tényleges végrehajtáskor kétszer megy végig, egyszer megkeresi, hogy melyik elemnél kell "elsülnie" és honnan folytatnia (ha van case ami teljesül, akkor onnan, különben a default-tól, ha volt olyan), másodjára pedig a megtalált elemtől kezdve végrehajtja az összes parancsot, ami szembejön - kivéve a case és default elemeket.
Szóval Pascal kóddal sem lenne sokkal érthetőbb az algoritmus. :P Egyébként nekem olybá tűnik, hogy ez ilyen "trutymó-cipher", azaz nincs konkrét matematikai modell mögötte, hanem ami eszükbe jutott azt megcsinálják a szignatúrával és azt kell visszafelé megcsinálni a deciphering alatt. Szóval auto-obfuszkált minden kód, ami ezt leírja. :P
- A hozzászóláshoz be kell jelentkezni
Koszi!
Par fuggvenyt - csak ugy hulyesegbol - megfejtettem en is, es megprobaltam osszerakni, hogy ezekbol az elemi muveletekbol kb mi johet ki. Azt hittem van valami "megfejtese". En elsore arra gondoltam, hogy ez valami in-house obfuscator tooljuk kimenete, ami fog egy normal js fuggvenyt es leforditja ilyen erthetetlen formatumra. Ezzel mondjuk valamelyest osszecseng, ha a "wtf" fuggveny belseje valtozik, es lenyegeben interpretert kell irnod hozza.
Kicsit furcsa az egesz megkozelites nekem, mert latszik, hogy beletettek munkat, de ugyanakkor megcsinalhattak volna ennel sokkal biztosabbra is. Pl olyan js-t kuldenek le, ami ellenorzi a webui intergritasat, random dom elemekre rakott random id-kat egyfajta challenge-response-ban visszakerdez a szerver es csak ezutan ad egy egyszerhasznalatos (vagy legalabbis rovid ideig elo) tokent - ezzel tkp az adblock-ot is ki tudnak nyirni. Nem akarok otleteket adni nekik...
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Nincs mit.
Az lehet, hogy ez valami obfuszkált kód, de maga az algoritmus is obfuszkálja a kódot. Mondom, szerintem ez valami trutymó-cipher, amiből valószínűleg van nekik több és azok jönnek le így obfuszkálva. Vagy csak egy van, de az úgy van megírva, hogy cserélgetni lehet a lépéseket.
A kugli egy pénzéhes cég, nem fognak több munkát belefeccölni a minimumnál. Látod most még ezzel is sokra mentek, mert a youtube-dl még mindig nem tudta megoldani a helyzetet, pedig már hónapok óta fennáll, a ytl-dlp pedig lenyelte a békát és behúzott egy JS interpretert. A Kodinak sikerült, nekem is, de lehet, hogy legközelebb már nekünk is be kell húznunk egy JS interpretert.
Azzal a webui-integritás-ellenőrzéssel nem mennének semmire, mert nekünk csak a függvény kimenete kellene, azt pedig, ha látjuk (és látjuk, lévén kliensoldalon van), hogy miket ellenőriz és milyen lépéseket tesz, akkor le tudjuk utánozni azt is, hogy úgy dolgozzon, mintha minden ellenőrzés sikeres lett volna.
Mindaddig, amíg a kliensoldalnak kell csinálnia valamit, addig a védelem törhető lesz, mert amit egy browser meg tud csinálni, azt egy másik program is meg tudja, ha tudjuk, hogy a browser mit csinál. Még az se lenne tökéletes védelem, ha olyan JS parancsokat használnának, amiket csak a zárt forrású Chrome ismer, a nyílt forrású Chromium nem (pl. doYouTubeProtection("wH@T3V3Rh@$HuC@N!M@6!N3");), mert a hálózati forgalmat itt is lehet rögzíteni és ha azt látjuk, hogy a JSON-ban lejövő URL-eket úgy küldi vissza, hogy ezt és azt lecserélt benne, akkor már tudjuk, hogy mit kell cserélni, aztán ha egyszerű a cipher, akkor akár arra is rá lehet jönni, hogy mi alapján mire, ha meg nem, még mindig ott van lehetőségnek a disassembly: meg kell keresni, hogy a doYouTubeProtection stringre hol hivatkozik a program és azok a részek mit csinálnak, úgy már meg lehet keresni azt a részt, ami a decipheringet csinálja, aztán vissza lehet fejteni, vagy ha az nem megy, le lehet másolni az assembly kód viselkedését is, maximum lassú lesz.
A kliensoldali védelem, nem védelem.
- A hozzászóláshoz be kell jelentkezni
Ezt a search funkciót nem tudnád megcsinálni, hogy feltöltési időrendben mutassa a találatokat?
Ha pl rákeresek Muszashi kolléga csatornájára akkor össze-vissza vannak a találatok. Tipp: szerintem nem lenne nagy dolog egy csatornák mentése opció (kedvencek), amolyan subscribe és a program indulásakor a csatornák tartalmának frissítése. Rákattintok a kedvencek fülre és egyből látom, ha valaki új tartalmat töltött fel.
Minden hulla a Mount Everesten valamikor egy nagyon motivált ember volt.
- A hozzászóláshoz be kell jelentkezni
A keresőfunkciót még meg tudom, mert ahhoz ad a tecső backend parancsot, hogy feltöltés alapján rendezzen, de a csatornák tartalmánál, meg a videóknál a related listában nincs ilyen lehetőség, ott nem tudok rendezni.
Egyfelől azért, mert a tecső ugyanis nem dátumot ad vissza, hanem azt, hogy mennyi ideje töltötték fel és azt is úgy, hogy "X [időegységgel] ezelőtt" és azt is valami alapon nyelvesítve, szóval nem én írom ki magyarul (egy angol nyelven beszélő programban), hogy "X évvel ezelőtt", a tecső adja vissza azt. Ahhoz, hogy ezt sorrendezni tudjam, ahhoz a programnak a világ összes nyelvén ismernie kéne az év/hónap/nap/óra/perc/másodperc szavakat és abból kibányásznia valahogy.
Másfelől meg azért, mert még ha rendeznénk is valahogyan a találatokat, azt csak egy "oldalra" tudnánk csinálni és semmi garancia nincs rá, hogy az első "oldalon" azok lesznek, amiknek időrendben ott kéne lenniük; azt meg nem játszhatom el, hogy betöltés alatt addig kérem a "további tartalmak betöltését", amíg el nem fogy, mert ha ötvenezer további "oldal" van, akkor sose érne véget a betöltés (amit lapozóként látsz a programban az csak "emuláció", én emulálom a lapokat úgy, hogy az előrefele lapozásnál kéri a további tartalmakat, a visszafelénél meg előhúzza az előző oldalt a cache-ből, lévén a tecső pár éve megszüntette a találatok lapozását).
Ennek megfelelően ha csinálnék is valami csatornafigyelőt, azt nem tudom kiberhelni belőle, hogy van-e friss tartalom, mert a kugli rendezi a csatornáknál a találatokat teljesen kaotikusan és nem ad egzakt időadatot. Sorry. A könyvjelzők közé csatornát is fel lehet venni, többet sajnos nem tudok tenni. Ha a keresési találatok sorrendezésére igény van, azt meg tudom csinálni; a tecső relevancia, feltöltési idő, nézettség és értékelés alapján tud rendezni, de csak csökkenő módon.
- A hozzászóláshoz be kell jelentkezni
Tegnapról mára a kugli megörvendeztetett egy új "wtf" variánssal, amiben nincs default ág, hanem a kis szarhadék kipakolta a karaktertömb feltöltését a switch blokkon kívülre:
function(d, e) {
for (var f = 64, h = []; ++f - h.length - 32;) {
switch (f) {
case 91:
f = 44;
continue;
case 123:
f = 65;
break;
case 65:
f -= 18;
continue;
case 58:
f = 96;
continue;
case 46:
f = 95
}
h.push(String.fromCharCode(f))
}
d.forEach(function(l, m, n) {
this.push(n[m] = h[(h.indexOf(l) - h.indexOf(this[m]) + m - 32 + f--) % h.length])
}, e.split(""))
}Ha valaki azt tapasztalná, hogy bedöglött a cucc, az ezért van, mert a ciklus addig fut, amíg a karaktertömb hossza el nem ér egy bizonyos hosszt, arra meg nem volt felkészítve a cucc, hogy a switch utánra pakolja a töltést, egyszer sem jött ilyen felállás. Ezt majd a nap folyamán valamikor javítom.
- A hozzászóláshoz be kell jelentkezni
az androidos google youtube lejátszó visszafejtése nem segíthet esetleg :)
csak talán egyszerűbb a java -> pascal traspiler megírása,mint a js -> pas :)
- A hozzászóláshoz be kell jelentkezni
Sajnos Java-ul nem beszélek. Életemben egyszer foglalkoztam vele, kétszer fél napot, amikor hello world gyanánt írtam benne egy Tetris-t. Annak is már fél évtizede... :/
- A hozzászóláshoz be kell jelentkezni
private static byte[] wtf(byte[], int p1, int p2, long salt) wow. én még pascal 5.5 és Delphi meg C64 SimonsBasic is.
ránézek, hátha megtalálom :)
- A hozzászóláshoz be kell jelentkezni
Ez a deklaráció honnan jött? Csak mert a JS verzióban két karaktertömb van, az egyik a signature, a másik a salt.
wow. én még pascal 5.5 és Delphi meg C64 SimonsBasic is.
Sorry, de ezt nem sikerült értelmezni. :)
- A hozzászóláshoz be kell jelentkezni
nyugi, improvizáltam. :D sorry, az izgalomért :)
- A hozzászóláshoz be kell jelentkezni
Lehet van egy emberuk akit azert tartanak, hogy titeket szivassanak :D
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy vicc volt, de az a vicc, hogy lehet, hogy nem is vicc. Nyilván nem egy ember, hanem egy csapat, akinek tényleg az a dolga, hogy a youtube-dl és egyéb alter-YT szoftverek júzereit és fejlesztőit szívassa.
- A hozzászóláshoz be kell jelentkezni
Plusz az osszes alternativ browser hasznalojat. A firefoxot is limitaljak. A legszebb, amikor be vagy jelentkezve, mas limitet kapsz, mint amikor nem vagy bejelentkezve.
Ha be vagy jelentkezve, akkor megnezik az internetszolgaltatodat, es a multbeli letoltesi sebessegedet, hogy mikor van az internet szolgaltatodnak peak time-ja, es ahhoz visszafogjak a sebesseget a youtube-nak, hogy "ne vedd eszre".
Azt hinnen, hogy ez full kitalacio, itt egy bugzilla bug:
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Tudom, a múltkor írtam is a jelenségről.
- A hozzászóláshoz be kell jelentkezni
A kugli ismét megörvendeztetett egy kis baszakodással, ezúttal kettébontotta a wtf deciphert, immáron két külön függvényként is szerepelhet az első és a második fele (utóbbinak mindig az első kimenete van átadva harmadik paraméterként; ja, innentől van háromparaméteres függvény is...). Lekezeltem.
- A hozzászóláshoz be kell jelentkezni
Megint új variáns, megint updated...
- A hozzászóláshoz be kell jelentkezni
A kugli kezdi túlzásba vinni a taknyolást... Eddig az átadott szekunder paraméterek mindig vagy integerek voltak, ha valamelyik normál függvénynek küldte, vagy stringek, ha valamelyik wtf-nek. Most azonban egy funkció volt átadva. Igaz, hogy egy olyan függvénynek, ami egy wrapper volt a push-ra, dehát ugye itt ez nem derül ki, hiszen, hogy melyik függvény van meghívva, az obfuszkálva van. Lekezelve.
- A hozzászóláshoz be kell jelentkezni
Megint updated... Kiváncsi vagyok, hogy innentől kezdve vajon a kugli néhánynaponta át fogja írogatni azt a deciphering fost, hogy akik megpróbálják elkerülni a szutyokszkrip interpreterek használatát, azok egy idő után feladják és utána meg már egyre több-és-több JS védelmi rész fognak letolatni a torkukon, hogy a végén a nem browser-alapú klienseknek is hatvannyolc kilotonna JS-t kelljen futtatni...
- A hozzászóláshoz be kell jelentkezni
Hát, nagyon úgy néz ki, hogy ez lesz...
- A hozzászóláshoz be kell jelentkezni