The above video goes away if you are a member and logged in, so log in now!
Scenix copy protection
Scenix copy protection –
Data sheets say the parts will read back garbled data if the protection fuses are set - For educational purposes, has anyone attempted to bypass this?
My parts are on backorder, so I get to have no fun while I wait. Is anyone interested in fooling around with this? I have some questions that will set the direction of possible attack..
1) Is the 'garbled data' different every time? A blank device with the protection fuses set would spit out the key, assuming that the garbling is done with an XOR. People love XOR, but another good idea would be to shift-register it, etc. Maybe a bad method of attack, since it would be easy to have the fuse disconnect readout completely and connect to some sort of 'puke' generator. IF they cared enough about protection to waste the space necessary for the size of a good puke generator. And for six bucks retail, that seems doubtful - maybe still hope.
2) The IC has brownout (undervoltage) protection, but what about overvoltage protection? A PIC 16 series can be unlocked by raising Vcc to Vpp-0.5v and writing the protection bits over and over. This is dangerous tho - may blow gates on this little process.
3) Is brownout on the magic enabled? Can anyone attempt to run a magic 3.1 at lower than 4.2v? The homebrew chips were tested at 3.3v, but those fuses were set by us, not the manufacturer. Vcc glitches were the downfall of the satellite cards, and those bad boys were DESIGNED to be attacked all day long in every country on the planet.
4) Worse comes to worse, one might try to find the location of those protection fuses and deposit a micron or two of 'jumper' to hardcode the protection off. It's really not too hard, chip designers do it all the time when they're trying to debug a mistake in a new IC. Anyone decapped a Scenix and took a look around? Anyone here work for Scenix/Ubicom or a competitor?
5) Who ripped the r16 code? how? Got an unprotected chip? Got the hex from a distributor? Or... Broke the Scenix?
IMO, keeping a fresh flow of code always advances the scene. Like the neo2 vs neo 2.2. Big damn improvement because people (like me) decompiled the source and made fun of the bad programming! Don't agree? Go check the dates on my Neo decompilations.. http://the_real_cableiso.tripod.com
1) the garbled data is exactly the same. on every chip. i tested this long time ago with the origa code.
i have an origa 1.10 chip, originally from origabrothers. works fine together with neo 4.1 as the famous neoriga combo, that boots everything inkl. dvd movie regionfree and macrovison off.
ok, i read out this otiginal origa and got garbled data.
then, i got the hex file of the origa code 6 month later. i programmed it into a sx 28. damnn, this fuses were heavy.... i got the hex file, but NOT the fuses. so, i tried to program the sx 28, set the code protection and read out the sx 28. i did this many times. and one time the code was 100% identical to the garbled data of the original origa, he he. succees, i haved catched the rigth fuses.
ther bad thing of that story is, nobody wants origa any more. all people love messiah chips..... and in V5 neo 4.1 and origa 1.10 are not working. so, nobody noticed that story......
later on, magic 3 homebrew scene comes.... and now, yes you are right, they use same fuses..... *lol*
the sx 28 protection can be hacked. there are companies, who do that for lots of $$$. they remove the cap and look with a microscope inside. because of that, channeltechnology used the ACTEL chip, which destroy the code by opening the chip.
you need a code? well, in the modchip business, the people buy just the code from the developer. a developer can sell the same code to 3-4 people. and you'll have 3-4 manufacturer. neo 4 code was sold several times. messiah code was sold. magic 3 code was sold...... it's business, nothing else for this people.
if you wan't more details, you should have enough money and then you can look behind the scene.
i have nothing to do with that. i have my ps2 and my xbox as hobby and i love the technik and the patching of this.
hmmm, interesting thougt. i never have tried this. i will verify this in the evening. but i thing, it will not work.
what i said is, if you have an original chip with code protection, you can read out the garbled data. if you read out 100 chips, you will get 100 times the EXACT garbled data.
now you have from somewhere in the internet a hex file. and you want to know, if this is the original code or not. so you program a chip with that code using protection.
then you can read out the garbled data of your self programmed chip. and when this garbled data matches exactly to the garbled data of the original chip, thenyou have the right code (which you found in the internet for example).
so, you can only VERIFY , if the code you got somewhere, is the same code as in the original chip.
you can not read out the code.
but..... i will try, what happens, if i set the right fuses and read out a before protected sx 28. i think, it will nor work, but i will give it a chance....
Amazing! Thanks, Frankieboy - that's incredible information!
Let me make sure I have this correctly... Two chips programmed with the same hex file will give the same garbled data???
That makes it nice for a developer to verify his data has programmed correctly, but it means the encryption formula (and key) has to be the same for every chip - not such a good protection! It probably adds up the hex file to get the key, and then uses that key to scramble the data.
How about this question:
In a 'blank' scenix, what is the value of a blank byte? Remember 00 does nothing when used in an XOR, and FF only inverts our original byte.
If someone would read out a blank chip to get a 'blank' hex file, and program that chip with only the first two bytes of the magic hex - would they get the correct first byte of garbled data? I hope not, that would be too easy!
also, what do you mean by 'the fuses were heavy'?
hard to program? or hard to find the right combination?
it was heavy to find the fuses. :-)
ok, i know some fuses, because of the use of the external oscillator and the soldering points. look in the ubicom datasheet. the other fuses i have had to try.
the important thing is, only the fuse is scrambled. the fuseX is not scrambled, he he.....
so, read out the garbled data and you know, you have the right fuseX read out. :-)
first two digts of the fuse are changed. 3. digit is also not scrambled.
but i have found out this to late...... anyway, now i know.....
you want to know, if red and blue magic 3.1 are genuine? or are they clones?
well, read out both. if the garbled data does not match exactly, it is not the same code......
I'm interested in the encryption they use... Can you do me a favor?
Program a scenix with all 00's, protect and read back the garbled data - then try all 01 and all ff. Upload some zips of the garbled readout if you can..
Here are three hex files filled with 00, 01 and ff in dummyhex.zip
And here is the program I used to generate them - if anyone else wants to load up some dummy files.
I think if red and blue are clones, they will have to contain the same data - someone is reading it out or has bought the code.
ok, here are some test results.
1) it is not working to re-program the fuse, when the copy protection is set. you have to erase the complete sx 28, otherwise no fude can be programmed.
2) your files are not loadable, because, the sx 28 uses 12 bit. first bit must be zero. 0FFF 0111 0222 etc.
3) buffer filled with 0001 0001 0001 0001 0001 etc. and copy protection gives as result the SAME 0001 0001 0001 0001 0001 etc.
4) buffer filled with 0FFF 0FFF 0FFF 0FFF 0FFF 0FFF etc. and copy protection gives as result WRONG 000F 000F 000F 000F 000F 000F etc.
5) buffer filled with 0111 0111 0111 0111 0111 0111 etc. and copy protection gives as result WRONG 0001 0001 0001 0001 0001 etc.
6) buffer filled with 0456 0456 0456 0456 0456 0456 etc. and copy protection gives as result WRONG 0007 0007 0007 0007 0007 etc.
7) buffer filled with 0ABC 0ABC 0ABC 0ABC 0ABC 0ABC 0ABC etc. and copy protection gives as result WRONG 000D 000D 000D 000D 000D 000D etc. (beware, it is a "D" and not a zero at th end).
ok folks, that is enough testing i think. result: the second and third bit are always set to zero. and the last bit is somehow calculated. it is encyption for only the command, no encyption over the whole code.
here is the output of the garbled modblak 1.0 code. it is the same. the second and third bit are always set to zero. the last bit is somehow calculated. the fuse 7F2 is set to 00A (see first line).
ADDRESS DEVICE BUFFER | ADDRESS DEVICE BUFFER | ADDRESS DEVICE BUFFER
0000FFF 000A 07F2 | 0000011 000B 0856 | 0000020 0006 0B6B
0000000 000A 005F | 0000012 0002 085F | 0000021 0006 0666
0000001 0003 0C0F | 0000013 000A 0831 | 0000022 000B 0B88
0000003 000C 0CFF | 0000014 0004 082E | 0000023 0004 02E8
0000005 000C 0CFF | 0000015 000B 0830 | 0000024 0005 0A1E
0000007 0005 0B3D | 0000016 000A 0820 | 0000025 0005 02E9
0000008 000A 0820 | 0000017 000A 0820 | 0000026 0007 0A1C
0000009 0001 084D | 0000018 000C 0CFF | 0000027 0006 02EA
000000A 0003 084F | 0000019 0008 002A | 0000028 0001 0A1A
000000B 0008 0844 | 000001A 000C 0CFF | 000002A 000C 0CFF
000000C 000E 0842 | 000001B 000B 0029 | 000002B 0008 002A
000000D 0000 084C | 000001C 000C 0CFF | 000002C 000C 0CFF
000000E 000D 0841 | 000001D 000A 0028 | 000002D 000B 0029
000000F 0007 084B | 000001E 0004 0765 | 000002E 000C 0CFF
0000010 000A 0820 | 000001F 0001 0010 | 000002F 000A 0028
ok, one important hint on my post before:
first line in my garbled output data is
0000FFF 000A 07F2 -> this is the fuse at adress FFF !!!
so, the Fuse 7F2 with copy protection gives the garbled Fuse 00A!
the Fusex is never garbled. it remains as it is.
Very interesting Frankie!! Thank you for your tests
oops! sorry about the missing bits in those files... but thanks for running those experiments - I think we may have found out quite a bit in one day!
At first glance, it looks bad - the micro throws away almost all of our data! but after a look over that modblak code, I had an idea..
If every 12-bit word gets calculated into one 4-bit hex letter, and the same instruction (like mov !rb, W) instruction always gets packed into the same "garble", we get a lot of information!
This won't work if only the 'mov' is encoded, but if (mov !ra, W) is a different garble than (mov !rb, W) - the thing is damn near broken already. All we need to do is compare the new release of garbled code against an old one - the matching parts we already have the code for, and the non-matching parts we know how many instructions are new... and the real instruction could only be one of the 3-4 instructions that the garbled letter matches!
Can you run one more experiment? Encoding different words next to each other to make sure we didn't get tricked because our data was all the same.
I think a string like
0120 0220 0121 0221 0122 0001 0ABC 0CAB 0000 0CAC.. then 0's to the end or whatever
would give us answers to all those questions. and hey, if only the instruction is encoded, we still know what parts have changed between each revision of the hex file!
Also, can you explain to me that hex file for modblak, to make sure we are both on the same 'page'..
It looks like you said 000A is the garbled data made from 07F2? so the second column is the garbled data and the third column is the real data?
If that is true, we are very happy. Address 007 encodes differently than address 009, and they contain the same end nibble ($D). Address 003 & 005 are the same, so x always equals y, and finally Addresses 00C and 00E differ by 1, and so do their encoding!
Next just look for patterns In the encoded data - everywhere 0C, 08, 0C 0B shows up it always means the same 4 instructions.. once starting at 018 and again at 02A