tényleg...franc
[ Szerkesztve ]
Op3n Dott tablet mélyvíz - Tabletek, E-bookok fórum
üzenetek
hozzászólások
fastboot getvar secure parancsra semmit dob, üres a visszajött érték (nem tudom, hogy milyen a bl állapota 
), getvar productra válaszolt eddig:clovertail ( nem mondod.... 
)
kisspall
(aktív tag)
A 100. "jé, hát ez meg egy Teclast P89 mini" hozzászólónak adni kellene majd valami díjat. Vagy már túl vagyunk ezen a számon?
R0GERIUS
(tag)
Ha találsz hozzá olyan kitömörítőt, akkor fogjuk csak megtudni.
Ehhez a nem működő szkriptet kellene úgy szerkeszteni, hogy ne keresse az "ANDROID" részt.
Ezt elméletileg a szkriptben az ANDROID !ANDROID-ra való cserélésével talán meg is lehetne csinálni...
Érdemes lenne megnézni azt, hogy a legtöbb x86-on, hogyan oldották meg ezt a problémát...
_Soma77_
(tag)
így nem mindegy, milyen platformon írják a ki-/becsomagoló tool-t... 
Drótszamár
(őstag)
Egyelőre haszontalan mellékinfó:
Innen próbálja leszedni a frissítést a tab: https://d25qsa734cg2i4.cloudfront.net/
Mivel https ezért nem látom a küldött adatot, így csak egy AccessDenied hibaüzenetet dob a webservice.
Lehet hogy az apk-ból kinyerhetők a login infók.
Írd le, hogy mit és hogyan, szívesen megcsináljuk/om 
Drótszamár
(őstag)
Az update szerverre akarok bekukkantani, de még nem tudom hogy. Hátha van valami érdekesség ott.
Először ki kéne találni milyen adatokat kell megadni a webservice-nek hogy válaszra bírjuk.
Az adatforgalom titkosított, így a csomagok elfogása zsákutcának tűnik egyelőre. Csak a domain látszódik.
A frissítést az Autoupdate csinálja. Az apk nevét nem tudom sajna. Mivel lehet megnézni?
Azt kéne leszedni, ráengedek egy apk visszafejtőt, hátha vannak benne érdekes stringek.
Megpróbálom a forgalmat átterelni saját apache szerverre, remélem úgy látszanak a küldött adatok.
Drótszamár
(őstag)
Innen szedi az infókat: https://d25qsa734cg2i4.cloudfront.net/update.xml
Frissítés #1:
https://d25qsa734cg2i4.cloudfront.net/v1.01_20141102-ota-inc.zip
Frissítés #2:
https://d25qsa734cg2i4.cloudfront.net/v1.02_20141103-ota-inc.zip
Egyelőre nem túl sok, majd még átnézem tüzetesebben.
Aryes
(nagyúr)
Sziasztok! Egész este abban mesterkedtem, hogy hogy lehetne a gigászi /log partíciót valahogy felhasználni vmi hasznosabbra, mint amire most van használva (semmire). Megpróbáltam egy üres mappát symlinkelni a belső sd kártyára, de hiába adtam mindenféle írási/olvasási jogot neki, csak root joggal lehet megnyitni. Van erre vmi megoldás szerintetek, vagy hülyeség az egész? 
_Soma77_
(tag)
csak nem hagy nyugodni ez a header história... ![;]](/dl/s/v1.gif)
írtam egy kis progit (Eclipse alatt, mingw alatt fordul) amely a leírt [struktúrába] kibontja a header tartalmát.
ráengedve egy hagyományos (ANDORID! magic-es) image-re, szépen hozza az adatokat.
viszont a "nem standard" image-ekre (amilyen a miénk is) nem sok adatot hoz...pl. boot.img
ami aggaszt, hogy az egész struktúra mérete összesen 608 byte (feltételezve, hogy az "unsigned" típus 4 byte-os "unsigned int"-et takar), holott a header 2048 byte (0x0000-0x800-ig terjedő terület az image-ben)...
hol a hiányzó 1440 byte (=180 unsigned int?) 
[ Szerkesztve ]
R0GERIUS
(tag)
A header mérete már a standard-ra sem stimmel. 
Viszont leginkább azért nem jut semmire, mert ez elméletileg az mkbootimg-nek felel meg, amivel a következő a gond:
"mkbootimg cross-compiled for ARM will run into issues as described in this question."
Azaz az mkbootimg ARM-hez van igazítva, így nem sok mindenben tudunk rá támaszkodni. (Leszámítva a fájlok kinyerését, mert arra alkalmas.)
Főként nem header területén, hiszen esetlegesen a blokk hosszai is eltérhetnek, de ha nem is, akkor is teljesen más a header elrendezése (megkockáztatom: teljesen máshogy dolgozhat).
A blokkhossz számláló tényleg nem stimmel, de ha még jó is lenne, nem sokra megyünk vele x86-os Android alatt. 
[ Szerkesztve ]
R0GERIUS
(tag)
IGEEEEN!
Habár nincs megoldva a header probléma, de 100%-ig ugyanolyan repacket sikerült készíteni.
Ha valaki átdobja, hogy miket kell módosítani a recovery.img-ben, illetve a boot.img-ben, akkor megnézném, hogy mennyi az eltérés.
Ha megtartja a header-t és csak a lényeges részeket írja felül, akkor van egy használható img tool. 
Talált eszköz: [link]
UPDATE: Nálam a kibontott ramdisk az szerintem hibás. Lehet, hogy repack-re lesz majd csak alkalmas?
Mondjuk az is elég lenne...
R0GERIUS
(tag)
UPDATE 2: korai volt a lelkesedés.
Valahogy a két dolgot össze kellene házasítani.
Itt jó a a repack és ott az unpack.
Amúgy a hiba amit dob a ramdiskhez: túl korai archívumvég. Azaz nem jól kezeli a végét a ramdisk-nek és az elejét zImage-nek...
Ha viszont a tool-al oda vissza csinálom akkor 100% ugyanolyan image-t ad, de ha a másik által kibányászott ramdisk-et és kernel képet használom, akkor elég sok eltérés van benne.
Ezzel a tool-al kicsomagolt ramdisk 0-38C000-ig tart, míg a rendes ramdisk-nek 38C020-ig, tehát valóban a mérettel van a gond. Valahogy azt kellene korrigálni, és valószínűleg megvan.
[ Szerkesztve ]
R0GERIUS
(tag)
UPDATE 3: Sajna nem nyersen a méret a hiba.
Átirtam a kódot, így megfelene a méret, de nem stimmel, továbbra sem nyitható meg.
Lehet, hogy maga a blokkok pozíciója más?
Az sok mindent megmagyarázna...
UPDATE 4: El van számolva.
Az eredeti szkript, ami értelmes fájlokat nyert ki, az onnan kezdi leválasztani, ahol a fájlban megtalálja ezt: 1F 8B (magic number)
Itt is megvan ez a szám, csak 1000-el elcsúszva...
Át kell paraméterezni a program által kiolvasott blokkokat.
[ Szerkesztve ]
