Trying to Tasmotize Ubibot WS1

[DzzD]

Hello there !

I try to Tasmotize Ubibot WS1 but failed, I am noob on Tasmota and I would probably need some help...

Here is the device :

https://www.ubibot.com/fr/ubibot-ws1/

One good thing is that it does not require to be opened to be flashed, it is delivered with an USB cable (USB<=>microUSB) wich is inside the box a serial connection, so saving & flashing it just require to connect it to a computer with the given USB cable or any other microUSB cable.

By analysing the network I was able to see it was an ESPxxx (it was on the header of request it made to server)

POST /update.json?execute=true&metadata=true&api_key=xxxxxxx&firmware=ws1a_v2.1.8&ssid_base64=xxxxx== HTTP/1.1
User-Agent: ESP32 HTTP Client/1.0
Host: api.ubibot.io
Content-Type: application/json
Content-Length: 512

What I did :
1 - backup the firmware using esptoolv4.4 on command line (I did three... 2MB/4MB/8MB backup as at first I did not knew its capacity, now I know it is 4MB
2 - I flashed it with web Tasmotizer
3 - I tried the "how todo for unknow device" : https://tasmota.github.io/docs/Configuration-Procedure-for-New-Devices/#step-2 (ESP32)
4 - I found some interresting informations :
=> GPIO 15 activate a relay inside (I can heard a little click) => configured as Relay
=> GPIO 18 lights up green LED => configured as relay
=> GPIO 19 lights up red LED => configured as relay
=> GPIO 22 seems to activate a relay inside (I can heard a little click) => configured as Relay
=> GPIO 32 give ADC value => configured as ADC Input
=> GPIO 33 give ADC value => configured as ADC Input
=> GPIO 36 give ADC value => configured as ADC Input
=> GPIO 37 give ADC value => configured as ADC Input

I tried to configure Tasmota template but never succeed.

Here are my problems :
1 - values given by ADC are meaningless, they probably need a linear conversion (AX+B), but I dont know if it is possible in tasmota
2 - I can activate on GUI relay 18/19 etc... only if I let all GPIO as relay, or at least It requiere 18 GPIOs or more as relay if I want to have access to the GUI button 18 on tasmota, If I only put 18 & 19 as relay I got two buttons but they dont activate GPIO 18 & 19, something I am missing here

Any help would be welcome !

Last thing, I was able to restore the original firmware with esptoolv4.4 on command line only, the ESP Flasher did not work and it throw an error, anyway I can reflash it with Tasmota do to new tests if needed without any risk as I know now I can re-flash with original firmware and it works again.

EDIT:

For better understanding here is what the WS1 sensors are (6 sensors) :

[sfromis]

While you may see something when configuring gpio 32,33,36,37 as analog, that does not mean that you get any useful function if they are not actually connected to analog sources.

Internal temperature/humidity would often be either an I2C device, or some one-wire device like DHT22, both cases needing pin configs to match.
Looks like the external sensor (in the freezer?) is DS18B20, again a specific pin config is needed.
Ambient light could easily be an analog LDR, Tasmota does have a pin config for that.
Voltage is likely an internal analog value. RSSI is just the signal strength, not a "sensor" as such.

It could save a lot of guesswork with a good peek inside the box.....

[DzzD]

It could save a lot of guesswork with a good peek inside the box.....

Sorry, I was too lazy to unscrew the four screws, I did it and managed to find an angle so the component references are visible on the picture, there is nothing on the back side of the IC

I'll try better picture & search for wich sensor it could be, but I am more concerned by how Tasmota handle template, why if I only set GPIO18 as relay and anything else to none it does not work ? if I put more than 18 relay I got 18 buttons and then the 18 button works

[sfromis]

The temp/hum sensor is U6, bottom right corner in the image in the small cutout, I think that it says SHT30, which is fairly decent I2C sensor, meaning that there has to be an I2C bus, two pins SCL/SDA. Assuming that I read SHT30 correct, SDA should be pin 1, corner pin where the dot is, and SDA should be pin 4, the other corner, same upper side. If you have a multimeter, you could check what they connect to on the ESP32, if anything.

However, as the 24CD8RP 8-pin IC left of it has a "ST" logo, it may be a STM MCU, making things "more complex", have no guess what may be happening there.

The PCF8563 next left should be a real time clock chip, I don't think that it is supported by Tasmota, but that may not be so bad, as Tasmota generally updates clock via a NTP server from the network. The NXP PCF8563 is also an I2C chip, most likely on the same SDA/SCL as the sensor.

I suspect (not very sure) that the encircled component top left in the image may be a light sensor, which plausibly may be analog input to some pin, traceable, or you could experiment with what analog value changes when you make it light/dark.

The DS18B20 should have a connector where you plug it in, which generally would be 3 pins, power/ground/data, where the data pin should be connected to the ESP32. Possibly also the power pin, as some devices use the "trick" of using a gpio to power a sensor.

Not clear what exactly you are doing with gpio 18 and 18 relays. Details matter a lot.

[barbudor]

It's not 24CD08 but 24C08, an I2C EEPROM 1KByte https://www.st.com/resource/en/datasheet/m24c08-r.pdf
I'm surprised that there are 2 flash chips : a 25Q32 (4KB) and 25Q128 (16KB)
I see a possible light sensor on the top left
and 2 chips I wonder what they are :

• 1 on the left botton,
• 1 on top right close to the inductance or transformer, so could be part of a DC/DC converter for the battery PSU

[sfromis]

The left bottom component is repeated near the PCF8563, and having it twice could suggest that it is less of a case of a key function of the device, more something to make the electronics work. SMD, two poles are usually not the "more interesting" stuff. Looks like the designator is "V" (Vacuum tube???") or "Y" which should be "Crystal or oscillator", which still looks "surprising", as there is also what looks a lot like a crystal above the ESP32.

[DzzD]

Thanks, to be honest, at first I was really thinking that Tasmota was a making everything a lot easier, sometime I think it may be easier to rebuild all the circuit & program an ESP than configuring Tasmota for such device.

You are right for the light sensor, it is where the enclosing case is open and where the light is captured.

The 18&19 pin light up two LED (green/red) at the bottom right of the circuit.

I will continue, but I have a lot to learn on Tasmota, but I like to learn. there are tons of things I still dont understand.

[sfromis]

I do not think that it would be any easier to program things yourself, configuring Tasmota should be pretty simple, after you've worked out what gpio are used for what, as long as you focus on the straightforward functions. Of course, if you build your own circuit, you know where the pins are, and then it is even easier to config Tasmota for that 😉

[DzzD]

ps: I tried to heat, light, etc... and do everything to see change on analog inputs returning a value I found but they never changed.

[DzzD]

Would be really nice to have a little program to flash ESP that will do a first analysis/diagnostic, testing different pins input/output etc...

Dont know if it will go anywhere but...

[DzzD]

I wrote a I2c scanner but unfortunatly it did not find anything, not surprising as I already find that pin 22 is linked to a relay so it is not used for the I2c I suppose, I need to find wich pins on the ESP is used for the I2C bus, using the sensor SHT30 may help but I need a better zoom... My phone may not be enought.

[DzzD]

This make me think of a very old dev I did to hack a game back in 1992 or so ! the game was asking to click on three or four symbols different at each start, those symbols was in the paper manual, I cant remember the game name, the solution I found was to wrote a mouse driver that was doing all the possible solution automatically, it was working nice and requiered between 1 to 5 minute to start the game :)

All that to said that knowing there is a know I2C chip as you mentioned SHT-30, I could try to make a test on every pins pair possibilities targeting its known adresses 0x44, that should give me the pin to use for the I2C and maybe I will found other device on it.

I should limit this to authorized pins for I2C wich I dont know, but even testing all pins should not take too long

34 i/o give 561 combination wich requiere to be tested in both sens, so 1122 tests maybe twice for targeting the two possible adresses

-
The SHT-30 Mesh-protected Weather-proof Temperature/Humidity Sensor is pretty much the same as the SHT-31 PCB product which has an ADDR pin on the PCB which can be pulled high changing the default 0x44 i2c address to 0x45
-

I would find this very fun if it work, but I doubt, let's try ! really that just for the fun, it would cost me a lot less buying another device compatible :) :)

[DzzD]

Well after two hours of programming It seems that I got some good results :), trying all possible clock and pins for the specific adress 0x44 found something !

Begin test at 10000Hz
1 - 2 => disabled
2 - 1 => disabled
1 - 3 => disabled
3 - 1 => disabled
1 - 4 => disabled
4 - 1 => disabled
1 - 5 => disabled
5 - 1 => disabled
1 - 6 => disabled
6 - 1 => disabled
1 - 7 => disabled
7 - 1 => disabled
1 - 8 => disabled
8 - 1 => disabled
1 - 9 => disabled
9 - 1 => disabled
1 - 10 => disabled
10 - 1 => disabled
1 - 11 => disabled
11 - 1 => disabled
1 - 12 => disabled
12 - 1 => disabled
etc...
etc...
1 - 34 => disabled
34 - 1 => disabled
2 - 3 => not found
3 - 2 => not found
2 - 4 => not found
4 - 2 => not found
2 - 5 => not found
5 - 2 => not found
2 - 6 => disabled
6 - 2 => disabled
2 - 7 => disabled
7 - 2 => disabled
2 - 8 => disabled
8 - 2 => disabled
2 - 9 => not found
9 - 2 => not found
2 - 10 => not found
10 - 2 => not found
2 - 11 => disabled
11 - 2 => disabled
etc...
etc...
24 - 14 => disabled
14 - 25 => disabled
25 - 14 => disabled
14 - 26 => disabled
26 - 14 => disabled
14 - 27 => not found
27 - 14 => found !
Device found !
pin 27
pin 14

It took about a minute, I will try now if I can read something with those pins (just testing 0x44 adressess)

[DzzD]

Side note : the box is making terrible noize while scanning !! :)

[DzzD]

Well, I managed to read temperature and humidity but values seems a little out of what they should be, not that much but not good, I took other picture an you was right it is a SHT30, I used two different libraries to read values but they seems not that good, like temperature say 29 where it is rather 20 and humidity is 19 where it should be 40/50, I read the raw value and use the datasheet to convert but no surprise same result

Anyway the scanner works !

So now I can (nearly):
Lite de red LED
Lite the gree LED
Read temperature of inside sensor
Read Humidity of inside sensor
Activate some relay that I dont know what they do :)
For the outside Sensor it is pluged on the serial interface that may help
Not too bad but so many time....

I miss the light detector
and why there are at least two relay that do something I dont know...

[DzzD]

Well, I will stop here for this one, it was fun, but it took unfortunately too much time, also I have a couple easier solution :

• dns spoofing for reading what it send to server (no SSL), already tried this, it works
• use another ESP to communiat via serial, as the box allow ro read data via serial port by sending simple commands
• use the custom homeassistant component ubibot, wich use the cloud (what I did not wanted too at first)

thanks @sfromis for all your good advices

I still not understand why they made such complicated, the box look like over-engineered for what it is doing.

I suppose that is because it is supposed to work without internet and store the datas internally (for long period)until it get internet connection back, this may explain why they need their own clock.

Also it can be powered by two AA batteries ans last for monthes.

Anyway I flashed it back to original firmware and it still work, seems I did not broke anything :)

[DzzD]

Just in case of here is my draft I2C scnaner :

To start :

• set targetAddress = 0x44;
• enable all pins by setting in scanI2PinEnabled[] the index value at array index, when one fail or reboot, set the entry to -1 to disable the GPIOi

NB: it could be easily extended to test all 127 adresses, it does not take that long, I may try to continu to work on this project if there is any interest on doing so...

#include <Arduino.h>
#include <driver/adc.h>
#include <Wire.h>

int scanI2PinEnabled[] = {-1,-1,2,3,4,5,-1,-1,-1,9,10,-1,12,13,14,15,16,17,18,19,-1,21,22,23,-1,-1,-1,27,-1,-1,-1,-1,32,33,-1};
uint32_t I2CSpeeds[] = {10000, 100000, 400000, 1000000};

boolean testI2C(int pin1 , int pin2, int address, int clock) //pin1 = SDA, pin2 = SCL
{
  Serial.print(pin1);
  Serial.print(" - ");
  Serial.print(pin2);
  if(scanI2PinEnabled[pin1] != pin1 || scanI2PinEnabled[pin2] != pin2)
  {
    Serial.println(" => disabled");
    return false;
  }
  
  Wire.begin(pin1, pin2);
  Wire.setClock(clock);
  Wire.beginTransmission(address);
  int error = Wire.endTransmission(true);
  Wire.end();
  if( error == 0 || error == 1 )
  {
    Serial.print(" => found ! code=");
    Serial.println(error);
    /* Do other testing stuff here 
      readSensorSHT(pin1, pin2, address, clock);
    */
    return true;
  }
  Serial.println(" => not found");
  return false;
}

void loop() 
{
  int targetAddress = 0x44;
  for(byte i = 0; i < 4; i++)
  {
    int clock = I2CSpeeds[i];
    int pinMin = 1;
    int pinMax = 34;
    int testCount = 0;
    Serial.print("Begin test at ");
    Serial.print(clock);
    Serial.println("Hz");
    for(int pin1 = pinMin; pin1 <= pinMax; pin1++)
    {
      for(int pin2 = pin1 + 1; pin2 <= pinMax; pin2++)
      {
        if(testI2C(pin1, pin2, targetAddress, clock))
        {
          Serial.println("Device found !");
          Serial.println(pin1);
          Serial.println(pin2);
          delay(10000);

        }
        if(testI2C(pin2, pin1, targetAddress, clock))
        {
          Serial.println("Device found !");
          Serial.println(pin2);
          Serial.println(pin1);
          delay(10000);
        }

        testCount++;
      }
    }
    Serial.println(testCount);
  }
}

[DzzD]

Is someone find this thread here some info, @sfromis I copied your version and embed new info to it.

And some references :

ESP32-D0WDQ6-V3 : Wifi + arduino

• https://www.mouser.fr/ProductDetail/Espressif-Systems/ESP32-D0WDQ6-V3?qs=GBLSl2Akirt8fvUVSeeceA%3D%3D

SHT30 : Temp/Huminidy sensor

• https://www.mouser.com/datasheet/2/682/Sensirion_Humidity_Sensors_SHT3x_Datasheet_digital-971521.pdf

BDR : Probably power transistor/relay

• https://www.ebay.com.au/itm/230821333068
• https://my.rs-online.com/web/p/power-switch-ics/1330737

CH340C : USB to UART/Serial

• https://www.mpja.com/download/35227cpdata.pdf

PCF8563 : Real time clock

• https://www.nxp.com/docs/en/data-sheet/PCF8563.pdf

6R8 : Coil

• https://www.tme.eu/en/details/djnr8040-6r8/smd-power-inductors/ferrocore/

A202L : maybe sensor or power/voltage regulator but strange case... ?
=> cant remember where I found information on this one

More info :

• the SHT30 seems linked to non standard I2C, should use pin 27 & 14 with addr 0x44 (not sure you can use scanner above to find it)
• external temperature sensor is a DS18B20 that is plugged on the USB port, so it may use ESP TX/RX, not tested (https://www.analog.com/en/products/ds18b20.html )
• I tried two libraries to read SHT30, both works even if readen values seems a bit far from reality (Adafruit_SHT31.h and SHT31.h)
• red and green LED can be lighten up by writing to GPIO 25 & 26

[DzzD]

Wait wait I got a strange idea...

They say that their temperature sensor range from -20 to +60 °C but the SHT30 range from -40 to 125 °C

Ubibto say : https://www.ubibot.com/fr/ubibot-ws1/

SHT30 say : https://sensirion.com/products/catalog/SHT30-DIS-F/

I wonder if divided by 2 the temperatures does not become good one

[sfromis]

That would be odd, but I don't know what happens around that SHT30, it should just provide values right away, as long as the driver code is correct. Did you try with the SHT30 support in Tasmota?

What do you mean by "non standard I2C"? There are no "standard" I2C pins on ESP32.

[DzzD]

I started another project from scratch, now using 10000Hz and pin 27/14 for I2C, now temperature looks good ?!, but not humidity, I also got the correct date & time from the realtime clock PCF8563

[DzzD]

arf.. I cant stop...

I manage to talk to the realtime clock using the I2C pins I found with the scanner, it requiered me to update the library for this device PCF8563

• Datasheet : https://www.nxp.com/docs/en/data-sheet/PCF8563.pdf
• Library : https://github.com/elpaso/Rtc_Pcf8563

I just needed to change the constructor that was using default pins :

Initial :

Rtc_Pcf8563::Rtc_Pcf8563(void)
{
    Wire.begin();
    Rtcc_Addr = RTCC_R>>1;
}

Modified :

Rtc_Pcf8563::Rtc_Pcf8563(void)
{
    Wire.begin();
    Rtcc_Addr = RTCC_R>>1;
}

Rtc_Pcf8563::Rtc_Pcf8563(int sdaPin, int sdlPin)
{
    Wire.begin(sdaPin, sdlPin);
    Rtcc_Addr = RTCC_R>>1;
}

And that's work like a charm !

Time: 18:07:10   Date: 12/11/2022
Time: 18:07:11   Date: 12/11/2022
Time: 18:07:12   Date: 12/11/2022
Time: 18:07:13   Date: 12/11/2022
Time: 18:07:14   Date: 12/11/2022
Time: 18:07:15   Date: 12/11/2022
....
....

[DzzD]

Well at the end I will have made my full Ubibot library ^^

void loop()
{
  
  setLED(LED_RED, LED_ON);
  readUbbWS1Clock();
  setLED(LED_RED, LED_OFF);

  setLED(LED_GREEN, LED_ON);
  readUbbWS1TemperatureHumidity();
  setLED(LED_GREEN, LED_OFF);

  Serial.println();
  delay(1000);
}

Date: 12/11/2022
Time: 19:35:30
Temp = 22.6°c
Hum = 29.1%

Date: 12/11/2022
Time: 19:35:31
Temp = 22.7°c
Hum = 29.1%
...
...

With LED flashing :)

Temperature looks good now, but humidity is as far I know in my house a little too low, should be at least 35/40%

[DzzD]

pretty funny, they offer developper membership for only 5000$ !!!!
https://store.ubibot.com/en-fr/products/ubibot-developer-membership

[DzzD]

Well now let's try to find the DS18B20 sensor, as it is pluged in the USB I suppose it should past by the CH340C ? and so may be linked to an UART pin ?? dont know

[DzzD]

It doesn't make any sense, but I want to finish to hack this stuff..., any idea or help would be welcome.

Ho and sorry, I forgot to thank you @barbudor for your first analizies/image for the IC.

Anyway, I'have got an idea that I need to confirm, there is a relay, (probably the BDR stuff), I know it is a relay because I can heard it when playing with pin 22 down & up (click), after thinking about it, I now make the assumption that it is to shut of power of a part of the IC to maintain power batterie life.

This thing is made to get measurment every 10 to 30 miniutes, and it is supposed to work with two AA batterie for more than 4 monthes.

For the EEPROM, it does store all measurments offline, so there is no lost even when it is not connected to internet, I dont see any other reason for those memory chips

One "big" problem I got is with the One Wire external prob DS18B20, it is connected to the same USB than the power or the PC, I can figure out what it become inside the borad, It is pretty sure that it goes throught the inside UART converter but then ?

[sfromis]

If you have those "clicks", that might speculatively be to switch the USB plug between USB usage and sensor usage. Anyway, I've not been deep into the CH340C specs, if it is able to do some sort of pass-through....

[DzzD]

If you have those "clicks", that might speculatively be to switch the USB plug between USB usage and sensor usage. Anyway, I've not been deep into the CH340C specs, if it is able to do some sort of pass-through....

for the relay I tried to switch it on and off, Serial was still available, it does not seems to be that, I also try Serial2, nothing on it and as far as I understand the spec, the CH340C provide only one UART

[DzzD]

We have identified all circuit, there are nothing back side and the last big black box at the upper right should be the buzzer (yes there is a buzzer), so I should be able to find everything :(

[sfromis]

Next step could be a logic analyzer (can be very cheap) while the board is in operation....

[DzzD]

Next step could be a logic analyzer (can be very cheap) while the board is in operation....

There are no probe point, and circuits are so tiny that I cannot touch anything without the risk of shortcircuit something, at least I managed to read the PIN A2 of the EEPROM. This have give me the ability to write a little dump program of it, but I did not understand any data of it for now.

EDIT: the ESP32 chip itself is 6mm x 6mm

[DzzD]

Some news of today 👍

Here is the I2C analyse (from 0 to 127) :
Found device at 0x0
Found device at 0x44
Found device at 0x51
Found device at 0x53
Found device at 0x54
Found device at 0x55
Found device at 0x56
Found device at 0x57

SDA is on GPIO27
SDL in on GPIO14

0x0 seems to be reserved for broadcasting
0x44 is the SHT30 temp/hum => working well
0x51 is the PCF8563 Realtime Clock =>working well
0x54 is the EEPROM => seems to works but I did not understand everything not sure it does not also use the following addresses : 0x55 0x56 0x57 (this will make 4 banks of 256 byte with one byte for memory adressing)

0x53 => dont know what it is

I need to read thoses flash memories too.

I wonder what 1KB EEPROM and 20KB Flash can be used for and also why there is those flash memory, supposely to store measure when offline ? they say they can store 300 000 measures offline (https://www.ubibot.com/fr/product/ubibot-ws1/) ? sound strange with 20KB (time, temp, humidity, voltage, light, ext temp) that's make a lot

[sfromis]

It is 20MB of flash, not just 20KB, barbudor made a small typo. Storing 300000 samples in 16MB (the bigger flash chip) looks pretty wasteful, 55 bytes per sample, could likely be compacted a lot for efficient storage.

IIRC it is actually common that those EEPROM chips have multiple I2C addresses.

Some known devices with I2C address 0x53 but likely not good candidates:

ADXL345     3-axis accelerometer
CAT24C512   EEPROM - 512Kbit - 64KB
LM25066     PMBus power management IC
MB85RC      Ferroelectric RAM
PCA9685     16-channel PWM driver default address

[DzzD]

It is 20MB of flash, not just 20KB, barbudor made a small typo. Storing 300000 samples in 16MB (the bigger flash chip) looks pretty wasteful, 55 bytes per sample, could likely be compacted a lot for efficient storage.

IIRC it is actually common that those EEPROM chips have multiple I2C addresses.

Some known devices with I2C address 0x53 but likely not good candidates:

ADXL345     3-axis accelerometer
CAT24C512   EEPROM - 512Kbit - 64KB
LM25066     PMBus power management IC
MB85RC      Ferroelectric RAM
PCA9685     16-channel PWM driver default address

Ha yes... you know I also chek the datasheet and did the same error :)

For the EEPROM it sound to be the case of 4 banks of 256 bytes, I dumped them, it read fine, will try a write, but dangerous

Also I think I definitly find what the BDR is made for : https://www.ti.com/lit/ds/symlink/tps61020.pdf?ts=1670870088946&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTPS61020%252Fpart-details%252FTPS61020DRCR
=> The Ubibot can be used on USB power or two AAA bateries, it is probably used with the coil to convert/adjust voltage 3.3/5v

[DzzD]

Well probably last news for today :

I found the press button GPIO !! it is GPIO4 : 4095 when pressed 0 otherwise

I do a file logger on the ESP32 of all ADC GPIO input and plug/unplug the device from the computer, and I found the following results:

I found three other functional GPIO, one seems to be the voltage sensor :

When plugged :
GPIO34 = 0
GPIO35 = 4095
GPIO37 = between 25 and 40 // probably parasiting signal
GPIO36 = between 1277 and 1341 //probably the voltage sensor

When unplugged (powered by two batteries AAA) :
GPIO34 = 4095
GPIO35 = 0
GPIO37 = 0 // stable grouded
GPIO36 = between 660 and 700//probably the voltage sensor

If I suppose average value of GPIO36 plugged is 5V, I found that unplugged the voltage is 2,58v, it is really near of last measurment by the original firmware 2,58v vs 2,77v

There is something weird with the GPIO0, very low when starting plugged, then higher when unplugged and then even higher when re-plugged

[sfromis]

Looks like gpio 4 and 34-35 would make sense as Switch pins instead of analog.

[DzzD]

Haha!

I was able to decode interresting data from the EPROM, I found my WIFI SSID and password, so technicaly if you stole an ubibot to someone you will be able to hack is WIFI ^^

[DzzD]

how ! that would be the 4MB used by the ESP32 for program upload/download ? the one I dump and restore every days ?

[sfromis]

Most likely, yes.

[sfromis]

Whether Tasmota can access two flash chips may be another question. I've not seen other devices with a dual-chip setup there.

[DzzD]

cool this sound so logical now, thanks :)

I verified and there is no 4MB on this chip, so it is probably wired to use this external 4MB memory as it main memory

https://www.mouser.fr/ProductDetail/Espressif-Systems/ESP32-D0WDQ6-V3?qs=GBLSl2Akirt8fvUVSeeceA%3D%3D

We got nearly everything now, I will test digital output and smi next time, for the buzzer and smi for external temp sensor (and memory 16MB). last task to have a full description of this Ubibot device and all its components !

[sfromis]

To be a bit hairsplitting, they could have had a PSRAM chip for much more main memory than the internal about 300KB available with ESP32 (2, 4 or 8MB are not rare, slower than internal), the term for persistent data is usually "storage" for the flash chip(s).

[DzzD]

Just a note about the voltage sensor, when plugged to USB the original firmawre give :

• 4.77v using the serial software
• 5v using the web interface

I can assume they correct the value for this one and my 2,58v was right if i make the same adjustment they do I got 2,81v nearly perfect !

[DzzD]

Well, I managed to dump the 16MB flash, it seems to be on the VSPI bus, my surprise is that it was empty... but this is not that surprising as when using serial tools of original firmware it report nothing too.
Doc on this ESP & its VSPI Spins : https://www.mouser.fr/datasheet/2/891/Espressif_Systems_01292021_esp32-1991551.pdf

VSDI pins :

If any interrested here is the tools and parameters I used for dumping Flash on VSPI bus :
>>esptool -p COM7 -b 115200 read_flash 0 0x1000000 --spi-connection 18,19,23,21,5 flash_contents_vspi.bin

Also after electronics, I started some software retro-enginering :), I may learn some new things I still miss on this device :

1 - get some information about the 4MB flash :

>>esptool flash_id
esptool.py v4.4
Found 1 serial ports
Serial port COM7
Connecting.....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ec:94:cb:7f:7a:10
Uploading stub...
Running stub...
Stub running...
Manufacturer: ef
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

EDIT: also do on the 16MB :

esptool flash_id --spi-connection 18,19,23,21,5
esptool.py v4.4
Found 1 serial ports
Serial port COM7
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ec:94:cb:7f:7a:10
Uploading stub...
Running stub...
Stub running...
Configuring SPI flash mode...
Manufacturer: ef
Device: 4018
Detected flash size: 16MB
Hard resetting via RTS pin...

2 - dump 4MB flash, witch appear to be on standard SPI bus :
>>esptool -p COM7 -b 115200 read_flash 0 0x400000 flash_contents.bin => this tools default to main SPI if not specified

3 - have some read about partitioning :
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/partition-tables.html

4 - do first analysis using simple Hex/ASCII viewer (Notepad++) :
nothing before adresses 0x1000 and magic number 0xE9 found at 0x1000, this confirm the start of the firmware image, the memory size & speed and the entry point of the program (note that once file is cutted this can be done with esptool as bellow)
https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/firmware-image-format.html

5 - cut the file, to keep only what is after 0x1000 adresse, and so the file start with 0xE9 magic number

6 - get some information on this partition using the new cutted file : (simply used notepad++ to cut firsts 0x1000 bytes)

>>esptool image_info --version 2 flash_4M-startAt0x1000.bin
esptool.py v4.4
Detected image type: ESP32

ESP32 image header
==================
Image version: 1
Entry point: 0x40080608
Segments: 3
Flash size: 4MB
Flash freq: 40m
Flash mode: DIO

ESP32 extended image header
===========================
WP pin: 0xee
Flash pins drive settings: clk_drv: 0x0, q_drv: 0x0, d_drv: 0x0, cs0_drv: 0x0, hd_drv: 0x0, wp_drv: 0x0
Chip ID: 0
Minimal chip revision: v0.0, (legacy min_rev = 0)
Maximal chip revision: v0.0

Segments information
====================
Segment   Length   Load addr   File offs  Memory types
-------  -------  ----------  ----------  ------------
      1  0x012c8  0x3fff0030  0x00000018  BYTE_ACCESSIBLE, DRAM, DIRAM_DRAM
      2  0x03664  0x40078000  0x000012e8  CACHE_APP
      3  0x00c58  0x40080400  0x00004954  IRAM

ESP32 image footer
==================
Checksum: 0x5d (valid)
Validation hash: 99e6f14f4299453642db6e79b9a805f8a0697ea68d1406b7bc086f80ea6ff20e (valid)

Obviously, We get the same values for memory size, frequency and entry point that we read with notepad++

7 - Found another more powerfull tools to get more information on the whole 4MB dump

>>esp32_image_parser.py show_partitions flash_4M.bin
reading partition table...
entry 0:
  label      : nvs
  offset     : 0x9000
  length     : 16384
  type       : 1 [DATA]
  sub type   : 2 [WIFI]

entry 1:
  label      : otadata
  offset     : 0xd000
  length     : 8192
  type       : 1 [DATA]
  sub type   : 0 [OTA]

entry 2:
  label      : phy_init
  offset     : 0xf000
  length     : 4096
  type       : 1 [DATA]
  sub type   : 1 [RF]

entry 3:
  label      : factory
  offset     : 0x10000
  length     : 1376256
  type       : 0 [APP]
  sub type   : 0 [FACTORY]

entry 4:
  label      : ota_0
  offset     : 0x160000
  length     : 1376256
  type       : 0 [APP]
  sub type   : 16 [ota_0]

entry 5:
  label      : ota_1
  offset     : 0x2b0000
  length     : 1376256
  type       : 0 [APP]
  sub type   : 17 [ota_1]

MD5sum:
09932f7bcd7d10f816535786e9c20c37
Done

We get confirmation of the firmware partition !

Note that all partition before 0x1000 are obviously empty empty

Note that I needed to patch the original tools I found for the rest of this works, new tools available here : https://github.com/DzzD/esp32_image_parser

8 - once again do a simple analysis using Notepad++ in hex mode
using informations grabbed from the command above (offset & length values for the partitions) we can see in the file that the two ota partitions are empty, this means the interresting code is only in the factory partition.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/ota.html

9 - generate ELF file for disasamble & study source code program
Well, this one was a bit hard :

• first, as mentioned above I needed to patch the tools (esp32_image_parser for the elf command)
• second, I needed to find a disassembler able to understand this processor native assembly code and format

Looked at IDA Pro, free version cant do anything with this processor and license that may works is more then 10K€ :), a bit much...

I founded an interresting NSA opensourced project that should work but it require an extension for XTensa processor :
https://github.com/NationalSecurityAgency/ghidra
https://github.com/yath/ghidra-xtensa

Now, let's study what this code to under the hood, I should learn some new things that may help. :)

[DzzD]

cool I just discover Cutter that seems to work with an handy GUI