Technical topic solo2 clone (please only technical talk)

Thats going to be question "ERR: fail to erase flash!" could say that RSA key didnt allowed for flashing..


EDIT Thanx @slaw:But we now have to order the gear and go to investigation
 
Last edited by a moderator:
Do we know that the flash ram is write protected after the attack?

Sent from my GT-I9505 using Tapatalk

No I don't believe we have a credible source to confirm this. Until we don't have the ability to dissect the code used by VU in the anti clone measure or until we don't have the means to try and read write to the NAND via JTAG we don't know for sure..
The write protection might just be a red herring . There is a lot of speculation at the minute.
 
maybe have use wrong app to upgrade flash or connected wrongly, dont know jet
 
Yeah could be but i think this is thing with have to do with the right equipment..
 
I don't believe it is left write protected after the attack. The idea that it was I think came from a log file that somebody here posted where one of the last errors was a write error but from what I can tell this was a result of the flash being wiped which meant that the file system that enigma2 was using was wiped from under its feet.

Sent from my GT-I9505 using Tapatalk
 
I don't believe it is left write protected after the attack. The idea that it was I think came from a log file that somebody here posted where one of the last errors was a write error but from what I can tell this was a result of the flash being wiped which meant that the file system that enigma2 was using was wiped from under its feet.
You are correct the possible write protect was taken from the end of a log from the other thread. There could have been any number of reasons for this from wrong connection, invalid security key (if needed) even corrupt flash memory, etc. Can you run fsck on flash memory?

The way I see it is if it was write protected by an upgrade then surely this can also be changed to read/write by the same method! It is highly unlikely that a flash memory can be given the write protect command and then that becomes permanently write protected.
 
Ok guys...Could,if there was a kind of a protection,this also block the communication in a jtag seance?
 
You are correct the possible write protect was taken from the end of a log from the other thread. There could have been any number of reasons for this from wrong connection, invalid security key (if needed) even corrupt flash memory, etc. Can you run fsck on flash memory?

The way I see it is if it was write protected by an upgrade then surely this can also be changed to read/write by the same method! It is highly unlikely that a flash memory can be given the write protect command and then that becomes permanently write protected.

Microsoft managed to do it in their DVD drives to stop custom firmware being wrote to the flash chip. But I really hope you are correct lol.

Sent from my Nexus 5 using Tapatalk
 
I think the way that that was done was a one time fuse would be blown so once this was done there was no way back. Similar to the way that a galaxy s4 phones now blows a fuse if it's ever been rooted.

Sent from my GT-I9505 using Tapatalk
 
Instead of only talking as on the other topic, let's get more technical and post some technical things...

Who is able to :

- Dump the Flash chip they will receive from the manufacturer ?
- Dump the erase Flash chip from the killed receiver ?
- Get the datasheet for the Samsung K9F2G08U0B TSOP48 ?

This will answer your questions about the security/lock/chip.

Please post here,

Omni
 
Information to JTAG interesting?
 

Attachments

  • jtag_vu.pdf
    357.1 KB · Views: 27
Instead of only talking as on the other topic, let's get more technical and post some technical things...

Who is able to :

- Dump the Flash chip they will receive from the manufacturer ?
- Dump the erase Flash chip from the killed receiver ?
- Get the datasheet for the Samsung K9F2G08U0B TSOP48 ?

This will answer your questions about the security/lock/chip.

Please post here,

Omni

Hi Omni, i hope this is the right datasheet, let the page load a short moment, then u should see it:
K9F2G08U0B TSOP-48 - ???

Ooops reini12 was faster than me ;-) and with better upload... :)
 
Last edited:
Very good, yes !

Let's read it, so we talk about facts, and not what we think could be inside :Biggrin2:

Thank you !

Omni

Is this what you are looking for? if not then delete it.
 
There is a "Write protect", but doesn't tell its forever. More a temporary protection. So means then that JTAG is a possible solution.

Omni
 
Guys thanx alot,,,were getting somewehere...whats the next stp @omni?what do you want?
 
Last edited by a moderator:
We need to push the box supplier to get us :

- Full dump of the Flash (bin file), they can email it to us
(if we can also get the full dump of the dead Flash chip, would be good to compare and learn)
- cfe bin file
- Broadcom Studio for BCM7345 (Solo2)
- And confirmation of the 4 pins (pins from left GND,Rxd,Txd) (Thx slaw77)

Omni
 

Attachments

  • DSC_0363.jpg
    DSC_0363.jpg
    657.6 KB · Views: 32
Read carefully the discussion of VU Clone atatck from PLi Forum, radxnl who has looked into the atatck has confirmed that the "write protect" issue is not a permenant feature it can be circumvented using BBS Tools. Hence we should concentrate on obtaining

- Broadcom Studio + BCM7345 Support files.
- Valid replacement CFE flash file.
- Correct pinouts for the JTAG, it wouldnt surprise me if the pinouts are the same as the DUO JTAG. (Cypress board).

BBS pinout
1 is 3v3
2 is BSC_SCL
3 is BCS_SDA
4 is GND

See below a copy and paste of the conversation on pli forum regarding the write protect of the NAND.

2- Flash was not only erased, but also set to 'read-only'

Re: Vu clone attack #10 radxnl

PLi® Core member

2. As i stated, the box can be revived using the BBS tool, given you have one and the corresponding software and a dump of the CFE to write back.
 
backup.jpg
I have manage to do backup using rs232 cable, is it flash backup? Dont know how to do file post :/
 
Back
Top