Skip to main content

Posts

Showing posts with the label firmware

Jay-Tech (JTC) TV Android hacks

Back in January I bought a cheap 55" TV, mainly to use as a low-latency monitor. On a random note, I haven't watched TV in years, all my TVs have been used as monitors in the past 10+ years. The model is  UHD SMART TV S55U5515MQ  and uses a dual-core running at 1.2GHz with 1.5GB RAM. It's running a version of Android TV 6.0. I think a very similar set is with a model name of Genesis, distributed by the same company - Jay-Tech. Was not expecting much for the price but it does a decent job as a monitor, with relatively low latency and relatively good resolution support. However the software on it is quite bad, even wrote the company to ask some questions but never heard back from them: there is no color calibration, even though it has a green tint from the factory there are YouTube notifications of new videos when the TV connects to a network, even with no account set up could not find a way to save the program list on USB as listed in the manual there's a Home and a Sta

Blinds/Shutters automation with Home Assistant

My apartment has the shutters/blinds controlled via a trio of wall-mounted button panels. Here's my experience of integrating them into Home Assistant for automation and remote control. Steps: Identify the control units Buy the remote unit or reverse engineer the control signals Build a firmware for NodeMCU (ESP8266) based on ESPHome Result I've kept the intrusion to a minimum so they can be reverted without any traces: Home-Assistant panel with the three blinds actions: Control Unit The button panels have Elero stamped on them so the first thing was to go to the manufacturer's website and search for a product:  https://www.elero.de/de/produkte/jalousiesteuerungen/ The closest match seemed to be Elero VarioTec, not sure at this point if it supports remote control or not (spoiler: it doesn't).

FiberHome AN5506-02-F router hack

I recently had to work with a home fiber router that was supplied by the ISP,  the FiberHome AN5506-02-F. Compared to the previous internet access solution, which was based on a cable modem and required the user to use their own router, the new solution has both advantages and disadvantages. The advantages would be: integrated WiFi, security and firewall. The disadvantages: only one LAN port available (@100Mbps), only 2.4GHz (@150Mbps), outdated software, locked-down interface, no easy way to expose a second router. The unit is very similar to the AN5506-04 model (  http://flytec.com.py/download/files/AN5506-04F-manual.pdf ), except it has only 2 UTP ports, only 1 phone port and no CATV interface. Exposing the inner router To get around the issue of the (old) router not being accessible from outside, the solution is to add that router into the DMZ setting. This is needed for things like web hosting, ftp server, some chat clients, torrents, etc. You can log in with your supp

Porting OpenWRT to ionik Wifi Cloud Hub

I will probably have to split this article into several parts, as I move along. In the initial article (see  http://hackcorrelation.blogspot.de/2017/01/ionik-cloud-hub.html ) I took a look at the hardware and started doing some basic hacking. However, I quickly ran into limitations and decided to try and port OpenWRT for the platform. There are quite a few steps and preparations needed to do this, however, this is for documentary purposes only. You don't need to do any of the stuff below (except backup), you can just flash my OpenWRT firmware and be none the wiser. However it might be useful if you want to port it to a new device, I could not find any tutorial about this. Step 0 - BACKUP In case everything blows up you will want to be able to restore everything to the factory condition. I first reset the root password to 'admin' by going to this link: http://10.10.10.254:8000/goform/SystemCommand?command=%2Fsbin%2Fchpasswd.sh+root+admin&SystemCommandSubmit=App

Designing a better diesel tuning box - part 5 - tweaks and updates

Living close to a densely populated area means that it's hard to do consistent testing without spending a lot of fuel, which is also expensive. Nevertheless, I took the pen&paper approach and started working my way from the basics. I studied all the Bosch sensors from this page , used a bit of common sense and figured out that my sensor is a Bosch 0281002691, or similar, with a 180 MPa (26000 psi) nominal rating. This might be wrong but It's a good place to start. I've already used Torque and my multimeter to get some data and it seems to fit with the sensor I've chosen. It might be wrong, but so far it clicks into place. Using the data I've gathered I've created a simple JS page that shows some logs and tries to simulate what my module (and sensor) does: https://jsbin.com/goyavabuju/edit?html,output (Note that this is the HTML/JS result after I did the interpolation.) So the basic function is: the ECU commands the pump, this delivers a pressure

i.onik Cloud Hub

I bought one of these cheap 'wireless drives' from Amazon:  https://www.amazon.de/I-ONIK-70752-i-onik-WIFI-Cloud/dp/B00I16C1K2/ Currently (early 2017) selling for 15E, I think I paid 12E including shipping. This post will focus on basic features and some early data. Later posts will go into some reverse-engineering, featuring a great YouTuber, LiveOverFlow . If you like reverse-engineering you will surely enjoy his tutorials. By the time you read this he will have probably published his first video showing you how to get into the device. He also discovered that a very similar device is being sold under the Strontium Mobile Wifi Cloud (Sri-CUBa-3KW) moniker in US and India. However that one is advertised as having a 3000mAh battery while this one only has a 1900mAh one. Edit The excelent video from  LiveOverFlow  is up:  https://www.youtube.com/watch?v=FxE2ITDWsNE

Designing a better diesel tuning box - part 3 - simplified design results

As I wrote in the previous article , the barebones design has been through some basic testing - 500km mixed environment driving - and has been mostly successful so far. I had a suspicion that the output impedance of the circuit must somehow match a known impedance, but was not sure which. The clue was that the RaceChip unit raised city consumption by 5-15% even though it had no effect during the bench testing. Here's a datasheet for a similar Bosch pressure sensor: http://rb-aa.bosch.com/boaasocs/index.jsp;jsessionid=A20738712FCFB9E51CA919DD7D2F9E91.sundoro2?ccat_id=275&prod_id=516 For testing they are using a pull-up resistor, so on the input side of the ADC the same circuit must be simulated in order to drive the sensor. I used a 10k resistor, but perhaps even the internal pull-up could work. At the DAC/PWM output I found out that a 1.5k resistor was too large and could not sink the ECU input line low enough. With a 10ohm resistor it seemed to work fine, perhaps 47oh

Racechip tuning box - part 2 - reverse engineering

See my first article for a short review and teardown: http://hackcorrelation.blogspot.de/2016/02/inside-stuff-racechip-car-tuning-thingie.html First off let me start by saying I consider this fair use, as the instructions and website do not explain what the settings do, how the unit actually functions and what effects it can have. The description below refers to a single-channel Diesel engine (single common rail). Settings First off, most of the users will just want the simple explanations, here's a graph that should be in the manual: The chart above shows 4 possible settings and their effects. The first rotary encoder controls how much 'extra power' is requested. See 9E vs. BE vs. 4E The second rotary encoder controls the RPM high range (endpoint). See BE vs B7. The encoders go from 8 (minimum) through 9, A, B, C, ..., F, 0, 1 ... 7 (maximum).

Toshiba 32TL868 LED 3D TV teardown

See last Toshiba posts for firmware reverse-engineering analysis. TL;DR version: it would take too long to come up with a useful firmware mod. I'm missing the toolchain, complete source code, compilation instructions, libraries, hardware architecture, ... In the meantime, I did take the TV apart to fix a broken stand-off.

Toshiba Regza TL868 firmware analysis

My TV has a quite complex set of features, none of which work particularly well. Except perhaps using it as a PC display. Input latency is quite bad, ranging from over 200ms in normal mode to 100ms in "gaming" mode. The latency can easily be tested by going to this link and making a picture of both displays (native and external) at the same time, preferably with a flash, in order to shorten exposure time. There's a half-assed [HBBTV] implementation that crashes once in a while, a horrible YouTube app that takes 1-2 seconds to react to keypresses, a barely-workable DLNA implementation and barely-acceptable USB media integration. Oh, it also does triple-tuner TV, but I don't watch TV. Sometimes I'm just wishing they would have stuck with a Linux, WinCE or Android implementation with freeware apps instead of reinventing the square wheel each time. What's worse, each of these apps (TV, DLNA, HBBTV, YouTube, USB media) seems to be written by a diff

txtr Beagle - native code analysis

I've been avoiding to do a write-up on this section for several reasons. First, I'm using the IDA disassembler which is pretty expensive and thus quite extensively pirated. Unfortunately there are no freely available tools that I know of that can perform this task. Second, I really suck at assembler and C so might not be the best person to do these analysis. I've used the freely available Thumb decompiler plugin which is able to translate assembly into readable code but only in about 30% of the cases. There's no substitute for knowledge, it seems. Part 1:  http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-teardown-part-1.html Part 2:  http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-part-two-software.html Part 3:  http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-part-3-storage-and-transfer.html Part 4:  http://hackcorellation.blogspot.de/2013/07/txtr-beagle-card-parser.html Part 5:  http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-na