Amazfit Midong and res2img - adaptation

[tomurbanowicz]

Is any chance for adaptation res2img to Amazfit Band?

Mili_tempo.zip

[ArcTuruS02]

Amazfit Band A1702 (midong). I also join with Tom!

[tomurbanowicz]

Amazfit Band - sorry.

[dpeddi]

I've tried to pass the Mili_tempo.res into the tool, but it hangs... by forcing to go over some resouces are extracted. I've tried to figure out the format but currently i have no time to identify it.

[tomurbanowicz]

That works for that: https://forum.gizchina.it/index.php?/topic/1177-amazfit-bip-resource-creator-cambiare-watchfaces-su-amazfit-bip/ Pozdrawiam, --- Tomasz Urbanowicz http://www.urbanowicz.net.pl http://blog.urbanowicz.net.pl http://www.facebook.com/foto.urbanowicz tel. 733 222 733 2017-10-19 13:58 GMT+02:00 dpeddi <notifications@github.com>:

…

I've tried to pass the Mili_tempo.res into the tool, but it hangs... by forcing to go over some resouces are extracted. I've tried to figure out the format but currently i have no time to identify it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeXjQh6eyAtSmcz-iHtec72Zy-kXciMlks5stzlfgaJpZM4P7uUX> .

[niclet]

I had a look at the last Mili_tempo.res from 3.1.2

• some bytes before HMRES signature
• seems to be 811 offsets, no idea where they point to (the last one is 989215 but file size is 305353...)
• seems to be 241 'BM' sections whose content is quite similar / quite different to Mili_chaohu.res ones

[dpeddi]

The file is compressed with an unknown algorithm that remove redundancy. There are blocks of compressed data with dynamic size.
The header meaning should be: 1 byte of flag, 4 bytes of compressed size, 4 bytes as uncompressed size.
When uncompressed the size of the data should become at the same size of the size declared in the header.
The first and the last chunk of data on the new res file format seems uncompressed.

Inside each chunk there are other "chunk" header that explain the uncompressor where and how many time put the data.

[niclet]

When you talk about header, do you mean the bytes before HMRES ? or inside each BM section ?

[tomurbanowicz]

The newest RES is quite different
Mili_tempo-newest.zip

[niclet]

@tomurbanowicz, yes, this is the one we are analysing

[niclet]

Ok, so, here is what I understand, according to @dpeddi comment

• first block : 0x4E / compressed size (4 bytes) / uncompressed size (4 bytes)
• other blocks : 0x4F / compressed size (4 bytes) / uncompressed size (4 bytes)
• near the end : 0x00 followed by unknown data, maybe last uncompressed block

There is 242 blocks of 4096 bytes (uncompressed size) plus 3311 bytes

[dpeddi]

seems correct... then there are block header, and chunk header. the chunk reader seems parsed and depending on some bit the firmware decide how to use the data near to it however depending.

I'm still trying to figure the relation between the header and the data

[Eth3rkni6ht]

Hi,
Since last week there are new faces available. I got the bin file of one of them. I'm interested in doing custom faces, hope you can help. I tried the script but of course it fails:

python dial2img.py -i f7752fb940506ae816ae75569a54c898.bin -u
file is a Haumi resource file
version 0
-177
number of resources: 44
resource 0 | addr: ffffffff | pos on file: fffffffe
ERROR: 0 isn't a bitmap resource
resource 1 | addr: ffffffff | pos on file: fffffffe
ERROR: 1 isn't a bitmap resource
resource 2 | addr: ffffffff | pos on file: fffffffe
ERROR: 2 isn't a bitmap resource
......

Best regards
Face_Midong.zip