@Ferret and @AJT,
i have opend this topic we realy need a Topic whos going to help us te solve the Bricked problem,a topic ONLY meant for technical details and if possible sollutions to FIX the problemwere saving at this moment,
So please only reply if u have technical information!!
If you want to talk or want to complain,please do that at this link:
http://www.digitalworldz.co.uk/vu-solo2-receivers-633/378201-anyone-got-chinese-vu-263.html
So basicaly what happend was this:
So for some technical background, just for those who care
About half a year or so ago i already made aware that there was added into the Vu drivers a 'time bomb', i don't know the exact thread by heart but pretty sure that the search function will bring it up..
The following driver releases where, apart for the usual bug fixes and improvements, trial runs for what has now gone 'live'.
Due to the fact the guys who cloned the security for the Chinese (and this was actually done in Europe, as many of you might know) made a pretty good copy of the alpu tpm chip (from neowine), which is used by many stb manufacturers and of course offers no real sense of clone protection what so ever
Vu had to look for another means of establishing the board authenticity.
So the logical second choice was the FPGA, hey, it was sitting on the board anyway and for the clone companies would for sure mean another $10/25K to read out and so that was of course the logical way to go.
So that brings us to the current situation, the best they can do is just wipe out the block in the nand where the SoC boots from, that would mean that the resellers will have to be equipped with at least BBS tools and software to 'revive' all boxes killed in the 19-4 attack.
Which is of course a good thing in more that one way,
First - the clones where shut off, even if it will be for a very short time. But this is giving a strong signal to the end user market never to buy a clone (of course, buying a clone is always a bad thing) as you can never be sure what will happen.
Second - this creates a market for the 'guy on the attic with a soldering station' (not that he will need one in this case) but you know the guy i am talking about, these are the same guys who helped out when ci modules and other stb where killed (a.k.a. erased) in the past.
So i guess the next thing that will happen is that the manufacturer of the clone boxes will start shipping BBS tools and so on to their resellers and they will 'fix' the problem in a jiffie any day soon now.
And now, just because we can, a quick rundown of what is exactly the 'authenticity check' and the 'counter measure' taken by Vu.
Let me first just state, i have no involvement in any cloning activities, i am just an independent researcher who likes to 'see what went down'.
And if i tell or not, it won't matter for the outcome, the current 'disabled' hardware will be revived, i am sure of this as there where too many sold already so it is imperative to the companies who made them that the 'problem' will be fixed, and so it will.
So, first what they have done is do some FPGA magic, to confirm to the drivers that they are in fact dealing with cloned hardware (i won't go into details on how they do this, its some challenge, some des crypto and some other stuff but not really relevant to be known exactly).
Then after they have established that it is in fact not a genuine board some counters start running in some critical places, like the tuning of the front end, vfd actions and a random one connected to the a/v input. So doing this they are pretty sure that at some point the counter limits are reached and then it is time to run 'the check'.
The check of course consist of a simple 'hello, what day are we at?' if this is in fact 19-4-2014 or later it is time to do some erasing to make sure that we are not happy that you cloned our board.
So now we start erasing, all they need to do is clean out the area where to SoC start reading from after it start up (a.k.a. the boot loader, a.k.a CFE). But for whatever reasons they chose to erase 64 pages, I guess to make sure it really won't start (not that it would matter at all, 1 would have been enough).
After that the erasing continues some more when the critical functions are called until the stb is rebooted and at that point the user will get a nice black screen and no reaction from the stb what so ever. All gpio will remain uninitialized after powering on, this for instance causes the LAN light to stay on continuously and so forth.
So that's pretty much the background of the whole thing, clones are killed and now let's see what the next move will be
For those who want to investigate the matter for them selves,
the recent functions where added into the drivers from a file called brcm_fpga_secu.c,
find it and you will see what i was talking about
A quick code snippet from it (the least interesting one, as here the damage is 'already being done') just for reference:
void nand_erase_64_pages(void)
{
for (int addr = 0; addr < 64; addr += 2)
{
BDEV_WR_RB((BCHP_NAND_CMD_ADDRESS, addr));
BDEV_WR_RB((BCHP_NAND_CMD_START, CMD_ERASE << BCHP_NAND_CMD_START_OPCODE_SHIFT));
BDEV_WR_RB((BCHP_NAND_CMD_START, CMD_NULL << BCHP_NAND_CMD_START_OPCODE_SHIFT));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x00, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x04, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x08, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x0c, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x00, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x04, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x08, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x0c, 0));
BKNI_Sleep_tagged(20);
}
BKNI_Sleep_tagged(100);
}
Moral of the story is of course, with the genuine product you would have never had these kind of issues and thus that is ALWAYS the way to go!
These where my 2 cents
happy reading.
The situation is that we are having a situation that the Bootlog is deleted and the CHIP is write protected
So we have to find out if there JTAG possibilities,so please lets concentrate on that!
@omni ive read here and on the Ferrari forum you have some mtd files,do you have enough info or what else do you need more?
@smart did managed to extract the mtd0-mtd1-mtd2-mtd3-mtd4 files from his lonrus boxes he did upload this.
So what`s the next step?
i have opend this topic we realy need a Topic whos going to help us te solve the Bricked problem,a topic ONLY meant for technical details and if possible sollutions to FIX the problemwere saving at this moment,
So please only reply if u have technical information!!
If you want to talk or want to complain,please do that at this link:
http://www.digitalworldz.co.uk/vu-solo2-receivers-633/378201-anyone-got-chinese-vu-263.html
So basicaly what happend was this:
So for some technical background, just for those who care
About half a year or so ago i already made aware that there was added into the Vu drivers a 'time bomb', i don't know the exact thread by heart but pretty sure that the search function will bring it up..
The following driver releases where, apart for the usual bug fixes and improvements, trial runs for what has now gone 'live'.
Due to the fact the guys who cloned the security for the Chinese (and this was actually done in Europe, as many of you might know) made a pretty good copy of the alpu tpm chip (from neowine), which is used by many stb manufacturers and of course offers no real sense of clone protection what so ever
So the logical second choice was the FPGA, hey, it was sitting on the board anyway and for the clone companies would for sure mean another $10/25K to read out and so that was of course the logical way to go.
So that brings us to the current situation, the best they can do is just wipe out the block in the nand where the SoC boots from, that would mean that the resellers will have to be equipped with at least BBS tools and software to 'revive' all boxes killed in the 19-4 attack.
Which is of course a good thing in more that one way,
First - the clones where shut off, even if it will be for a very short time. But this is giving a strong signal to the end user market never to buy a clone (of course, buying a clone is always a bad thing) as you can never be sure what will happen.
Second - this creates a market for the 'guy on the attic with a soldering station' (not that he will need one in this case) but you know the guy i am talking about, these are the same guys who helped out when ci modules and other stb where killed (a.k.a. erased) in the past.
So i guess the next thing that will happen is that the manufacturer of the clone boxes will start shipping BBS tools and so on to their resellers and they will 'fix' the problem in a jiffie any day soon now.
And now, just because we can, a quick rundown of what is exactly the 'authenticity check' and the 'counter measure' taken by Vu.
Let me first just state, i have no involvement in any cloning activities, i am just an independent researcher who likes to 'see what went down'.
And if i tell or not, it won't matter for the outcome, the current 'disabled' hardware will be revived, i am sure of this as there where too many sold already so it is imperative to the companies who made them that the 'problem' will be fixed, and so it will.
So, first what they have done is do some FPGA magic, to confirm to the drivers that they are in fact dealing with cloned hardware (i won't go into details on how they do this, its some challenge, some des crypto and some other stuff but not really relevant to be known exactly).
Then after they have established that it is in fact not a genuine board some counters start running in some critical places, like the tuning of the front end, vfd actions and a random one connected to the a/v input. So doing this they are pretty sure that at some point the counter limits are reached and then it is time to run 'the check'.
The check of course consist of a simple 'hello, what day are we at?' if this is in fact 19-4-2014 or later it is time to do some erasing to make sure that we are not happy that you cloned our board.
So now we start erasing, all they need to do is clean out the area where to SoC start reading from after it start up (a.k.a. the boot loader, a.k.a CFE). But for whatever reasons they chose to erase 64 pages, I guess to make sure it really won't start (not that it would matter at all, 1 would have been enough).
After that the erasing continues some more when the critical functions are called until the stb is rebooted and at that point the user will get a nice black screen and no reaction from the stb what so ever. All gpio will remain uninitialized after powering on, this for instance causes the LAN light to stay on continuously and so forth.
So that's pretty much the background of the whole thing, clones are killed and now let's see what the next move will be
For those who want to investigate the matter for them selves,
the recent functions where added into the drivers from a file called brcm_fpga_secu.c,
find it and you will see what i was talking about
A quick code snippet from it (the least interesting one, as here the damage is 'already being done') just for reference:
void nand_erase_64_pages(void)
{
for (int addr = 0; addr < 64; addr += 2)
{
BDEV_WR_RB((BCHP_NAND_CMD_ADDRESS, addr));
BDEV_WR_RB((BCHP_NAND_CMD_START, CMD_ERASE << BCHP_NAND_CMD_START_OPCODE_SHIFT));
BDEV_WR_RB((BCHP_NAND_CMD_START, CMD_NULL << BCHP_NAND_CMD_START_OPCODE_SHIFT));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x00, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x04, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x08, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_0 + 0x0c, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x00, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x04, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x08, 0));
BDEV_WR(BCHP_NAND_SPARE_AREA_WRITE_OFS_10 + 0x0c, 0));
BKNI_Sleep_tagged(20);
}
BKNI_Sleep_tagged(100);
}
Moral of the story is of course, with the genuine product you would have never had these kind of issues and thus that is ALWAYS the way to go!
These where my 2 cents
The situation is that we are having a situation that the Bootlog is deleted and the CHIP is write protected
So we have to find out if there JTAG possibilities,so please lets concentrate on that!
@omni ive read here and on the Ferrari forum you have some mtd files,do you have enough info or what else do you need more?
@smart did managed to extract the mtd0-mtd1-mtd2-mtd3-mtd4 files from his lonrus boxes he did upload this.
So what`s the next step?
Last edited: