ZTE H220N (Experiabox) tweaken v2/H368N ExperiaBox v9 Versie

[MrDikke]

Hoi,

Ik heb een ExperiaBox'je v9 (In het vervolg genoemd als EBV9). Ik wil er alleen meer uit. Beetje Tweaker gevoel dat. Dus ben wat aan 't googlen geweest, kwam al snel op dit topic: ZTE H220N (Experiabox) tweaken

Eigenlijk wil ik hetzelfde als in dit topic, maar dan voor de EBV9...

Heb nog meer speurwerk gedaan, kom je ook vrij snel op de OpenWRT website uit. https://wiki.openwrt.org/toh/zte/zte_zxhn_h368n

Geeft duidelijk aan dat zij ook nog geen idee hebben van een CFE/Bootloader password. KPN houd deze net als in het boven genoemde geval achter. Still open source?

Ik ben zelf wat aan 't klooien gegaan. Om hem in CFE HTTP modus te krijgen is niet moeilijk:
1. Zet de EBV9 uit, en druk een paperclip op het resetknopje.
2. Zet de EBV9 weer aan, en houd de paperclip op het resetknopje.
3. Houd de paperclip erop totdat het Power ledje rood wordt.
4. Tadaa!

Maar dan, je hebt geen internet, logisch. Mocht je naar de gateway gaan (192.168.2.254) of mijnmodem.kpn of iets dergelijks, krijg je het volgende in beeld:


Ik heb wat standaard dingen geprobeerd (admin/admin, admin/password, root/root) maar lijken niet te werken. Als je op Annuleer/Cancel drukt krijg je het volgende schermpje te zien.

Geeft ons weer wat, micro_httpd. Op naar google!

Geeft gelijk andere mensen die ook hun router proberen te hacken. Nais.
https://www.hellboundhack...20_router-14-16260_0.html

Blijkbaar is/was het wachtwoord in plaintekst opgeslagen op een DV-2020. Password.html bestaat helaas niet op de EBV9.

Dat is hoever ik ben gekomen tot nu toe. Ik hoop wat input te krijgen vanuit jullie mede-tweakers. Of zijn mijn enige opties Dictionary Attack/Brute Force? Of een DirBuster in de hoop een plain text file te bemachtigen?

Let op: Mijn doel is daadwerkelijk root access etc. te krijgen. Vanuit daar mogelijk telnet. Het is een bezigheidsprojectje soort van

[ Voor 5% gewijzigd door MrDikke op 10-01-2017 21:25 ]

[Anoniem: 203842]

Ik snap dat je er meer uit wilt halen.

Maar als je "snel resultaat" wilt zien: Laat dat ding zoals deze is, zet DHCP uit, en hang er een DD-WRT, Mikrotik of Pfsense router erachter. Kan je VEEL meer, en beter.

Laat die EBv9 puur voor de fysieke verbinding (zo zal ook je telefonie goed werken).


Ja, het is misschien niet het antwoord wat jij wilt, maar zo kom je sneller verder, en blijf je niet avonden het wachtwoord raden / brute forcen etc....

[MrDikke]

Anoniem: 203842 schreef op dinsdag 10 januari 2017 @ 19:09:
Ik snap dat je er meer uit wilt halen.

Maar als je "snel resultaat" wilt zien: Laat dat ding zoals deze is, zet DHCP uit, en hang er een DD-WRT, Mikrotik of Pfsense router erachter. Kan je VEEL meer, en beter.

Laat die EBv9 puur voor de fysieke verbinding (zo zal ook je telefonie goed werken).


Ja, het is misschien niet het antwoord wat jij wilt, maar zo kom je sneller verder, en blijf je niet avonden het wachtwoord raden / brute forcen etc....

Het hoeft niet snel, deze EBv9 is een kapotte (wifi bereik is nog slechter als normaal) maar werkt verder prima. Ik heb aan kpn gevraagd of ik hem mag houden voor persoonlijk gebruik waar ze naar mijn verbazing geen probleem mee hadden.

DHCP is alleen volgensmij vanuit de firmware automatisch ingeschakeld. Dus kan deze ook niet uitzetten AFAIK! Mocht je wel weten hoe hoor ik het graag.

[Anoniem: 203842]

Is niet erg. Bij Mikrotik kan je poorten "isoleren". Laat die DHCP maar aan staan. Dan zal de Mikrotik de enige zijn die de client is.

[MrDikke]

Anoniem: 203842 schreef op dinsdag 10 januari 2017 @ 19:54:
Is niet erg. Bij Mikrotik kan je poorten "isoleren". Laat die DHCP maar aan staan. Dan zal de Mikrotik de enige zijn die de client is.

Hoe dan ook, ik wil eigenlijk gewoon root access

[Anoniem: 203842]

Ik weet het. Heb mijn (zakelijke) Ziggo modem ook in bridge modem willen hebben. Dat is op geen enkele manier mogelijk volgens Ziggo. Terwijl de modem voor consumenten lijnen wél binnen 10 minuten door de klantenservice in bridge mode gezet kan worden.


grrr......

[MrDikke]

Anoniem: 203842 schreef op dinsdag 10 januari 2017 @ 20:35:
Ik weet het. Heb mijn (zakelijke) Ziggo modem ook in bridge modem willen hebben. Dat is op geen enkele manier mogelijk volgens Ziggo. Terwijl de modem voor consumenten lijnen wél binnen 10 minuten door de klantenservice in bridge mode gezet kan worden.


grrr......

Geloof me, dit is in 99% van de gevallen gewoon mogelijk. Of ze het 'supporten' is het 2e verhaal. Of ze het dan daadwerkelijk nog (weten) te vertellen is al helemaal een andere koek.

[sig69]

Ik mijn eigen router gewoon in dmz gegooid achter de experiabox, zo was m'n overstap naar kpn het makkelijkst. Alles werkt, alleen vpn niet. Maar daar zijn ook al hele fora's over volgeschreven geloof ik. Heb verder geen zin om er tijd in te steken, ik doe het er maar mee.

[ Voor 14% gewijzigd door sig69 op 10-01-2017 21:19 ]

[MrDikke]

sig69 schreef op dinsdag 10 januari 2017 @ 21:17:
Ik mijn eigen router gewoon in dmz gegooid achter de experiabox, zo was m'n overstap naar kpn het makkelijkst. Alles werkt, alleen vpn niet. Maar daar zijn ook al hele fora's over volgeschreven geloof ik. Heb verder geen zin om er tijd in te steken, ik doe het er maar mee.

Kan, maar ik wil best wel die tijd er wel in steken voor root access. Misschien eigen firmware erop ofzo

[johnkeates]

Ik heb die OpenWRT pagina geschreven. Ding is op het moment nog niet gehackt, probleem is dat er nog geen bruikbare CFE is. Ik heb alle flash contents gedumpt, en een paar avondjes gespendeerd aan het decompileren van de CFE en mini_httpd, maar het is allemaal een karige bende. Ik heb z'n beetje alle experia boxen liggen, probleem is dat ze eigenlijk geen van allen bruikbare DSL chips hebben. De firmware is nagenoeg niet beschikbaar, en de paar binaries die er wel zijn gaan niet met nieuwe of custom firmware werken. De CFE zelf draait niet zomaar custom firmware (voor het geval je de EB's zonder DSL wil gebruiken), die moet dus vervangen worden, maar om dat te doen moet je eerst weten hoe de huidige CFE de hardware initialiseert, zodat dat met een vervangende CFE gedaan kan worden. Die kan je dan gewoon in de flash chip gooien en draaien maar.

Het apparaat kan je wel modificeren door de flash chip te dumpen, filesystem te extracten, bestanden aanpassen, weer inpakken, nieuwe checksum calculeren, en weer in de flash chip flashen. Maar dan nog kan je vrij weinig om dat het nogal oude firmware is. Op z'n best kan je DHCP uit zetten, de firewall uit zetten enz. TR069 uitzetten kan ook, en is in principe ook wel aan te raden om dat je anders het risico loopt op een update van KPN en dan werkt je hack niet meer.

Al met al kan je voor vrij weinig geld vergelijkbare hardware krijgen waar je wel gewoon standaard OpenWRT op kan draaien, en gezien je dan ook meteen goede langdurig ondersteunde en verkrijgbare hardware hebt is er ook meteen een stuk meer mee te doen.

Qua DSL ben je ook beter af met een simpel ATM/PTM-Ethernet adaptertje zoals de Vigor 120. De firmware voor de DSL chips is ranzig, werkt alleen op de huidig meegeleverde kernel+modules, en moeten in de DLS comm chips geladen worden na het opstarten om ze werkend te krijgen. De ATA chip is nog totaal onbekend qua aansturing, dus daar kan je met custom firmware al helemaal niks mee.

Stel dat je gewoon wil rondneuzen: dump de flash chip en ga je gang. Stel dat je in een live systeem wil kijken: er is geen bruikbare seriele console, niet in de CFE, niet in recovery en ook niet na boot. Je kan het wel via JTAG proberen, maar of dat nou praktisch is... Je kan ook directory listings enz. doen via een bug in de USB SMB server config UI, maar daar schiet je ook niet heel veel mee op.

[MrDikke]

johnkeates schreef op dinsdag 10 januari 2017 @ 23:01:
Ik heb die OpenWRT pagina geschreven. Ding is op het moment nog niet gehackt, probleem is dat er nog geen bruikbare CFE is. Ik heb alle flash contents gedumpt, en een paar avondjes gespendeerd aan het decompileren van de CFE en mini_httpd, maar het is allemaal een karige bende. Ik heb z'n beetje alle experia boxen liggen, probleem is dat ze eigenlijk geen van allen bruikbare DSL chips hebben. De firmware is nagenoeg niet beschikbaar, en de paar binaries die er wel zijn gaan niet met nieuwe of custom firmware werken. De CFE zelf draait niet zomaar custom firmware (voor het geval je de EB's zonder DSL wil gebruiken), die moet dus vervangen worden, maar om dat te doen moet je eerst weten hoe de huidige CFE de hardware initialiseert, zodat dat met een vervangende CFE gedaan kan worden. Die kan je dan gewoon in de flash chip gooien en draaien maar.

Het apparaat kan je wel modificeren door de flash chip te dumpen, filesystem te extracten, bestanden aanpassen, weer inpakken, nieuwe checksum calculeren, en weer in de flash chip flashen. Maar dan nog kan je vrij weinig om dat het nogal oude firmware is. Op z'n best kan je DHCP uit zetten, de firewall uit zetten enz. TR069 uitzetten kan ook, en is in principe ook wel aan te raden om dat je anders het risico loopt op een update van KPN en dan werkt je hack niet meer.

Al met al kan je voor vrij weinig geld vergelijkbare hardware krijgen waar je wel gewoon standaard OpenWRT op kan draaien, en gezien je dan ook meteen goede langdurig ondersteunde en verkrijgbare hardware hebt is er ook meteen een stuk meer mee te doen.

Qua DSL ben je ook beter af met een simpel ATM/PTM-Ethernet adaptertje zoals de Vigor 120. De firmware voor de DSL chips is ranzig, werkt alleen op de huidig meegeleverde kernel+modules, en moeten in de DLS comm chips geladen worden na het opstarten om ze werkend te krijgen. De ATA chip is nog totaal onbekend qua aansturing, dus daar kan je met custom firmware al helemaal niks mee.

Stel dat je gewoon wil rondneuzen: dump de flash chip en ga je gang. Stel dat je in een live systeem wil kijken: er is geen bruikbare seriele console, niet in de CFE, niet in recovery en ook niet na boot. Je kan het wel via JTAG proberen, maar of dat nou praktisch is... Je kan ook directory listings enz. doen via een bug in de USB SMB server config UI, maar daar schiet je ook niet heel veel mee op.

Ff wat reacties per alinea.
1. Ik neem aan dat je hier micro_httpd bedoeld (sneltyp foutje )? Verder snap ik het wel denk ik wat je hier zegt.

2. Dat gebeurt sowieso niet neem ik aan aangezien het modem dus afgeschreven is naar mening van kpn en ik ook niet meer bij kpn zit?

3. Dit is vrijtijdbesteding voor mij. Ik heb dat ding gratis. Dus minder kan het niet kosten. Al zou je met sommige EB's geld toe moeten krijgen. Ik noem verder geen namen. Kuch v8 kuch.

4. Niks over te zeggen

5. Ah, nou komen we ergens. Je wilt dus zeggen ookal crack ik de CFE auth, dat er eigenlijk niks bruikbaars achter zit? En heb je verdere info over die usb bug? Directory listings kan nooit kwaad.

[johnkeates]

Er zit inderdaad weinig bruikbaars achter. Je kan na de CFE auth wat firmware uploaden en that's it. Kan overigens ook via TFTP. Probleem is dat die ondertekend moet zijn, en ik heb geen tijd/zin gehad om die te reverse engineeren (als het tenminste niet asymmetrisch is). Het maakt ook weinig uit, want zonder serial console kom je nog nergens, en als de CFE die uit zet moet je de CFE dus vervangen, en als je de CFE vervangt ben je ook van het password probleem af... en dan heb je ook een serial console en daarmee dus ook toegang tot de embedded linux omgeving die er nu op draait.

Er staat wel een telnetd op maar ik heb geen duidelijke backdoor o.i.d. gevonden om hem aan te zetten. Een exec exploit is genoeg om het ding te starten, maar die ben ik nog niet tegen gekomen. DLNA was in oude versies te gebruiken, en HTTPD dus ook, maar in de huidige firmware allebei niet, of tenminste niet op een eenvoudige injectie methode.

De directory listing kon je via de web interface in de SMB/USB server module doen. Het is dezelfde bug als in de firmware van de fabrikant z'n eigen hardware/software, dus een vergelijkbaar modem/modelnummer had die bug en de EB dus ook. Ik ben even het type vergeten maar die heet ook iets van 220N.

[MrDikke]

johnkeates schreef op woensdag 11 januari 2017 @ 17:42:
Er zit inderdaad weinig bruikbaars achter. Je kan na de CFE auth wat firmware uploaden en that's it. Kan overigens ook via TFTP. Probleem is dat die ondertekend moet zijn, en ik heb geen tijd/zin gehad om die te reverse engineeren (als het tenminste niet asymmetrisch is). Het maakt ook weinig uit, want zonder serial console kom je nog nergens, en als de CFE die uit zet moet je de CFE dus vervangen, en als je de CFE vervangt ben je ook van het password probleem af... en dan heb je ook een serial console en daarmee dus ook toegang tot de embedded linux omgeving die er nu op draait.

Er staat wel een telnetd op maar ik heb geen duidelijke backdoor o.i.d. gevonden om hem aan te zetten. Een exec exploit is genoeg om het ding te starten, maar die ben ik nog niet tegen gekomen. DLNA was in oude versies te gebruiken, en HTTPD dus ook, maar in de huidige firmware allebei niet, of tenminste niet op een eenvoudige injectie methode.

De directory listing kon je via de web interface in de SMB/USB server module doen. Het is dezelfde bug als in de firmware van de fabrikant z'n eigen hardware/software, dus een vergelijkbaar modem/modelnummer had die bug en de EB dus ook. Ik ben even het type vergeten maar die heet ook iets van 220N.

Vanuit achter de CFE moet je toch iets kunnen vinden voor de telnet?

[johnkeates]

MrDikke schreef op woensdag 11 januari 2017 @ 21:19:
[...]

Vanuit achter de CFE moet je toch iets kunnen vinden voor de telnet?

Nee, de CFE heeft helemaal niks. De HTTP console is alleen voor het uploaden van firmware, en de serial console staat uit.

[johnkeates]

Hier is een ruwe bende aan HTML die in de CFE zit: https://ufile.io/556b5
Ik weet niet precies welke ik er een beetje schoon uit gekregen heb, waarschijnlijk is het alleen vanaf de header afgeknipt en zit er nog een rommeltje achter de footer met de rest van de flash chip.

Oh. Dit is de CFE: https://ufile.io/bcd75

Er zitten twee flash chips op, en de CFE heeft een JFFS ergens waar die HTTP interface op draait in recovery. Eigenlijk is er dus de 'echte' CFE, en een embedded RTOS-achtige HTTP server die in recovery mode vanaf de CFE direct geladen wordt zonder Linux o.i.d.

RootFS van de bovenste Flash Chip: https://ufile.io/79274

Volgens mij is dat de normale boot chip, en de onderste voor CFE, recovery en non-upgraded runtime code.

[ Voor 48% gewijzigd door johnkeates op 11-01-2017 22:29 ]

[MrDikke]

johnkeates schreef op woensdag 11 januari 2017 @ 22:21:
Hier is een ruwe bende aan HTML die in de CFE zit: https://ufile.io/556b5
Ik weet niet precies welke ik er een beetje schoon uit gekregen heb, waarschijnlijk is het alleen vanaf de header afgeknipt en zit er nog een rommeltje achter de footer met de rest van de flash chip.

Oh. Dit is de CFE: https://ufile.io/bcd75

Er zitten twee flash chips op, en de CFE heeft een JFFS ergens waar die HTTP interface op draait in recovery. Eigenlijk is er dus de 'echte' CFE, en een embedded RTOS-achtige HTTP server die in recovery mode vanaf de CFE direct geladen wordt zonder Linux o.i.d.

RootFS van de bovenste Flash Chip: https://ufile.io/79274

Volgens mij is dat de normale boot chip, en de onderste voor CFE, recovery en non-upgraded runtime code.

Hoe heb je dit verkregen als ik het vragen mag? En er moet toch iets zijn waar we wat meer aan hebben?

Oja, en heb je dit al eens gezien: https://github.com/lymon66/ZTE_H368N-rootfs ? Sounds interesting to me...

[ Voor 5% gewijzigd door MrDikke op 12-01-2017 15:35 ]

[johnkeates]

Je haalt de EB uit elkaar, soldeert de flash chips er af, hangt hem aan een SPI bus, en leest ze uit, bijv. met flashrom. Je kan dan bijv. ook gemodificeerde software terugflashen en dan de chip weer op z'n plek solderen en dan draait de EB dus in theorie gemodificeerde software. Probleem is dat je de checksums goed moet krijgen om dat de CFE anders in recovery start en een herinstallatie doet.

MrDikke schreef op donderdag 12 januari 2017 @ 15:32:
[...]
Oja, en heb je dit al eens gezien: https://github.com/lymon66/ZTE_H368N-rootfs ? Sounds interesting to me...

Dat zijn inderdaad de upper en lower flash dumps van de chips.

[ Voor 27% gewijzigd door johnkeates op 12-01-2017 16:10 ]

[MrDikke]

johnkeates schreef op donderdag 12 januari 2017 @ 16:08:
Je haalt de EB uit elkaar, soldeert de flash chips er af, hangt hem aan een SPI bus, en leest ze uit, bijv. met flashrom. Je kan dan bijv. ook gemodificeerde software terugflashen en dan de chip weer op z'n plek solderen en dan draait de EB dus in theorie gemodificeerde software. Probleem is dat je de checksums goed moet krijgen om dat de CFE anders in recovery start en een herinstallatie doet.


[...]


Dat zijn inderdaad de upper en lower flash dumps van de chips.

Heb je ooit iets gevonden over de BusyBox die ook duidelijk in de GitHub staat? Zitten wel vulnerablities in, https://www.exploit-db.com/exploits/28595/

[johnkeates]

MrDikke schreef op vrijdag 13 januari 2017 @ 17:26:
[...]

Heb je ooit iets gevonden over de BusyBox die ook duidelijk in de GitHub staat? Zitten wel vulnerablities in, https://www.exploit-db.com/exploits/28595/

Dat is de bug die dus misbruikt wordt voor directory traversal in de SMB/USB interface.

[MrDikke]

johnkeates schreef op vrijdag 13 januari 2017 @ 18:08:
[...]


Dat is de bug die dus misbruikt wordt voor directory traversal in de SMB/USB interface.

Ik wil eigenlijk toch wel wat vinden.

- CFE cracking heeft geen zin.
- Er lijkt geen seriele console duidelijk zichtbaar te zijn
- Telnet lijkt niet openbaar
- HTTP Auth lijkt een degelijke

Welke opties hebben we/heb ik nog?

[johnkeates]

MrDikke schreef op vrijdag 13 januari 2017 @ 20:01:
[...]

Ik wil eigenlijk toch wel wat vinden.

- CFE cracking heeft geen zin.
- Er lijkt geen seriele console duidelijk zichtbaar te zijn
- Telnet lijkt niet openbaar
- HTTP Auth lijkt een degelijke

Welke opties hebben we/heb ik nog?

CFE reverse-engineeren en een compatible CFE flashen die wel goed werkt. Het OS enz. zijn allemaal niet zo spannend. Zonder goede CFE is het ding niet echt bruikbaar. HTTP auth kraken helpt ook niks, het kan wel, maar dan nog kom je nergens. Het punt is niet dat het 'veilig' of 'secure' is, ze hebben gewoon nagenoeg alles uit de firmware en CFE gesloopt zodat er niks te hacken valt.

[MrDikke]

johnkeates schreef op vrijdag 13 januari 2017 @ 20:14:
[...]


CFE reverse-engineeren en een compatible CFE flashen die wel goed werkt. Het OS enz. zijn allemaal niet zo spannend. Zonder goede CFE is het ding niet echt bruikbaar. HTTP auth kraken helpt ook niks, het kan wel, maar dan nog kom je nergens. Het punt is niet dat het 'veilig' of 'secure' is, ze hebben gewoon nagenoeg alles uit de firmware en CFE gesloopt zodat er niks te hacken valt.

Ik zou het wel willen doen, maar heb geen idee hoe of waar te beginnen....

Zou je me in een richting kunnen wijzen hoe dit te doen of een tutorial? Ik ben compleet nieuw hiermee!

[ Voor 8% gewijzigd door MrDikke op 14-01-2017 22:01 ]

[MrDikke]

Aangezien ik niet echt een beter idee heb hoe ver te gaan, ben ik zelf maar wat gaan aanklooien.

Zie hier het resultaat:
http://pastebin.com/JSgez4Xi

Het is de file die @johnkeates eerder stuurde (de cfe-bin) waarvan ik de main HTML component helemaal heb doorgespit naar mogelijke informatie.

Er staat iets in over een BOOT_CONSOLE. Mogelijk nog nuttig.

Verder hoop ik echt op extra input!