- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- Parci: Milyen mosógépet vegyek?
- sziku69: Szólánc.
- Aggregátor gondjai, örömei, és elmélkedései
- Chosen: Canon 5D II - portrézás 2025-ben
- zebra_hun: Hűthető e kulturáltan a Raptor Lake léghűtővel a kánikulában?
- Drivv: Prehistorik 2 - Retró Játékpercek! 1. rész
-
LOGOUT
Ezt a fórumot azért hoztuk létre,hogy ne zavarjuk azon felhasználókat, akik még csak most ismerkednek a tablettel, vagy akár az Android rendszerrel.
Új hozzászólás Aktív témák
-
#200
Orionhilles
senior tag
Aryes
#199
Orionhilles
senior tag
-
#195
rasky
senior tag
Orionhilles
#193
rasky
senior tag
válasz
Orionhilles
#193
üzenetére
A rootolás nem nyitja a bootloadert? Mert pl Moto G esetén, csak nyitás után lehetett rootolni.
-
#193
Orionhilles
senior tag
_Soma77_
#192
Orionhilles
senior tag
válasz
_Soma77_
#192
üzenetére
Simán elképzelhető: fastboot oem <titkos parancs>
Successful, now your bootloader is unlocked
Kedves <én>!
Bootloader nyitással, rootolással és hasonlókkal még nem próbálkoztunk, így erre válaszolni nem tudunk. A particionálásról pedig értesültünk és továbbítottuk a fejlesztőknek, akik dolgoznak a hiba javításán.
Köszönettel,
Op3ndott.No, nem baj, majd próbálkozzatok csak nyugodtan!
-
#192
_Soma77_
tag
Orionhilles
#191
_Soma77_
tag
válasz
Orionhilles
#191
üzenetére
reméljük, előbb-utóbb mindennek meglesz a módja
vagy már meg is van, csak még nem tudunk róla -
#190
_Soma77_
tag
Orionhilles
#189
_Soma77_
tag
válasz
Orionhilles
#189
üzenetére
attól mert zárt, az még nem feltétlenül jelenti azt, hogy nem lehet kinyitni...
![;]](//cdn.rios.hu/dl/s/v1.gif)
általában minden szoftveres mókolás garanciavesztéssel jár, de aki ilyenre adja a fejét, az ezzel alapból tisztában van szóval az a kérdés, ki lehet-e nyitni egyáltalán. -
#189
Orionhilles
senior tag
Orionhilles
senior tag
Rossz hír: zárt bootloader
Ráírtam az Op3n Dott-ra, és a szokásos:
Kedves <én>!A tablet bootloadere zárt. Bármilyen szoftveres beavatkozás sajnos garanciavesztéssel jár.
Köszönettel,
Op3ndott.:'(
-
#184
_Soma77_
tag
Orionhilles
#182
_Soma77_
tag
válasz
Orionhilles
#182
üzenetére
link javítva
-
_Soma77_
tag
mai házi csapatmunkánk eredményei (köszönet a kollégáknak!!!):
- külső 16GB-s SD kártya Ext4-re formázva
- recovery-be belépve, adb shell-en keresztül dd-vel teljes belső tárhely tartalom image-ként lehúzva (8GB)dd if=/dev/block/mmcblk0 of=/external_sd/soma_backup.img
Ez az image be-mountolható, így látszik a /system stb...
mount /dev/block/mmcblk1p1 /external_sd
- kollégám kitotózta az $OS$ magic-es boot.img szerkezetét:
OSIP header [link]
master boot rekord (MBR)
signature
és végül a partíció tartalmaa szívás az, hogy az image aláírt kell hogy legyen
a jó hír, hogy egy orosz PDA fórumon találtunk egy XImgTool nevű csodatool-t, ami image-eket ki-be csomagol éééés aláír is! [link]
jó hír, hogy a ki és visszacsomagolás ugyan olyan $OS$ magic-es képfájlt eredményez! 
- találtunk egy másik tool-t is, ami ramdisket is kicsomagolja, ezt még próbálgatni kell (nem próbáltuk ki, hogy aláír-e pl.) [link]
- akinek van Total Commander win alatt, érdemes feltetelíteni az adb-plugin-t, szépen browse-olható vele a tab ADB interface-en kersztül... [link]
Most itt tartunk jelenleg...
-
R0GERIUS
tag
válasz
R0GERIUS
#178
üzenetére
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. -
R0GERIUS
tag
válasz
R0GERIUS
#177
üzenetére
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.
-
R0GERIUS
tag
válasz
_Soma77_
#175
üzenetére
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
válasz
_Soma77_
#175
üzenetére
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. -
_Soma77_
tag
válasz
R0GERIUS
#164
üzenetére
csak nem hagy nyugodni ez a header história...
í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?)
-
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?
-
#173
Drótszamár
őstag
Orionhilles
#171
Drótszamár
őstag
válasz
Orionhilles
#171
üzenetére
Innen szedi az infókat: https://d25qsa734cg2i4.cloudfront.net/update.xml
Frissítés #1:
https://d25qsa734cg2i4.cloudfront.net/v1.01_20141102-ota-inc.zipFrissítés #2:
https://d25qsa734cg2i4.cloudfront.net/v1.02_20141103-ota-inc.zipEgyelőre nem túl sok, majd még átnézem tüzetesebben.
-
#172
Drótszamár
őstag
Orionhilles
#171
Drótszamár
őstag
válasz
Orionhilles
#171
üzenetére
Köszi. Lássuk mi van benne -
#171
Orionhilles
senior tag
Drótszamár
#170
Orionhilles
senior tag
válasz
Drótszamár
#170
üzenetére
-
#170
Drótszamár
őstag
Orionhilles
#169
Drótszamár
őstag
válasz
Orionhilles
#169
üzenetére
You need permission
-
#169
Orionhilles
senior tag
Drótszamár
#168
Orionhilles
senior tag
válasz
Drótszamár
#168
üzenetére
com.softwinner.update
-
#168
Drótszamár
őstag
Orionhilles
#167
Drótszamár
őstag
válasz
Orionhilles
#167
üzenetére
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.
-
#167
Orionhilles
senior tag
Drótszamár
#166
Orionhilles
senior tag
válasz
Drótszamár
#166
üzenetére
Írd le, hogy mit és hogyan, szívesen megcsináljuk/om
-
#166
Drótszamár
őstag
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. -
_Soma77_
tag
-
R0GERIUS
tag
válasz
_Soma77_
#157
üzenetére
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... -
#162
Orionhilles
senior tag
Orionhilles
senior tag
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.... ) -
#161
lacafaca
addikt
Orionhilles
#159
lacafaca
addikt
válasz
Orionhilles
#159
üzenetére
tényleg...franc
-
_Soma77_
tag
lehet, hogy vakvágány, de....
valaki írta korábban, hogy ez a gép egy Teclast klón. Nem egy Teclast 89 mini véletlenül?
[speckója] elégge hasonló.a baj csak annyi, hogy ez a gép is 16GB-os --- ahogy az Op3n Dott eredeti gépe is.
van hozzá root-olt ROM [link] innen [link]
a partíciós tábla (partition.tbl) is elég hasonló felosztást mutat.
talán érdemes ezt a szálat is nyomozni egy kicsit...
-
R0GERIUS
tag
válasz
_Soma77_
#149
üzenetére
Szerintem a fejlécnek nincs köze hozzá, hogy min lett generálva.
A Moto-sok azzal próbálkoztak, hogy a szkriptbe beírták a változó negáltját, de az se egy túl biztos módszer.
A hexá-s nekem biztosabbnak tűnik, hisz mivel egyszer ki tudtuk bontani, így elég könnyen megmodható, hogy meddig tartanak az egyes részek (header, cpio, kernel).
Amúgy ez a '$OS$' jelölés az android helyett az elején inkább indefinit. Sok helyen (szkriptekben) így jelölik, esetlegesen a din. adatot, azaz hogy pl. olvassa ezt az adatot, és nem fix adat.
Bár elég ronda dolog ez egy header-ben. -
R0GERIUS
tag
válasz
_Soma77_
#149
üzenetére
Nézz rá a #145-re.
Úgy néz ki, hogy az összes x86-osnál nem standard a header, és nem működnek a szabvány módszerek erre nézve.
Ahogy utaltam is rá: sajnos valószínűleg ezen a vonalon kell elindulni...
A hexeditoros módszer jónak tűnt elsőre, de sajna nincs időm kipróbálni. -
_Soma77_
tag
válasz
R0GERIUS
#143
üzenetére
megnéztem a linken szereplő eljárást is, leszedtem a tool-okat, de a "unmkbootimg" nem ette meg a mi képfáljainkat.
az általam korábban használt perl szkriptek egyébként a leírtak alapján dolgoznak (BTW zImage helyett ...-kernel.gz file-okat gyártanak), és az image összerakás (kernel, és cpio-ba becsomagolt ramdisk összefésülése) is teljesen jónak tűnik... kicseréltem a "mkbootimg" toolt is egy frissebbre (ami a linken szerepelt), és átparamétereztem a hívást a leírtak alapján, de ugyan az lett a kimenet, mint korábban... 
nekem úgy tűnik az eredeti image fejléce alapján, hogy ez vmi OSX-es tool-lal generált dolog lehet, mert 1. nem a standard magic android header keletkezik 2. BoardConfig.mk-ból származó dolgok vannak benne (kernel szint?!), tehát ez több, mint egy sima "lapátoljunk össze egy image"-et tool mint az "mkbootimg"...
akinek van ötlete, pls jelezze!
-
_Soma77_
tag
válasz
R0GERIUS
#144
üzenetére
rákeresve a kérdéses olvasható részére a boot.img-nek, eljutottam egy BoardConfig.mk-ig, mintha innen lenne...
BOARD_KERNEL_CMDLINE := init=/init pci=noearly console=logk0 earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay $(cmdline_extra) ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0
n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main -
_Soma77_
tag
@Adamus1117: köszi, hogy belenéztél...és köszi a tippeket is...
próbaképpen egy újonnan készített img-et kicsomagoltam majd újra becsomagoltam, és nem lett ugyanaz
na erre végképp nem számítottam, lehet, hogy vagy 1. vmit elböktem (bár többször is kipróbáltam) 2. az x86-os "anomália" okozza... 
-
R0GERIUS
tag
válasz
R0GERIUS
#144
üzenetére
Nos ezen értelmes részek még egy érdekes helyre vittek, és sikerült felfedezni valamit, de a befejezést rátok hagyom.
Alapvetően minden hiba/kellemetlenség a képfájlok kibontásában és újracsomagolásában az X86 miatt van.
Úgy néz ki, hogy ezen architektúrára épülő készülékek boot-ja és recovery-je eltér a szokványostól (ARM).
Így a keresési irány: Android x86 képfájlok kezelése.Véletlen bele is futottam XDA-n egy olyan Motorolába aminél hasonló gondoktól szenvedtek a képfájloknál (pontosan az Intel x86 miatt):
[link]
(Lehet, hogy érdemes végignézni, mert sok a hasonlóság: egyedi header, egyes részek (amit kiemeltem az előzőben) ugyanúgy szerepeltek benne...)Nem olvastam végig, de említenek egy hexa szerkesztőn alapuló megoldást:
[link]Idő hiányában nem tudok most ennél jobban belemélyedni; ezt rátok bízom.
-
R0GERIUS
tag
válasz
R0GERIUS
#143
üzenetére
Na jó; nem bírtam megálni.
A header-rel jelenleg én sem tudok mit kezdeni.
A recovery és a boot meg iszonyatosan nagy hasonlóságot mutat, ami különös...
Talán az egyik a másik backupja?
A fájlokat elnézve nem tartom lehetetlennek.A másik érdekesség az, hogy a header-nek van egy olvasható részlete:
"init=/init pci=noearly earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789012345678901 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M ehci_hcd.use_sph=1"Az újracsomagoltból ez hiányzik.
Ezen kívül külön érdekes ez a két rész:
"androidboot.hardware=redhookbay"
A configban van pár ilyen kiterjesztésű fájl.
"androidboot.bootmedia=sdcard"
Micsoda?!?! (Vad feltételezés: USB módban innen várja a boot helyreállító fájlját?)A harmadik: a klasszikus módszertól eltérően nem készül a kibontáskor zImage, hanem helyette xxx.img-kernel.gz (meg sem említem, hogy mind a recovery, mind a boot kibontása dob egy ilyen fájlt...).
-
R0GERIUS
tag
-
#142
Drótszamár
őstag
Drótszamár
őstag
Üdv!
Úszni nem tudok, de most vettem egy ilyen tabot. Még nem frissítettem. Kell az eredeti rom?
Ha kapok egy rövid leírást, hogy hogyan kell leszedem szívesen holnap este.
4.4.2
F9.EE
3.10.20-as kernel 2014.09.10 13:41:13
1.00_20140910-es build. -
_Soma77_
tag
válasz
R0GERIUS
#139
üzenetére
az a helyzet, hogy a re-pack szkript nem ugyan olyan fejlécű image-et rak össze, mint az eredeti volt.
Örülnék, ha valaki rá tudna nézni egy kicsit közelebbről...
felraktam ide a teljes motyót, minden köztes állománnyal és szkript-tel. [link]
van két pearl szkript (unpack-bootimg.pl és unpack-bootimg2.pl), amelyek gyakorlatilag csak parancssoros hívásban térnek el egymástól...
1) system ("mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");
2) system ("mkbootimg --base 0x00200000 --pagesize 2048 --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");...viszont mindkettő a csomagban lévő mkbootimg-t hívja.
A kimeneti image-ek (new_boot.img és new_boot2.img) csak a parancssorban különböznek (header részben), többi ugyan az...miért is lenne más?
Viszont az eredeti img és az újra-pakolt img több ponton is különbözik, főleg a fejlécben, mivel nem "ANDROID!"-dal kezdődik, hanem "$OS$"-al.
Szerintem kellene találni egy olyan "mkbootimg"-et, ami az eredetivel megegyező image-et gyárt.
Az újrapakolt image-ek elvileg(!) Android kompatibilisek, kérdés, hogy az Op3n Dott megeszi-e???
Ötlet?
-
R0GERIUS
tag
-
#135
_Soma77_
tag
Orionhilles
#134
_Soma77_
tag
válasz
Orionhilles
#134
üzenetére
ok, de még előtte kicsit gyakorlom a re-pack-ot a boot.img-n, hogy meglegyen a rutin, meg hogy lecsekkoljam, tényleg jó-e a re-pack szkript, mielőtt brick-eljük a tabodat...
-
#133
_Soma77_
tag
Orionhilles
#132
_Soma77_
tag
válasz
Orionhilles
#132
üzenetére
itt a kibontott recovery
[link] szóval mit is kellene vele csinálni? -
#128
Freddycom
őstag
Orionhilles
#126
válasz
Orionhilles
#126
üzenetére
Ne kelljen hasznalni, csak akkor jo tudni, h van ilyen lehetoseg, ha mondjuk a tescoba vissza kell kuldeni garanciaba.
A visszaallitott tab nem lesz rootolt, igaz?
Amit irtal parancsokat, azt az adb interface-en keresztul kell beirni gepen?
-
#125
Freddycom
őstag
Orionhilles
#120
válasz
Orionhilles
#120
üzenetére
Mit jelent az ep bootloader? Be tudok lepni a power+hangero fellel. Visszaallitas utan root nelkuli, igaz?
-
#123
Orionhilles
senior tag
_Soma77_
#121
Orionhilles
senior tag
válasz
_Soma77_
#121
üzenetére
A recoveryt, azt nagyon ki kellene bontani
Van egy 5letem: kibontjuk, valahogy kiszedjük belőle az aláírás ellenőrzést, repack, flash és akkor utána belőle flashelhető lesz a CWM
#122: FW DnX,IFWI, OS DnX, OS img ezekre a fájlokra gondoltam, de koszö a tool-ért lehet az is jó lesz még vmire
#124: Próba cseresznye, én írtam nekik szombat du. remélem holnap kapok választ (igaz nem kernel forrással kapcsolatban, hanem még partíciók mentésével kapcsolatban ) -
#122
Nmajkix
csendes tag
Orionhilles
#118
Nmajkix
csendes tag
válasz
Orionhilles
#118
üzenetére
ez esetleg nem jó?: [link]
-
#121
_Soma77_
tag
Orionhilles
#116
_Soma77_
tag
válasz
Orionhilles
#116
üzenetére
gratula
Freddycom boot.img-jét még nem bontottam ki, mindjárt megcsinálom, mert bár hosszra uaz, de a tartalma nem az...
kibontás után látható lesz a különbség...
Többi image-et is ki kellene bontani, nem? főleg recovery lehet érdekes....
-
#120
Orionhilles
senior tag
Freddycom
#119
-
#118
Orionhilles
senior tag
Orionhilles
senior tag
Ahogy elnézem ezek a fájlok eszköz specifikusak... Valahogy meg kellene őket szerezni, nem hiszem, hogy az Aceréi jók lennének, bár ki tudja...
-
_Soma77_
tag
-
#112
Orionhilles
senior tag
_Soma77_
#111
-
#111
_Soma77_
tag
Orionhilles
#110
_Soma77_
tag
válasz
Orionhilles
#110
üzenetére
"adb sideload revovery.zip" elvileg kiadható parancs de "adb sideload" menüpont recoveryben? azt hol kellene látnom?
Sideload nem kezd el telepíteni valamit?Ahogy mondtam, a hardcore flash-elgetést meghagynám másnak...
-
#109
_Soma77_
tag
Orionhilles
#107
_Soma77_
tag
válasz
Orionhilles
#107
üzenetére
recovery launcher mappa hol van?
-
#107
Orionhilles
senior tag
_Soma77_
#106
Orionhilles
senior tag
válasz
_Soma77_
#106
üzenetére
Ez nekünk már megvan
. A recovery launcher mappában van valahol egy update.zip (ez a CWM).
Megtennéd, hogy a tabot recoverybe indítod, ott kiválasztod az adb sideload-ot, gépen pedig beírnád, hogy adb sideload update.zip? (ez a CWM) Ha minden igaz, CWM recovery fog betöltődni -
#105
philips20
aktív tag
Orionhilles
#104
philips20
aktív tag
válasz
Orionhilles
#104
üzenetére
Akkor várjuk az igazságot
-
bocsi... 
vagy már meg is van, csak még nem tudunk róla ![;]](http://cdn.rios.hu/dl/s/v1.gif)
így nem mindegy, milyen platformon írják a ki-/becsomagoló tool-t... 
n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main
Új hozzászólás Aktív témák
Hirdetés
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- exHWSW - Értünk mindenhez IS
- Google Pixel topik
- OLED monitor topik
- Milyen légkondit a lakásba?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Kazy Computers - Fehérvár - Megbízható?
- Kompakt vízhűtés
- Kamionok, fuvarozás, logisztika topik
- Lakáshitel, lakásvásárlás
- További aktív témák...
- iPad 10th. 64GB Wifi Újszerű/1-3 hónap gar./Akku 95%/p4281
- Panasonic Toughbook Cf H2 - Ütésálló tablet.- Erős fényerővel - Több darab
- Új - Apple iPad mini 7.gen 2024 Wi-Fi 128GB Purple/Blue/Space Gray - Bontatlan
- Honor Pad X8a 64GB Wifi,1 év Garancia
- MacSzerez.com - iPad Pro 12.9" / M2 / Ezüst / Wifi / 256GB / Garancia
- DELL Universal Dock D6000 dokkolók, RTX Legion Pro laptopok 4 év Lenovo garanciával, licencek
- BESZÁMÍTÁS! MSI B550M R7 5800X 32GB DDR4 512GB SSD RX Nitro+ 6700XT 12GB Corsair 4000D ASUS ROG 650W
- ÁRGARANCIA! Épített KomPhone Ryzen 5 5500 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- Telefon szerviz helyben - Gyors javítás, akár 30 perc alatt!
- AKCIÓ! Épített KomPhone R5 4500 16GB RAM 240GB SSD RX 6500 XT 4GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest