New cheap portable player in the market

[pmp4]

I found this url with "Spreadtrum Research Download Tool" source code (2.9.7007 version)

That's some outdated version. Latest version can be downloaded from official web-site https://spdflashtool.com/category/research-tool. Tutorial how to use it: https://spdflashtool.com/tutorial/use-spd-research-tool

I also saw instruction how to flash FullFlash .bin file with this tool (by default it requires .pac) https://4pda.to/forum/index.php?showtopic=625677&st=20#entry61083373
Though it's in Russian (Краткий гайд по прошивке китайских телефонов на базе SpreadTrum SC6531) - let me know if you have any translation troubles.

Yeah, but the version I posted has the source code, unlike other last versions.

Anyway, the same source code can be found in the very useful complete zip you posted.
Same source code, same version in: /MOCOR_12C.W13.04.23.BTDialer.20_Source/tools/DEBUG_TOOL/ResearchDownload/Source
(I think that was the original source of the leak).

But since I saw that zip you posted, I've left the target of study research download and pac files, I'm not interested in that anymore.

My current target is modify res.bin, recompress (using bzpwork) and write using UniFlash in .bin format. Once I can flash a modified MOCOR firmware (different res.bin) without destroy the player, the next target will be a rockbox "hello world", that will be more than enough for me by now.

Resources (res.bin) structure file can be found in the file "mmi_resource_def.h" of the zip.

ResOver.exe is useful as test, but it's incomplete, it can't extract all the resources of res.bin (like animated GIF and all text strings).

I ordered another portable player because I only got one, and I think it can be bricked in my tests  .
I dont know yet, but I suspect the boot mode is always on, even if you flash the wrong firmware, I will confirm that in the future.

I ordered a slightly different model, with different button, I think it's the same, from the same manufacturer. The only difference is the button design, and that it has several submodels, with internal nand memory of 8/16/32 GB and without nand memory (I ordered without NAND).

https://www.aliexpress.com/item/1005004543172464.html (exactly 12.19 EUR, ship included, around 12 USD too)

In the pics appears differents icons, but I think it can't be trusted, and maybe it's the same firmware than the other player, because I've seen it in videos:

https://shopee.com.my/2022-New-Mini-Bluetooth-Mp3-Mp4-Music-Player-Fm-Radio-Hi-Fi-Media-Lossless-Voice-E-Book-Reader-i.513952359.14130839607

https://play-ws.vod.shopee.com/c3/98934353/103/AnoyQ3IANMHcnQUhGAIBAEY.mp4

BTW I've seen a similar player from the same manufacturer (I guess) and similar firmware, but in touch version. Same box, similar GUI design but with touchable screen, without buttons:

https://shopee.com.my/2.0-Mini-Touch-Screen-Bluetooth-MP3-Player-Portable-Audio-Music-Video-Player-with-Built-in-Speaker-FM-Radio-Recorder-Ebook-i.694651067.15656407769

[bahus]

Yeah, but the version I posted has the source code, unlike other last versions.

Latest source for all their tools is also posted on their website https://spdflashtool.com/source/spd-tool-source-code

My current target is modify res.bin, recompress (using bzpwork) and write using UniFlash in .bin format.

Ok but it seems Bilgus has troubles writing using UniFlash. So maybe ResearchTool would still be required.

[pmp4]

Yeah, but the version I posted has the source code, unlike other last versions.

Latest source for all their tools is also posted on their website https://spdflashtool.com/source/spd-tool-source-code

My current target is modify res.bin, recompress (using bzpwork) and write using UniFlash in .bin format.

Ok but it seems Bilgus has troubles writing using UniFlash. So maybe ResearchTool would still be required.

I can't confirm it, I didn't test write yet.

Maybe write address is different, I dont know.

As general advice, sometimes it's faster see USB traffic than see source code, to do reverse engineering to a usb driver.

In linux it's easy thanks to usbmon kernel module.

Just run windows over virtualbox in linux, load modprobe, and see the trafffic with tcpdump like if usb was a network interface.
something like this:
modprobe usbmon
tcpdump -i usbmon1 -s 65535 -n -q -w test.pcap

and open test.pcap with WireShark. Change usbmon1 by the number of USB bus (see with lsusb).

[Bilgus]

Maybe write address is different, I dont know.

this is my guess as well, as I get to 'FDL running, may start interacting with flash memory'
but a timeout once the write flash command is sent

Ive tried all three 6531A bins so at least none of them have bricked the device

[pmp4]

Maybe write address is different, I dont know.

this is my guess as well, as I get to 'FDL running, may start interacting with flash memory'
but a timeout once the write flash command is sent

Ive tried all three 6531A bins so at least none of them have bricked the device

Even if it's the command was ok, we can't know if the flash really works until we have a different firmware, because we got just one firmware, and we will see no changes in the device if the flash write response is ok.

That's one reason because I'm trying to modify res.bin, it's the best way to know if write flash really works, changing gui appearance. (the another reason, it's because I dont like MOCOR standard GUI  )

As I read in the Luxferre blog (the UniFlash author), write flash doesnt need fdl. Maybe I misunderstood it.
fdl is just for read the flash and another values (kind of cpu and so on), but write flash can be done just with the boot mode, without fdl.
Write flash is like upload a fdl, but instead in the ram address, in the nor flash address.

[Bilgus]

fdl is just for read the flash and another values (kind of cpu and so on), but write flash can be done just with the boot mode, without fdl.

judging by the way the script is laid out I don't think that is the case but it's not working for me so far so I too could be misunderstanding it

[bahus]

Maybe write address is different, I dont know.

From instruction I posted earlier the following addresses are used:
FDL: 0x34000000
Firmware: 0x80000003

FDL file: https://mega.nz/file/RX4GRKjR#Dm79NZVtZxqmmrStJvOgasF8rzPyW2D3xHj-zcD7tKU

[Bilgus]

I might have to dig out a windows machine to try the spreadtrum flasher or my dev machine so I can run a windows vm

I get to
FDL running, may start interacting with flash memory

with two of the bins but the norss one never gets to that point

I read through your instructions and already had an incantation but unfortunately they never get past the command to enable flash write

Code: [Select]

uniflash.py flash ./oldbin.bin -wf -nr -s 0x80000003 -t 6531A_norss

[pmp4]

I might have to dig out a windows machine to try the spreadtrum flasher or my dev machine so I can run a windows vm

I get to
FDL running, may start interacting with flash memory

with two of the bins but the norss one never gets to that point

I read through your instructions and already had an incantation but unfortunately they never get past the command to enable flash write

Code: [Select]

uniflash.py flash ./oldbin.bin -wf -nr -s 0x80000003 -t 6531A_norss

But the dump (read) flash command works in your machine?

I can confirm that dump (read) command works in linux using uniflash and the fdl I said in this thread.

I can't confirm flash (write) command yet.

[Bilgus]

But the dump (read) flash command works in your machine?

Yes I've dumped the device, dis-assembled and even re-assembled the stone image
so far (on linux)

[pmp4]

I've tested flash (write) command, and I can confirm that doesnt work.

Crash in Line 88 of uniflash.py:
assert rcode == unicmd.BSL_REP_ACK, 'Could not start data transfer, response code is %X' % rcode

In that line ends the program, with the response code = 0xFF.

I tried to comment the line, and it starts to send data a few minutes, and then it crash in Line 96.
assert rcode == unicmd.BSL_REP_ACK, 'Something is wrong and response code is %X, block is %s' % (rcode, buf.hex())

With the response code 0x89.

The devices keeps alive, just reset, and try to dump (read) the flash, and then starts again.

[bahus]

Hm.. Reading https://chronovir.us/2021/12/18/Opus-Spreadtrum/  - 0x80000003 seems shouldn't be used when writing. It's some kind of marker and not real address...

Just to iterate all possible cases  you should try renaming working fdl files to `sc6530_something` so the following lines are executed
https://gitlab.com/suborg/uniflash/-/blob/master/uniflash.py#L255-256

So try something like renaming 6531A_Write_Full_Flash_1.bin -> sc6530_wff_0x34000000_single.bin

uniflash.py flash ./oldbin.bin -t sc6530_wff
or
uniflash.py flash -wf ./oldbin.bin -t sc6530_wff

[pmp4]

Hm.. Reading https://chronovir.us/2021/12/18/Opus-Spreadtrum/  - 0x80000003 seems shouldn't be used when writing. It's some kind of marker and not real address...

Just to iterate all possible cases  you should try to rename working fdl files to `sc6530_something` so the following lines are executed
https://gitlab.com/suborg/uniflash/-/blob/master/uniflash.py#L255-256

So try something like renaming 6531A_Write_Full_Flash_1.bin -> sc6530_wff_0x34000000_single.bin

uniflash.py flash ./oldbin.bin -t sc6530_wff
or
uniflash.py flash -wf ./oldbin.bin -t sc6530_wff

You're absolutely right!

It works!

Rename 6531A_Write_Full_Flash_1.bin to sc6530_generic_0x34000000_single.bin and put in fdls folder of UniFlash. And then:

uniflash.py -t sc6530_generic flash firm_mod.bin

Once written, restart, and dump the flash, and when it ends, it starts the player with the new firm.

I flashed a modified firmware with different icons (changed with ResOver.exe) and it works!

[pmp4]

Here I post a pic of the player with the new modified firmware:

[pmp4]

Here I post instructions of how modify icons of the MOCOR firmware:

Just open res.bin with ResOver.exe (it works in a Windows XP virtualbox machine in linux)  and change the icons your want, with the same size/format/filename.
Once you got the new res.bin, you need to compress it in a complete firmware file.

I tried to use BZPwork but it didnt work (it lacks one file when you try to compress a folder with all files).

So instead I use BZPcmd.exe from the 6531.zip, just running windows xp over virtualbox in linux. (You can find it in MOCOR_12C.W13.04.23.BTDialer.20_Source/make/make_cmd/BZPcmd.exe)

Here are the commands:

BZPcmd.exe -L -cat2 -level 5 -usr usr.bin -usrpacsize 4096 -usrcmp b -res res.bin -respacksize 4096 -rescmp b -out part1.bin
BZPcmd.exe -L -cat -level 5 -cmp b -ps ps.bin -kernz kern.bin -res part1.bin -out firm_mod.bin

And you get the new modified firmware in the file firm_mod.bin. You can uncompress with bzpwork to verify that it works fine. I did and every file is the same, except ps.bin that change a little (but it works) than before BZPcmd.exe run.

Here is my modified firmware: https://www.mediafire.com/file/j354kp0hwcuqo5i/firm_mod.bin/file

(I just changed 6 icons from main menu and the background image/color).