radxnl

here you go, 2 improvements:

EXTRA_OEMAKE = "CROSS=${TARGET_PREFIX} \
OSCAM_BIN=Distribution/oscampli4 USE_LIBUSB=1 LIBUSB_LIB='${STAGING_DIR_TARGET}/lib/libusb-1.0.a -lrt' \

 

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.

 

on your linux system start with:

 

cat /dev/ttyUSB0 to see if your access rights are setup correctly ( default distro installation sometimes requires root only access ( = bad ) to serial ports )

i just build 1.2.2 base, good and bad without any major problems

 

steps needed are to update remote repositories ( 1.2.2 was added recently, openpli is not up to date... yet! )

 

make to use new orc version and just build gstreamer1.0 etc etc

 

maybe i will push a new branch when i have time with all (even though they are minor) fixes.

als het goed is heeft ie vandaag gelopen, morgen resultaat

I am afraid this will bloat the drivers considerately. I hope at some time new drivers will get released without the FPGA update. OTOH maybe it's just a small piece of code.

 

it doesn't matter, before last the fpga firmware code was inside the fpga_directc.ko, now it's inside the dvb-bcm7356.ko, so pound for pound the outcome is the same

 

the funny thing from this version is the clone protection function ( brcm_fpga_timebomb() and brcm_fpga_secu_random_timebomb() )

 

guess what that does

morgen in de feed met net5 en veronica

Kijk, mooi ben benieuwd, je stopt hem in de ug app?

Had zelf nog niks getikt. Ik was nog op zoek naar de echte urls.

 

ja morgen staat ie in de feed

ik waarschuw bij deze maar een keertje dan, niet dat je weer boos wordt

 

ik heb inmiddels alle programma's werkend ik moet alleen nog een menutje ervoor maken, hopelijk lukt dat vandaag nog.

 

ik gebruik geen rtmp of dat soort dingen maar gewoon de 'echte' url

 

die https van sbs zuigt gelukkig zwaar dus de sessie was vrij eenvoudig te decrypten, een correcte url zit er uiteindelijk zo uit

 

 

http://l3c.cdn.sbsnet.nl/ra/01/170952b8e7c18d1a349fd030e0b415c6872464/hls/sbs6_wegmisbruikers_S00E267_130929224124170952-hls-main.m3u8 

en die laat zich prima met gstreamer afspelen, hij start soms het eerste blok ( a ongeveer 10 sec ) in een iets lagere resolutie maar daarna is het altijd 868x488

 

groeten

 

// edit, kleine typo

ik heb vanmorgen de boel al geupdate, morgen even updaten en dan zou het weer allemaal moeten werken

nee zelfde stand alleen meer anti clone zooi

telnet

opkg install python-subprocess

De BBC is het zeker niet ( die zitten echt niet te wachten op open markt boxen die waarschijnlijk ook nog zonder hun mooie reclame hun dure streams afspelen ), dus waarom denk je dan dat ze het licht gezien hebben?

// Edit Henksat was me voor

jawel het is wel opera, hij was al te testen voor 'intimi' sinds 5 juni. wel leunen ze op directFb voor de gfx rendering ( vind ik zelf niet echt een goeie keus maar dat is persoonlijk )

groeten

uit mijn hoofd, dus geen garantie

echo 0 > /proc/stb/lcd/oled_brightness

of anders

echo 0 > /proc/stb/fp/oled_brightness

groeten