Disassembling Joyetech eVic firmware image

[bitterskittles]

Hi, I've just created a project on GitHub, that can decrypt joyetech eVic firmware image v1.0 - v1.1
I'd appreciate any help with finding a disassembler for the binary image.

https://github.com/bitterskittles/NVaporWare

 

[bitterskittles]

I think the MCU could be one of 8051 based Sinowealth Lithium battery management chips. ida can disassemble the file, but haven't played around with it yet

SH366000
I couldn't find an English product description page, but here is the Google translated summary:

Description :
The SH366000 Ying Electronic Co., Ltd. introduced an intelligent battery management chip, its communication protocol is compatible with SMBus1.1, in line with the smart battery the instruction set SBData1.1 specifications; 2 to 4 apply to lithium-ion and lithium-polymer battery pack; be able to accurately calculate the full charge capacity of the battery pack, the remaining capacity and run time and charging of the battery can complete the required time; provide voltage, current, temperature monitoring, providing hardware and software protection; provide cell balancing function to extend the battery life.

Characteristic:
■ achieve 2 -, 3 -, 4 - string lithium battery charge and discharge management and security
■ compatible with SMBus v1.1 and SBData1.1 standardize
■ Coulomb integral method and the open circuit voltage combined to determine the remaining capacity of the battery
■ Under the current temperature and current, combined with embedded model dynamically calculated discharge cut-off voltage
■ with self-learning function, a full charge and discharge process to obtain the actual maximum capacity
■ provide overload and short circuit protection, MV / LV / over / under temperature battery pack protection
■ two security
■ cell balancing function to extend the battery life
■ support 4 - ,5-LED output display absolute or relative remaining battery percentage
■ Low-power system design
■ Package: TQFP 48/TSSOP 38

 

[Janusxvii]

I don't know that I have much to offer in terms of help on this subject but I think I like where you are going with this. I haven't used an evic yet but based on what it is it seems reasonable for me to believe that someone with better programming skills than myself should be able to write unofficial firmware. This could be an absolute game changer. Perhaps the best place to start would be a complete disassembly of the control head to see exactly what it is working with (hopefully they didn't put globs of epoxy over the chip(s)). A physical inspection is the only way to know for sure what the technical limitations are. The next step would be how the firmware is written. Likewise, ( I just thought of this) decompiling the MVR software that displays usage data on the PC might yield some useful information as well.
I doubt that was terribly helpful but I had to comment on this since I have been thinking about this for the past few days. I'll probably go ahead and order an evic in the next week or so because even though most of the bells and whistles are useless to me I am convinced it's only a matter of time until a firmware (official or otherwise) comes out that makes it a much better device for most vapers.

 

[bitterskittles]

Hi Janusxvii,
Thanks for your comment. Getting the decryption out of disassembled MVR was easy, and it should be fairly trivial to write a program to read the statistics from the device and write a new firmware through USB. However, my assembly skills are limited to x86/x64 CPU's, and I also agree with you that it would reveal more information if the internals of the control head was examined by someone with the right skill set.

Also, MVR.exe contains the string "Sinowealth_Sh86313_Smoke_Joyetech_Type0001", which I believe is the identifier of the MCU that runs the firmware and controls the lithium battery management chip inside the control head.

I must also admit that I haven't ordered an eVic device yet due to some negative reviews on youtube (JoyeTech eVic Full Review v1.1 - YouTube). I'd consider buying one if some of the issues like incorrect actual volt levels were addressed in a new firmware.

 

[KraKsX]

OMG someone do this!
I'm sure we have someone smart enough, even if its just to fix the damn display messages, like "no atomizer find" to "no atomizer found" I really want to like the eVic and think people here can make a 'better' firmware then Joyetech can.

Good luck !

 

[Janusxvii]

Well I did pull the trigger on ordering one. I should be getting it towards the end of the week. I have no experience with programming outside of a mediocre aptitude with the Arduino micro-controller. However I have a decent amount of work related experience with electronics and reverse engineering and will be examining the device carefully to see how difficult it will be to disassemble without destroying it. If I don't feel 100% comfortable that I can strip it down to the board level without ruining the unit then I'm going to wait until I can reasonably afford to buy just a control head to sacrifice in the name of research and development. Whatever my observations are I will post them here.
Also I feel like it's worth pointing out that in the process of googling "sinowealth sh86313" I discovered another vaping message board where it looks like someone else came to the same conclusion as you bitterskittles. Lastly, I saw somewhere (but can't remember where) that Joytech is planning on releasing v1.2 of the firmware and v1.1 of the MVR software in the very near future.

OVALE/Joyetech eVic - new VV mod - Page 6

 

[Rock0900]

I'll jump in in a couple weeks, got a move coming up first and will need to do some resettling first.

 

[bitterskittles]

Hi,

I had time to learn 8051 assembly and peek into the decrypted firmware image this week, and wanted to post a quick update on my findings. Actually 8051 turned out to be much simpler than x86, however, the small amount of instructions and being a 8 bit processor causes an inflation in the number of instructions used to do a simple operation, especially when moving data around registers code memory and external memory.

in v1.1, the bitmaps for the fonts and other things start from address 0x2B13. The first byte is the number of horizontal pixels, and the second byte corresponds to the number of vertical pixels.

Length of a single image data is: ((height * width) / 8)

The first character at 0x2B13 is number 0, followed by the rest of the numbers and lower case letters. Haven't examined every image but I assume it follows the ASCII order.

The only thing is, every 2 row has to be swapped for some reason that's unknown to me for the moment. I will investigate the disassembled code further when I have more time.

Examples:
number 0
Address: 0x2B13
Data: 06 08 7E 00 81 81 7E 81
Total length: 8 bytes
Size: 6x8

Default order:	After swapping the columns:

number 3
Address: 0x2B2B
Data: 06 08 42 00 89 81 76 89
Total length: 8 bytes
Size: 6x8

Default order:	After swapping the columns:

 

[Rock0900]

Good job! Take this as a start. When 1.2 comes out, we'll be taking it from there.

 

[Judge Dredd]

Hi,

I had time to learn 8051 assembly and peek into the decrypted firmware image this week, and wanted to post a quick update on my findings. Actually 8051 turned out to be much simpler than x86, however, the small amount of instructions and being a 8 bit processor causes an inflation in the number of instructions used to do a simple operation, especially when moving data around registers code memory and external memory.

in v1.1, the bitmaps for the fonts and other things start from address 0x2B13. The first byte is the number of horizontal pixels, and the second byte corresponds to the number of vertical pixels.

Length of a single image data is: ((height * width) / 8)

The first character at 0x2B13 is number 0, followed by the rest of the numbers and lower case letters. Haven't examined every image but I assume it follows the ASCII order.

The only thing is, every 2 row has to be swapped for some reason that's unknown to me for the moment. I will investigate the disassembled code further when I have more time.

Examples:
number 0
Address: 0x2B13
Data: 06 08 7E 00 81 81 7E 81
Total length: 8 bytes
Size: 6x8

Default order:	After swapping the columns:
View attachment 171970	View attachment 171971

number 3
Address: 0x2B2B
Data: 06 08 42 00 89 81 76 89
Total length: 8 bytes
Size: 6x8

Default order:	After swapping the columns:
View attachment 171976	View attachment 171973

Did you use IDA for this?

 

[bitterskittles]

Did you use IDA for this?

I did use IDA to take a look at the code, but I found out about the images when I noticed a pattern while scrolling through the firmware image file in the hex viewer. How the firmware accesses those images and how the strings are encoded, accessed and used are the next things I want to investigate.

Edit: oh I know what I'll do next. I'll stitch together some code to extract the images, or maybe even replace them

 

[Judge Dredd]

I did use IDA to take a look at the code, but I found out about the images when I noticed a pattern while scrolling through the firmware image file in the hex viewer. How the firmware accesses those images and how the strings are encoded, accessed and used are the next things I want investigate.

Edit: oh I know what I'll do next. I'll stitch together some code to extract the images, or maybe even replace them

You really ought to include the release or debug versions of your built and compiled code, like NVaporWare. That would be helpful!

I'd love to work with you on reversing the firmware if you'd like.

 

[bitterskittles]

You really ought to include the release or debug versions of your built and compiled code, like NVaporWare. That would be helpful!

I'd love to work with you on reversing the firmware if you'd like.

Being a total MCU and electronics noob, I'd appreciate any help with reversing the firmware and the hardware as well.
I created the repository on Github to document and share my findings, and haven't considered making the built binaries available since the decryption is only 1 subtraction and 1 xor operation in a simple iteration
But yup, I think I can add my image extraction, repacking, and file encryption code into NVaporWare library and make a pretty front end for it

 

[Judge Dredd]

Being a total MCU and electronics noob, I'd appreciate any help with reversing the firmware and the hardware as well.
I created the repository on Github to document and share my findings, and haven't considered making the built binaries available since the decryption is only 1 subtraction and 1 xor operation in a simple iteration
But yup, I think I can add my image extraction, repacking, and file encryption code into NVaporWare library and make a pretty front end for it

I like that! In the meantime, can you please PM me a download to the decrypted firmware file so I can disassemble it? I don't want to install VSC# just for this alone.

 

[bitterskittles]

Here's the second and the last update for tonight:
I was wrong to believe that the images started from 0x2B13 in my earlier post. After peeking around a little, I came to think that the images start from 0x2B10, with a dummy character (can also be a single pixel dot), and continue with number 0 after that in ASCII order. This makes zero the second character, and it can be accessed with index 1 in eVic char table.

Hexadecimal value (index) of 0 is 0x30 in the ASCII table, and subtracting 0x01 (the index of 0 in the eVic table) from 0x30 yields 0x2F.

Now, if we skip forward to the offset 0xECA1 in v1.1 file, and take the characters until the next 0x00, we get:
0x1E, 0x40, 0x3F, 0x35, 0x32, 0x4A

Now, if we add the value 0x2F we found earlier (by subtracting the index of 0 in the eVic table from the index of 0 in the ASCII table) to every char, it becomes:
0x4D, 0x6F, 0x6E, 0x64, 0x61, 0x79

And finally, we open up the ASCII table, and get the characters that correspond to these hexadecimal values:
"M", "o", "n", "d", "a", "y"

Coincidence? Lets get the next string until 0x00 (starts from 0xECA8)
0x25, 0x46, 0x36, 0x44, 0x35, 0x32, 0x4A

Now add 0x2F:
0x54, 0x75, 0x65, 0x73, 0x64, 0x61, 0x79

and finally translate to ASCII:
"T", "u", "e", "s", "d", "a", "y"

Happy Haxx0ring! ^^

 

[bitterskittles]

I don't want to install VSC# just for this alone.

There is always SharpDevelop for this kind of stuff, and the installer of the latest version is only 14.7 MB

 

[Janusxvii]

Wow! Seems like a lot happened today. That's a good breakthrough on the programming bitterskittles. I definitely won't be of any use though on the software end of things. I got my evic in the mail today. It's a neat little device. From a naked eye inspection, disassembly doesn't look very straightforward. If you watch a video review where they show the bottom of the control head where there is a little brass button that contacts the battery in the tube you will see a whole lot of black... I believe that is epoxy. Though I don't think the whole inside of the head is flooded. I should have a pretty slow day at work tomorrow so I'll give it a look over under a 20X inspection microscope and try to get a solid picture of what will have to be done to get at the guts. Personally, my goal for myself is to document the electronics and find out what the device is theoretically capable of (maximum hardware limitations).

 

[bitterskittles]

Wow! Seems like a lot happened today. That's a good breakthrough on the programming bitterskittles. I definitely won't be of any use though on the software end of things. I got my evic in the mail today. It's a neat little device. From a naked eye inspection, disassembly doesn't look very straightforward. If you watch a video review where they show the bottom of the control head where there is a little brass button that contacts the battery in the tube you will see a whole lot of black... I believe that is epoxy. Though I don't think the whole inside of the head is flooded. I should have a pretty slow day at work tomorrow so I'll give it a look over under a 20X inspection microscope and try to get a solid picture of what will have to be done to get at the guts. Personally, my goal for myself is to document the electronics and find out what the device is theoretically capable of (maximum hardware limitations).

Good stuff! If we knew what inputs/outputs are connected to where, we could even write our own firmware from scratch! I am even more tempted to get an eVic, but I guess I'll wait for v1.2 (or whatever the next version is)

Now, I wish for the next gen devices to come with an ARM processor, color LCD, Linux OS and SD card reader, oh and an USB host and bluetooth so I could stream and listen to music on while I vape

 

[bitterskittles]

I said it would be my last update for the night in my previous post, but had too much vape and coffee so couldn't get to sleep xD

Here is a summary of my findings in v1.1:

• Images (including fonts) are stored between offsets 0x2B0F - 0x3D0C (see image format)
  
• Strings (at least some of them) are stored between offsets 0xECA1-0xEFA5 (see ASCII to eVic character conversion)
  
• (new) Character to image mapping table, which maps chars to images, is between offsets 0x3D0D-0x3E2C
  The table starts with number 0, and follows the ASCII order

 

[Judge Dredd]

Thanks to bitterskittles, I was able to find an instance of 0x11 closely followed by 0x00. I am going to see if we can find a way to get this new firmware file to my eVic and see if I raised the limit to 15 watts.

EDIT: ignore this. 0x11 is 17 in dec. Forgot about that.