Debranding - CSC Wechseln

  • 88 Antworten
  • Letztes Antwortdatum
G

gggggg

Fortgeschrittenes Mitglied
7
Bei den aktuellen Preisen, scheint das Tab innerhalb EU wohl in Italien sehr günstig zu sein (SM-T705 ~ 425€ bei Amazone ;-).

Ich hab nun mal von sammobile die deutsche (DBT), italienische (ITV) und österreichische (ATO) Firmware T705XXU1ANF7 runter geladen.

system, recovery, boot, sboot, param sind ident.
Bei I und Ö ist auch noch die modem ident.
hidden Cache sind unterschiedlich.

Dann hab ich mit Odin die I Firmware auf ein deutsches Gerät geflashed. Tel. und Daten funktionierten. Außer dass die Einstellungen bei der I auf dem 2. Homescreen sind ist mir nichts aufgefallen.
Auch der official Status blieb erhalten.

1 Mal grundsätzlich: Hat man also ein Gerät aus I (mit CSC=ITV). Was spricht dagegen die Ö (ATO) Firmware zu flashen ?

2 Welche Gründe kann es geben dass zwischen D und I/Ö die modem.bin unterschiedlich ist ? (andere Frequenzbänder bei LTE ???)
aus der ATO modem.bin: SP7160_V2_MODEM_01.1420.03 2014-Jun-16 23:26:12 SP7160_V2_MODEM_01.1420.03_BL01 T705XXU1ANF6
aus der DBT modem.bin: SP7160_V2_MODEM_01.1420.03 2014-Jun-20 17:19:38 SP7160_V2_MODEM_01.1420.03_BL01 T705XXU1ANF7
EDit: Ich glaube da kann man Entwarnung geben. Da in der ital. T705XXU1ANF8 die gleiche modem.bin drin ist, wie in der deutsch. T705XXU1ANF7.

3 Wenn man dann z.B. mit CF-Autoroot rootet, wird ja eine "fremde recovery" installiert. Würde man also mal recovern (ohne TWRP zu nutzen) hätte man zwar root erhalten aber doch andere Software an Board. Wäre es also sinnvoll nach dem rooten für den Fall der Fälle die eigene recovery aus dem Firmwarepackage z.B. per Flashify zu installieren ?
 
Zuletzt bearbeitet:
Was versprichst du dir von der Aktion? Kannst das tab wohl genauso auf dem italienischen ROM betreiben. Nach dem rooten ist knox gesetzt. Danach kannst du installieren was du willst. Die Stock Recovery von Samsung taugt aber nicht viel.
 
gggggg schrieb:
Dann hab ich mit Odin die I Firmware auf ein deutsches Gerät geflashed.
Ich hoffe, du hast bedacht, dass das ein Debranding Vorgang ist und hast vor ein EFS und IMEI Backup gemacht. Sonst ist dein EFS jetzt angeschlagen und kann bei jeder kommenden Flash Aktion verloren gehen. Das bedeutet dann, dass die IMEI flöten geht und dein LTE Modem nicht mehr benutzbar ist.

gggggg schrieb:
1 Mal grundsätzlich: Hat man also ein Gerät aus I (mit CSC=ITV). Was spricht dagegen die Ö (ATO) Firmware zu flashen ?
Wenn man die erforderlichen Vorsichtsmaßnahmen beachtet, nichts.

gggggg schrieb:
2 Welche Gründe kann es geben dass zwischen D und I/Ö die modem.bin unterschiedlich ist ? (andere Frequenzbänder bei LTE ???)
Unterschiedliche Optimierungen für die im Netz eingesetzten Basisstationen und deren Firmwares. Mittlerweile ist man so weit, dass in den Modem Firmwares spezielle Workarounds und Optimierungen für praktisch alle relevanten Chipsätze enthalten sind, die üblicherweise in einem Netz zum Einsatz kommen. Umgekehrt gibt es auch Optimierungen in der Software der Basisstationen. Ziel ist eine möglichst gute Performance und Interoperabilität der Geräte.
 
frank_m schrieb:
Ich hoffe, du hast bedacht, dass das ein Debranding Vorgang ist und hast vor ein EFS und IMEI Backup gemacht. Sonst ist dein EFS jetzt angeschlagen und kann bei jeder kommenden Flash Aktion verloren gehen. Das bedeutet dann, dass die IMEI flöten geht und dein LTE Modem nicht mehr benutzbar ist.
Ich erinnere mich dunkel, dass wir das schon mal diskutiert hatten. Aber es klingt nicht so wirklich schlüssig.
Wie ist da der Zusammenhang nun genau, bzw. wo kann man das nachlesen?
 
Danke für den EFS Hinweis. Das hatte ich zwar am Beginn meiner Recherche schon mal gelesen, dann aber aus den Augen verloren.

- Wobei sich die Katze etwas in den Schwanz .... Denn ohne Root kein Backup von /efs ODER ? Und einigen hats beim Root genau den ordner verändert/gelöscht.

- Wo die IMEI steckt weis man noch immer nicht ODER ? (ein user hat /efs entsorgt und es lief immer noch bzw. war der Ordner nach Neustart wieder da)
- Was meinst du dann mit EFS und IMEI Backup ? (einen screenshot der Daten habe ich jedenfalls)

Welche Vorgehensweise schlagt ihr vor ?
1 CF-Autoroot

2a dann den Ordner mit Root Explorer auf meine .ext3 Partition auf die SD zu verfrachten. Oder wäre es besser
2b ihn per ADB mit dd zu sichern, da dann die Rechte einfacher/sicherer mitgesichert werden
2c den Ordner erst nach Installation von TWRP damit zu sichern

3 IMEI Backup - how to ???

Und könnte ihr bitte noch zu Punkt 3 aus meinem ersten post antworten ...
 
Zuletzt bearbeitet:
gggggg schrieb:
Und einigen hats beim Root genau den ordner verändert/gelöscht.
Dann haben sie nicht aufgepasst. Der Root Vorgang ist unkritisch, solange man sich präzise an die Anleitung hält.

gggggg schrieb:
- Wo die IMEI steckt weis man noch immer nicht ODER ?
Doch. Bei Geräten mit Intel Modem liegt sie im EFS. Bei Qualcomm Geräten im nvram, den man mit QPST auslesen kann.

gggggg schrieb:
(ein user hat /efs entsorgt und es lief immer noch bzw. war der Ordner nach Neustart wieder da)
Aber nicht bei einem Intel-basierten Gerät (und auch bei Qualcomm war er anschließend im Factory Mode und hatte einen Haufen Arbeit vor sich).

Bezüglich EFS Backups kannst du dich an den Anleitungen der anderen Samsung Geräte orientieren. Die Tools funktionieren zwar wahrscheinlich nicht, aber der Weg von Hand sollte problemlos funktionieren.
 
Zuletzt bearbeitet:
Mit HW_info bekommt man zwar viel über das Innenleben raus, aber nicht übers Modem ... wo seh ich das ? Da es ein Exynox ist wird's vermutlich Intel.

Welche Methode für EFS backup ? 2a-c

Wenn man dann z.B. mit CF-Autoroot rootet, wird ja eine "fremde recovery" installiert. Würde man also mal recovern (ohne TWRP installiert zu haben) hätte man zwar root erhalten aber doch andere Software an Board. Wäre es also sinnvoll nach dem rooten für den Fall der Fälle die eigene recovery aus dem Firmwarepackage z.B. per Flashify zu installieren ?
 
EFS-Backup:
2a dann den Ordner mit Root Explorer auf meine .ext3 Partition auf die SD zu verfrachten. Oder wäre es besser
2b ihn per ADB mit dd zu sichern, da dann die Rechte einfacher/sicherer mitgesichert werden
2c den Ordner erst nach Installation von TWRP damit zu sichern

Nach dem Root Recovery von Autoroot behalten oder oder Stock drüber büglen:
Wenn man dann z.B. mit CF-Autoroot rootet, wird ja eine "fremde recovery" installiert. Würde man also mal recovern (ohne TWRP installiert zu haben) hätte man zwar root erhalten aber doch andere Software an Board. Wäre es also sinnvoll nach dem rooten für den Fall der Fälle die eigene recovery aus dem Firmwarepackage z.B. per Flashify zu installieren ?
 
In dem Fall würde ich 2b bevorzugen. So sichere ich meine EFS Partitionen.

Ja, ein original Recovery zu flashen kann nicht schaden.
 
Auf welchen Wegen kann man mit "dd if=/dev/block/mmcblk0pXX of=/storage/extSdcard/NNNN.img" gesicherte EFS.img, recovery.img, System.img wieder aufs Gerät bekommen ?? (adb, Odin, flashify)
 
Auf dem gleichen Weg, wie bei der Sicherung, nur muss man if und of vertauschen.

System.img würde ich auf dem Weg allerdings nicht flashen, wenn das System gebootet ist. Da sollte man dann auf ein Custom Recovery mit ADB Shell Unterstützung zurückgreifen.
 
Ah, danke, dass der restore so einfach geht war mir als Linux noob nicht klar.

1. SYSTEM:
Im Odin und Stock-Recovery-Modus bekommt man ja keine ADB Verbindung oder ?
D.h. man muss z.B. TWRP installieren um dann wieder per ADB / dd rücksichern zu können? Warum dann nicht gleich die TWRP Sicherung ?

2. RECOVERY:
Wir hatten ja besprochen die von CF Autoroot eingespielte recovery durch die Stock zu ersetzen. Mit welcher Methode (geht Odin, flashify, dd) ?
Die Stock Recovery ist ja ein "sparsed Image" ... was immer das bedeutet (löchrig;-)

2a Odin:
Mit Odin muss man glaub ich das .img in ein .tar packen, [Tool][[windows] Make CWM Recovery .img's in… - Pg. 5 | Android | XDA Forum, http://forum.xda-developers.com/showpost.php?p=45629177&postcount=1 da gibt's leider zig Varianten (hab mal meine Varinate angehängt, bin unter Win7, 8.1) die einen sagen das Format für tar ist ustar und die anderen gnu ... was stimmt den nun für Odin ?

- wie geht's unter Linux ?

2b Mit flashify gings auch ...

2c Und wie mit dd ?
 

Anhänge

  • img2tar.zip
    3,8 MB · Aufrufe: 137
Zuletzt bearbeitet:
Redest du jetzt nur vom EFS Backup? Oder was ist im Moment dein Ziel?
 
Ich hab mal alle Partitions mit dd gesichert. So gesehen auch EFS. Nun geht's um die Wege wie man die heiklen Dinge wie 1. System und 2. Recovery aus dem dd Backup und/oder StockImage wieder zurück bringt.
 
System ist kein heikles Ding. Da kann man mit Backups eigentlich nur Dinge kaputt machen. Das flasht man ab besten über eine Stock ROM mit Odin.
 
System: du meinst EIN nicht kein ;-)

OK, wenn man nur System restoren möchte muss man aber vermutl. das System.img aus dem Stock Package zuerst wieder in ein .tar.md5 konvertieren.

Da gibt's auch Möglichkeiten ... siehe 2a vorletzter post

Format=ustar
Code:
bin\tar --group=1 -H ustar -c NON-HLOS.bin modem.bin > %tarname%.tar
bin\md5sum -t %tarname%.tar >> %tarname%.tar
bin\mv %tarname%.tar %tarname%.tar.md5
Auszug aus dem .bat, Format = gnu
Code:
tar --create --format=gnu -b20 --quoting-style=escape --owner=0 --group=0 --totals --mode=644  -f %%~nG.tar %%~nxG
md5sum -t %%~nxG >> %%~nxG
oder überhaupt ohne md5
Code:
tar -cvf output.tar file1.bin file2.bin file3.img file4.img.ext3 ...
Was ist nun zu verwenden ?
 
Zuletzt bearbeitet:
Kein "Guru" eine Idee ?
 
Du kannst kein Image, dass du mit dd generiert hast, mit Odin flashen. Odin flasht SPARSE Images. dd ist ein RAW Image. Da ist es egal, welches TAR Programm du nutzt.

Übrigens: Ich nutze unter Windows einfach den Total Commander für der erzeugen von TAR Dateien für Odin. Hat immer noch funktioniert. Unter Linux benutze ich einfach tar ohne weitere spezielle Optionen.
 
Zurück
Oben Unten