WARNING (vu solo2 v3 users ) openvix Apollo build 25 & 26 is a clone killer

Warning anybody thinking of flashing these builds and doing a driver swap DON,T as it will kill your box and will need the flash chip replacein be warned lad,s, And for all the haters and i told you so i was running build 24 fine till these build,s were released ,tooshay to the openvix boys on that one :Clap: Not to worry i have a spare chip and the box will be up and running again tomorrow on openvix 24 again as i like to practice what i preach and i new the risk i was taken and i checked and i look at the change log on the site it did,nt state drivers or kernel were changed for solo2 so be careful lad,s regards dubliner

Many thanks mate

Yep all to do with the new kernel 3.0 I think so later drivers won't work with newer kernel and newer drivers have the timebomb..getting sticky.

AJT said:

Yep all to do with the new kernel 3.0 I think so later drivers won't work with newer kernel and newer drivers have the timebomb..getting sticky.

Click to expand...

I think you meant earlier drivers won't work with new kernel roud:

I'm sure pheonix mentioned this somewhere a while ago and a notice was placed a few days ago on vix forum about drivers being updated, etc:-

Please note that OpenViX Apollo builds 025 and 026 are on a different OE core (OE-A 2.3) from build 024 (OE-A 2.2) and many receivers have undergone Linux kernel and driver updates.

Click to expand...

so this means those already updated their boxes with v3 update tools & FPGA r not safe as we though coz V3 updated clones should be safe against timebomb new kernal original images, am i right?!

How did you do the driver swap?

Afternoon lad,s box is up and running again ;-) what happen was flashed original image Apollo 26 was usein 24 build was fine till then with driver swap, went through the basic setup then i connected internet got a ip for the box i did,nt reboot after flashing opened up DCC was able to get as far as ftp then the box locked up with in a minute of connecting the internet i knew straight away what was going to happen was not able to swap anything there,s something in the kernel 3.13.5 in 25 / 26 builds switch box off turn on again bricked again ;-) this was with the v3 flash chip firmware , So it,s no use with these kernel be careful lad,s , i,ve flashed BlackHole-2.0.9-vusolo2_usb_Ferrari_V3a to get the box up and running going to do the v3 upgrade then i,am good to go, regards dubliner

IAmATeaf there were the driver,s used on the the clone patched image openvix-Helios.017-vusolo2_usb from the VU-HD Site i was usein these drivers for a good while without any problem,s as the V3 flash chip firmware stop your box get bricked after the easter weekend timebomb ,but without the driver swap the box would,nt function right on original image ,as always this is at your own risk as i found out lastnite, as support for these box,s are pance, i,ve had more fun in a dentist chair then trying to get a straight answer from these chinesse seller,s regards dubliner

dubliner said:

...i,ve flashed BlackHole-2.0.9-vusolo2_usb_Ferrari_V3a to get the box up and running going to do the v3 upgrade then i,am good to go, regards dubliner

Click to expand...

Did you flash with BlackHole first to get box working or did you HAVE to replace flash chip and then flashed with BlackHole?

bbbuk no had to replace flash chip first then i flashed the blackhole 2.0.9 ferrari v3a as this image has the driver,s from before christmas and is safe to use and you can also use AJT blackhole 2,0.9 thank,s to him for that on vu solo2 v1 box,s, then i,ve flashed the v3 flash chip firmware then your able to use the images from VU-HD site these images will stop your box getting bricked if you update by mistake ,regards dubliner

Is the method you've described something you've done before? TBH since the TB booting with drivers newer than 24th December is not something I'd even consider doing. Maybe the v3 update will protect your box but as far as I'm concerned that's an accidental feature of v3 and not something that has been programmed hence why I wouldn't risk it.

Why do I say accidental? Because if it was intended then I'm sure the chinese could code so that newer drivers can be used but you can't.

IAmATeaf said:

...if it was intended then I'm sure the chinese could code so that newer drivers can be used but you can't.

Click to expand...

I thought that was this v3 was for in a way. It would detect when certain drivers was used and refused to boot thereby preventing the driver from doing it's job and wiping the flash chip.

It was easier to programme the flash chip (v3) to check what driver was being used and refuse to boot.

My guess is that the new OE core that requires the newer drivers to work, along with fact new Kernels has made v3 obsolete by either overwriting v3 flash or just stopping v3 from doing it's job.

bbbuk said:

I thought that was this v3 was for in a way. It would detect when certain drivers was used and refused to boot thereby preventing the driver from doing it's job and wiping the flash chip.

It was easier to programme the flash chip (v3) to check what driver was being used and refuse to boot.

My guess is that the new OE core that requires the newer drivers to work, along with fact new Kernels has made v3 obsolete by either overwriting v3 flash or just stopping v3 from doing it's job.

Click to expand...

My view is that this behaviour is an accidental side effect which is why I've personally never relied upon it to provide absolute protection.

Sent from my Nexus 7 using Tapatalk 4

IAmATeaf said:

My view is that this behaviour is an accidental side effect which is why I've personally never relied upon it to provide absolute protection.

Click to expand...

My view is that it was programmed like that on purpose and did it's job until the new OE core/drivers and Kernel update came along.

There is never any kind of absolute protection anyone could do including the chinese to prevent a clone bomb, they can only do things to minimise the likelyhood of a clone bomb working.

Whatever the chinese or anyone did to detect clone bomb attempts via drivers, VU (in this example, but equally applies to any manufacturer) can just programme their drivers to fool whatever clone bomb protection is in place.

It's a similar nature now with viruses/malware writers who manage to fool/circumvent anti-virus/malware software to still do damage.

Nothing is guaranteed to work and anyone wanting guarantees need to buy original.

bbbuk said:

My view is that it was programmed like that on purpose and did it's job until the new OE core/drivers and Kernel update came along.

There is never any kind of absolute protection anyone could do including the chinese to prevent a clone bomb, they can only do things to minimise the likelyhood of a clone bomb working.

Whatever the chinese or anyone did to detect clone bomb attempts via drivers, VU (in this example, but equally applies to any manufacturer) can just programme their drivers to fool whatever clone bomb protection is in place.

It's a similar nature now with viruses/malware writers who manage to fool/circumvent anti-virus/malware software to still do damage.

Nothing is guaranteed to work and anyone wanting guarantees need to buy original.

Click to expand...

You are reading far too much into the newer OE-A core update, these updates are primarily just updates from the official Open Embedded GIT an contain library updates.

The issue here is solely down to the new Kernel and drivers as released by Vu+ some weeks ago, as all drivers built for this kernel contain the same clone bomb that was released in Easter. The cheat people were using by swapping old drivers to the newer images simply will not work as this new kernel can not run those old drivers because they were built for a older kernel.

This is not a new thing it was true of the kernel update that took place for the Vu+ Duo from 2.6.18 to 3.1.1 some two plus years ago and will still be true the next time they update the kernel. It is also true of all manufacturers.