From another site,

Posted by a mod,




September 13, 2006
Rev 10b in the stream
Filed under: News — mountaineer @ 8:39 am

For those all happy bout the change of events, don’t get your hopes up too high. You more than likely be in the same boat you were in this past June. My guess enjoy until friday of ths week but later than 23 of this month for sure. Word is dish will initiate 3 map calls instead of 1.

Dishnet REV10B update

; ** STREAM PACKETS **
21406DA0CA00006704650001820010EA7D44480379026F210D 08EF4F9A1C6C2D92D8CF7B210867AB083ADE6282FEF4297B5C DBD7D7FED5A58CF9F959CCC9B9920F84B0F33B210628E9EAEA B0EC18B8056C901483CE15ACC4CF1F204CC0F25909788AC72F F9F5D3442045CE937E36AF0237
21406DA0CA0000670465000182001015253376B0760105232D EDE94A3A2FF7EC645B0FF197F258C7CC3C43B7E3C3180B5AD6 4A720A6D10CA4DACB4CAEF52181B3CF5CDB6B2AA73C3E25AF6 6EF6AA139FEEA00EF046F0D62068580F019C5F2C86D4F4B68D C2DEB4495E70BB3A97E1250267
21006DA0CA00006704650001820010BDBFAC225ED55D82C674 F520D1F356166DC91242A3F61074ADAE9FF82D14C68D1EE2C4 FAEFF8F440AD592F768AA0BE2D0AFE372AE59D51E8817C315A 7B903C8C1A7F6E2B9D98787EA37544020A13F5AC9E97E05942 5E5117E5AC73115525B90802DC
21006DA0CA0000670465000182001087A4480C8A084ECA0F49 ADAF1B4D486F782A4058F05D346ACF3D83A9D546072331F169 BCF24F3285D47C8CD6DA150AC0B03DBB3ECF088ABC7C4F2CD8 C8B0AF7BAAE67E30813968830F8577E27801D8A9A1A00FBE50 6D30C81F77D58C3271F73902C6

; ** DECRYPTED **
21406DA0CA000067046500018200101ceb1e1b6b670c010001 14dc707f18717787e309104c340291d501000291d501000292 8c268383838383838383838383838383838383838383838383 838383838383838383838383838383e309104d050230d70141 0000000000000000000000
21406DA0CA000067046500018200100d0561844005f0080001 14dc707f18717787e309104e490291d7458a9ba602b748cd92 7ecd59da019080cd5ac00a00019003a6f888a6918888cc9121 905f5fa601b74aa690b74bd601a8aa01d701a83f48a618cd58 ecb64ab744b64bb745a607
21006DA0CA00006704650001820010189e00bd6abc4bf50001 14dc707f18717787e309104f4902921c45cd927ea618cd596b b64ab744b64bb745a603b748a63bcd927e3f48a60ccd927e90 5c90a302240b9fab2897a628cd58ec20b5a643cd927ecd5ac0 0190040040a644cd927ecd
21006DA0CA00006704650001820010624c3db2a3f960890001 14dc707f18717787e30910502f0292612b5ac001d0040040a6 44cd927ecd59da019080cd5ac0044401900286988788899089 8acd3840869085858481e30910510a0291d501070230d70142 0000000000000000000000

; ** BREAKDOWN **
21406DA0CA0000670465 0001 820010 1CEB1E1B6B670C01 0001 14DC707F 18717787
___E3 09 104C 34
______02 91D5 01 00
______02 91D5 01 00
______02 928C 26 83838383838383838383838383838383
_________________83838383838383838383838383838383
_________________838383838383
___E3 09 104D 05
______02 30D7 01 41
___00 END 00000000000000000000
21406DA0CA0000670465 0001 820010 0D0561844005F008 0001 14DC707F 18717787
___E3 09 104E 49
______02 91D7 45 8A9BA602B748CD927ECD59DA019080CD
_________________5AC00A00019003A6F888A6918888CC91
_________________21905F5FA601B74AA690B74BD601A8AA
_________________01D701A83F48A618CD58ECB64AB744B6
_________________4BB745A607
21006DA0CA0000670465 0001 820010 189E00BD6ABC4BF5 0001 14DC707F 18717787
___E3 09 104F 49
______02 921C 45 CD927EA618CD596BB64AB744B64BB745
_________________A603B748A63BCD927E3F48A60CCD927E
_________________905C90A302240B9FAB2897A628CD58EC
_________________20B5A643CD927ECD5AC00190040040A6
_________________44CD927ECD
21006DA0CA0000670465 0001 820010 624C3DB2A3F96089 0001 14DC707F 18717787
___E3 09 1050 2F
______02 9261 2B 5AC001D0040040A644CD927ECD59DA01
_________________9080CD5AC00444019002869887888990
_________________898ACD3840869085858481
___E3 09 1051 0A
______02 91D5 01 07
______02 30D7 01 42
___00 END 00000000000000000000

; ** PATCHES **
; REV10A_update_patch:
; disable module
$91D51 00
; update module code (clear old)
$928C=83838383838383838383838383838383
$929C=83838383838383838383838383838383
$92AC6 838383838383
; update last byte of rev to “A”
$30D71 41

; REV10B_update_patch:
; update module code
$91D7=8A9BA602B748CD927ECD59DA019080CD
$91E7=5AC00A00019003A6F888A6918888CC91
$91F7=21905F5FA601B74AA690B74BD601A8AA
$9207=01D701A83F48A618CD58ECB64AB744B6
$9217=4BB745A607CD927EA618CD596BB64AB7
$9227=44B64BB745A603B748A63BCD927E3F48
$9237=A60CCD927E905C90A302240B9FAB2897
$9247=A628CD58EC20B5A643CD927ECD5AC001
$9257=90040040A644CD927ECD5AC001D00400
$9267=40A644CD927ECD59DA019080CD5AC004
$9277=44019002869887888990898ACD384086
$92875 9085858481
; enable module
$91D51 07
; update last byte of rev to “B”
$30D71 42

** DISASSEMBLY **
91D7: 8A push CC
91D8: 9B sim
91D9: A602 ld A,#$02
91DB: B748 ld $48,A ; $48 = 2
91DD: CD927E call MapCall_ ; (02) set default size
91E0: CD59DA call ClearRAM
91E3: 0190 .dw 0190 ; dest
91E5: 80 .db 80 ; len
91E6: CD5AC0 call Copy
91E9: 0A00 .dw 0A00 ; src
91EB: 0190 .dw 0190 ; dest
91ED: 03 .db 03 ; len
91EE: A6F8 ld A,#$F8
91F0: 88 push A ; push F8 91 91
91F1: A691 ld A,#$91
91F3: 88 push A
91F4: 88 push A
91F5: CC9121 jp $9121

91F8: 905F clr Y ; Y = 0
91FA: 5F clr X ; X = 0
91FB: A601 ld A,#$01
91FD: B74A ld $4A,A
91FF: A690 ld A,#$90
9201: B74B ld $4B,A ; RC2 = 0190

:_LOOP_
9203: D601A8 ld A,($01A8,X)
9206: AA01 or A,#$01
9208: D701A8 ld ($01A8,X),A ; $01A8 |= 01
920B: 3F48 clr $48 ; $48 = 0
920D: A618 ld A,#$18
920F: CD58EC call ADD_A_to_RC2 ; RC2 += 18h
9212: B64A ld A,$4A
9214: B744 ld $44,A
9216: B64B ld A,$4B
9218: B745 ld $45,A ; 44:45 = RC2
921A: A607 ld A,#$07
921C: CD927E call MapCall_ ; (07) import [44:45] to MR_D
.
921F: A618 ld A,#$18
9221: CD596B call Sub_A_from_RC2 ; RC2 -= 18h
9224: B64A ld A,$4A
9226: B744 ld $44,A
9228: B64B ld A,$4B
922A: B745 ld $45,A ; 44:45 = RC2
922C: A603 ld A,#$03
922E: B748 ld $48,A ; $48 = 03
9230: A63B ld A,#$3B
9232: CD927E call MapCall_ ; MapCall_ (3B) ?
.
9235: 3F48 clr $48 ; $48 = 0
9237: A60C ld A,#$0C
9239: CD927E call MapCall_ ; (0C) export MR_C to [44:45]

923C: 905C inc Y ; Y++
923E: 90A302 cp Y,#$02
9241: 240B jruge $924E ; if Y
Comments (0)

You beat me to it Droc....was just going to post something similar...I found almost the same post on a diff site.
Yeah seems there is a lot afoot....Im sure it will be bad for the Fta units, but wonder what will happen with the Rom 102's How long until they will have a spoof for the 10b rev.

I would suggest anyone who does not have a rom 102 to possibly use, pull it and if you have a FTA laying around...get some use out of it while you can....before it becomes a doorstop again"unless you are really into REAL Fta"
I know it is testing but a little caution may go a long way this time.

Really curious what will happen with the CS aux cards, if they take any kind of Rev update or if the cards are ok...if so should be really interesting.....but if they do 3 map routines...then it might make the aux bin useless..but at least not update/lock the card Very interesting times ahead...but enjoy your FTA while you can....looks like snowy screens are coming soon

Well I dare say, that even if nothing happens and they go back to map 57... this has throw a big monkey wrench to those still working on a cardless bin for various receivers.

Plus, since this has happened, has anyone said they want to buy a viewsat now?

Just to shed some light over Viewsat fix....

The fix WAS BOUGHT! NOT CRACKED~

Just to shed some light over Viewsat fix....

The fix WAS BOUGHT! NOT CRACKED~

Ugh, lets not get back to this again...

It was only mentioned as "working on a cardless fix" ... which can mean many things ... this was left upto interpretation by the reader... which you obviously have some serious issues with still...

Let it GO.

No one cares if it was bought or 'appeared outta thin air'... the fact was there was only one stb up and running with a true 'cardless' fix during this, albiet short, map57 time...

Besides, your post is completely OFF point of this THREAD.

The was hope that FTA was NOT gonna be hit this time, but apparently this is not the case and BOTH plastic and fta are in for it.

This is doom and gloom news for everyone.

So are you guys saying that after they release this rev. there would be no more FTA and no one can ever crack it and release a new bin?

So are you guys saying that after they release this rev. there would be no more FTA and no one can ever crack it and release a new bin?


Only time will tell........

Devilman15 has a good question in that is FTA dead in a few days or will the Viewstats still be cookin?

as I have seen in the breakdown, 102 emulation will still work but FTA will be back to step 1.

They didn't changed the bugtable at all so maybe and I say maybe the old blocker will still work. Don't forget that there's a lot of FTA units compared to 102 emulation. That can explain why they are letting rom 102 users an "easy life" for now.

Time to see if all thoses Viewsat speech about having the full maprom was true or BS ...

Correct me if i'm wrong.

hey guys ,question, it might sound dumb but the local's be got too

Devilman15 has a good question in that is FTA dead in a few days or will the Viewstats still be cookin?

If viewsat has the full maprom like they said, Then it will likely be no problem.

But do they have it? Thats to be proven :mellow:

[QUOTE=jrogue]
It was only mentioned as "working on a cardless fix" ... which can mean many things ... this was left upto interpretation by the reader...

No one cares if it was bought or 'appeared outta thin air'... the fact was there was only one stb up and running with a true 'cardless' fix during this, albiet short, map57 time...

I dont want to flame any fires either,but it sounds to me like you are saying that VS never said or claimed they ever had the full dump of the 102.

They said they had it all,they said they did it themselves. and it was NOT left to the interpretation of the reader.

Unless you are talking about something different altogeather???:hat:

The point I was trying to make was that this thread is NOT about if viewsat "bought the fix" or "made it out of playdough".

This is a person trying to stir stuff... nothing more nothing less.

If we want to speculate about the longevity of FTAs or Viewsats in particular... Im cool with that.

But to make a statement like this


Just to shed some light over Viewsat fix....

The fix WAS BOUGHT! NOT CRACKED~


Does not add to this thread... Nor is it even remotely related to the topic of this thread.

Dougie Flutie fan, I agree with you (I went to High School with that guy:wow: )

They said they had it all,they said they did it themselves. and it was NOT left to the interpretation of the reader.


They did make this claim, but this is not what I was talking about in my original post... it was directed at "Egyptian Mafia".

'Egyptian Mafia' is trying to stir stuff by making that statement... where in the previous posts did anyone state that Viewsat 'cracked' the fix? ... nowhere.

I just dont want this to be a 'sign' of things to come ...
Where people make statements like this just to draw people into a battle...

IMHO, we are all going down... but that is not a big stretch to speculate is it?

Question is, how long before we get back up again?

I'll hazzard a guess that Viewsat will again be back up again... whether they "BUY it" or "grow it" ... I have no idea... thing is, money talks and they got lots of it tied up with new products...

so sure, we could be down for 2-4 months, but that is the nature of the beast...viewsat will be back for another round

Just my 2 cents

:beer:

i agree with you jrouge, i think viewsat will spend what ever it takes , and if possible will be up and running, viewsat seems to be planning to stick around for awahile, thats why they are comeing out with hd receivers in the near future, no one knows for sure how things will turn out but it does not hurt to wish for the best

Well Im beginning to wonder if VS didnt play one hell of a hand, and CS and PS just waited it out.
Remember CS stated they didnt want a partial Map fix but the WHOLE Thing.
Im sure VS, CS and PS had some inside info as to what might be coming down the pipe soon, or had a good idea of what it might be.

VS took a chance and released something and for a month really cleaned up with sales. But if they do a 3 Maprom Call this will prove if Anyone had the Full Map or just a partial. If it is just a partial then ALL the Ftas will be down, and if they didnt get a full Map read by this time....and they swtich 3 of them...well it will be a LONG time before they get it this time..IF ever.

And we are not even sure how the New 10b rev is going to do, or what will happen in conjunction with the new Maproms. So right now about the only thing that is sure is, If you have a good 102 card...hold onto it, it may be the only thing working soon.

Seems the Blockers for the 102's that had the B1 addressed seem to still be at Rev 09....so time will tell what will and wont work. But the FTA's will be down for a while once this happens unless someone really does have a FULL Maprom...it will be very easy to tell soon.

So lets enjoy it while it lasts

we will just have to wight N C

this is just a rumor

From another site,

Posted by a mod,




September 13, 2006
Rev 10b in the stream
Filed under: News — mountaineer @ 8:39 am

For those all happy bout the change of events, don’t get your hopes up too high. You more than likely be in the same boat you were in this past June. My guess enjoy until friday of ths week but later than 23 of this month for sure. Word is dish will initiate 3 map calls instead of 1.

Dishnet REV10B update

; ** STREAM PACKETS **
21406DA0CA00006704650001820010EA7D44480379026F210D 08EF4F9A1C6C2D92D8CF7B210867AB083ADE6282FEF4297B5C DBD7D7FED5A58CF9F959CCC9B9920F84B0F33B210628E9EAEA B0EC18B8056C901483CE15ACC4CF1F204CC0F25909788AC72F F9F5D3442045CE937E36AF0237
21406DA0CA0000670465000182001015253376B0760105232D EDE94A3A2FF7EC645B0FF197F258C7CC3C43B7E3C3180B5AD6 4A720A6D10CA4DACB4CAEF52181B3CF5CDB6B2AA73C3E25AF6 6EF6AA139FEEA00EF046F0D62068580F019C5F2C86D4F4B68D C2DEB4495E70BB3A97E1250267
21006DA0CA00006704650001820010BDBFAC225ED55D82C674 F520D1F356166DC91242A3F61074ADAE9FF82D14C68D1EE2C4 FAEFF8F440AD592F768AA0BE2D0AFE372AE59D51E8817C315A 7B903C8C1A7F6E2B9D98787EA37544020A13F5AC9E97E05942 5E5117E5AC73115525B90802DC
21006DA0CA0000670465000182001087A4480C8A084ECA0F49 ADAF1B4D486F782A4058F05D346ACF3D83A9D546072331F169 BCF24F3285D47C8CD6DA150AC0B03DBB3ECF088ABC7C4F2CD8 C8B0AF7BAAE67E30813968830F8577E27801D8A9A1A00FBE50 6D30C81F77D58C3271F73902C6

; ** DECRYPTED **
21406DA0CA000067046500018200101ceb1e1b6b670c010001 14dc707f18717787e309104c340291d501000291d501000292 8c268383838383838383838383838383838383838383838383 838383838383838383838383838383e309104d050230d70141 0000000000000000000000
21406DA0CA000067046500018200100d0561844005f0080001 14dc707f18717787e309104e490291d7458a9ba602b748cd92 7ecd59da019080cd5ac00a00019003a6f888a6918888cc9121 905f5fa601b74aa690b74bd601a8aa01d701a83f48a618cd58 ecb64ab744b64bb745a607
21006DA0CA00006704650001820010189e00bd6abc4bf50001 14dc707f18717787e309104f4902921c45cd927ea618cd596b b64ab744b64bb745a603b748a63bcd927e3f48a60ccd927e90 5c90a302240b9fab2897a628cd58ec20b5a643cd927ecd5ac0 0190040040a644cd927ecd
21006DA0CA00006704650001820010624c3db2a3f960890001 14dc707f18717787e30910502f0292612b5ac001d0040040a6 44cd927ecd59da019080cd5ac0044401900286988788899089 8acd3840869085858481e30910510a0291d501070230d70142 0000000000000000000000

; ** BREAKDOWN **
21406DA0CA0000670465 0001 820010 1CEB1E1B6B670C01 0001 14DC707F 18717787
___E3 09 104C 34
______02 91D5 01 00
______02 91D5 01 00
______02 928C 26 83838383838383838383838383838383
_________________83838383838383838383838383838383
_________________838383838383
___E3 09 104D 05
______02 30D7 01 41
___00 END 00000000000000000000
21406DA0CA0000670465 0001 820010 0D0561844005F008 0001 14DC707F 18717787
___E3 09 104E 49
______02 91D7 45 8A9BA602B748CD927ECD59DA019080CD
_________________5AC00A00019003A6F888A6918888CC91
_________________21905F5FA601B74AA690B74BD601A8AA
_________________01D701A83F48A618CD58ECB64AB744B6
_________________4BB745A607
21006DA0CA0000670465 0001 820010 189E00BD6ABC4BF5 0001 14DC707F 18717787
___E3 09 104F 49
______02 921C 45 CD927EA618CD596BB64AB744B64BB745
_________________A603B748A63BCD927E3F48A60CCD927E
_________________905C90A302240B9FAB2897A628CD58EC
_________________20B5A643CD927ECD5AC00190040040A6
_________________44CD927ECD
21006DA0CA0000670465 0001 820010 624C3DB2A3F96089 0001 14DC707F 18717787
___E3 09 1050 2F
______02 9261 2B 5AC001D0040040A644CD927ECD59DA01
_________________9080CD5AC00444019002869887888990
_________________898ACD3840869085858481
___E3 09 1051 0A
______02 91D5 01 07
______02 30D7 01 42
___00 END 00000000000000000000

; ** PATCHES **
; REV10A_update_patch:
; disable module
$91D51 00
; update module code (clear old)
$928C=83838383838383838383838383838383
$929C=83838383838383838383838383838383
$92AC6 838383838383
; update last byte of rev to “A”
$30D71 41

; REV10B_update_patch:
; update module code
$91D7=8A9BA602B748CD927ECD59DA019080CD
$91E7=5AC00A00019003A6F888A6918888CC91
$91F7=21905F5FA601B74AA690B74BD601A8AA
$9207=01D701A83F48A618CD58ECB64AB744B6
$9217=4BB745A607CD927EA618CD596BB64AB7
$9227=44B64BB745A603B748A63BCD927E3F48
$9237=A60CCD927E905C90A302240B9FAB2897
$9247=A628CD58EC20B5A643CD927ECD5AC001
$9257=90040040A644CD927ECD5AC001D00400
$9267=40A644CD927ECD59DA019080CD5AC004
$9277=44019002869887888990898ACD384086
$92875 9085858481
; enable module
$91D51 07
; update last byte of rev to “B”
$30D71 42

** DISASSEMBLY **
91D7: 8A push CC
91D8: 9B sim
91D9: A602 ld A,#$02
91DB: B748 ld $48,A ; $48 = 2
91DD: CD927E call MapCall_ ; (02) set default size
91E0: CD59DA call ClearRAM
91E3: 0190 .dw 0190 ; dest
91E5: 80 .db 80 ; len
91E6: CD5AC0 call Copy
91E9: 0A00 .dw 0A00 ; src
91EB: 0190 .dw 0190 ; dest
91ED: 03 .db 03 ; len
91EE: A6F8 ld A,#$F8
91F0: 88 push A ; push F8 91 91
91F1: A691 ld A,#$91
91F3: 88 push A
91F4: 88 push A
91F5: CC9121 jp $9121

91F8: 905F clr Y ; Y = 0
91FA: 5F clr X ; X = 0
91FB: A601 ld A,#$01
91FD: B74A ld $4A,A
91FF: A690 ld A,#$90
9201: B74B ld $4B,A ; RC2 = 0190

:_LOOP_
9203: D601A8 ld A,($01A8,X)
9206: AA01 or A,#$01
9208: D701A8 ld ($01A8,X),A ; $01A8 |= 01
920B: 3F48 clr $48 ; $48 = 0
920D: A618 ld A,#$18
920F: CD58EC call ADD_A_to_RC2 ; RC2 += 18h
9212: B64A ld A,$4A
9214: B744 ld $44,A
9216: B64B ld A,$4B
9218: B745 ld $45,A ; 44:45 = RC2
921A: A607 ld A,#$07
921C: CD927E call MapCall_ ; (07) import [44:45] to MR_D
.
921F: A618 ld A,#$18
9221: CD596B call Sub_A_from_RC2 ; RC2 -= 18h
9224: B64A ld A,$4A
9226: B744 ld $44,A
9228: B64B ld A,$4B
922A: B745 ld $45,A ; 44:45 = RC2
922C: A603 ld A,#$03
922E: B748 ld $48,A ; $48 = 03
9230: A63B ld A,#$3B
9232: CD927E call MapCall_ ; MapCall_ (3B) ?
.
9235: 3F48 clr $48 ; $48 = 0
9237: A60C ld A,#$0C
9239: CD927E call MapCall_ ; (0C) export MR_C to [44:45]

923C: 905C inc Y ; Y++
923E: 90A302 cp Y,#$02
9241: 240B jruge $924E ; if Y
Comments (0)

If this is truly a trace of the stream.............someone must own one hell of a 'Trace Tool' !! Dis-assembly of code in an EPROM/FLASH-ROM is one thing,
tracing at a data rate this fast and 'Trapping' I/O or routine calls is something else.
I have been in HDWR and SFTWR testing for 44 years.
Having a tool to 'Record' and analyze a data stream was not that difficult when the requirements were for 'Start/Stop' communication up to 9600 & up to 19.2 Kb.
RS-232C and Parallel interfaces were equally simplistic.

But, even with today's technological advances, I can not imagine doing a 'Snap Trace' of the data stream for the DN Xmission.
You would have to be a Developer in the Sat xmission industry, or a very wealthy 'Hobbyist' to afford such a tool.

If this has been accomplished, it would be a 'walk-in-the-park' for the Software Engineers to analyze a trace, do a dump, set their Processor emulator in single-step or procedure step mode and map out every program function in the encryption scheme.
Getting a 'Memory Dump' and dis-assembling it can not accomplish anything without knowing what changes are taking place in the Xmitted data at a given moment in time.......which is what a 'Trace Tool' would do.

I believe to this day that 'internal leaks' from the Software design engineers of the encryption schemes are responsible for the success of all FTA builders that "discretely advertise" the ability of these RCVRs to be able to receive everything that a provider Xmits.

Also, I am confident that a "LOT" of palms have been greased for promotional comments regarding certain Rcvr manufacturers.

Point being..........if the guys writing / reverse-engineering code for all the FTA rcvrs had access to a monitoring/tracing tool............everyone would be happy !

If this is truly a trace of the stream.............someone must own one hell of a 'Trace Tool' !! Dis-assembly of code in an EPROM/FLASH-ROM is one thing,
tracing at a data rate this fast and 'Trapping' I/O or routine calls is something else.
I have been in HDWR and SFTWR testing for 44 years.
Having a tool to 'Record' and analyze a data stream was not that difficult when the requirements were for 'Start/Stop' communication up to 9600 & up to 19.2 Kb.
RS-232C and Parallel interfaces were equally simplistic.

But, even with today's technological advances, I can not imagine doing a 'Snap Trace' of the data stream for the DN Xmission.
You would have to be a Developer in the Sat xmission industry, or a very wealthy 'Hobbyist' to afford such a tool.

If this has been accomplished, it would be a 'walk-in-the-park' for the Software Engineers to analyze a trace, do a dump, set their Processor emulator in single-step or procedure step mode and map out every program function in the encryption scheme.
Getting a 'Memory Dump' and dis-assembling it can not accomplish anything without knowing what changes are taking place in the Xmitted data at a given moment in time.......which is what a 'Trace Tool' would do.

I believe to this day that 'internal leaks' from the Software design engineers of the encryption schemes are responsible for the success of all FTA builders that "discretely advertise" the ability of these RCVRs to be able to receive everything that a provider Xmits.

Also, I am confident that a "LOT" of palms have been greased for promotional comments regarding certain Rcvr manufacturers.

Point being..........if the guys writing / reverse-engineering code for all the FTA rcvrs had access to a monitoring/tracing tool............everyone would be happy !


9ball..... Your post is why I posted this.... I know there are some people out there that really know what this is all about inside and out... your response is the response I am looking for.....


Doesn't that stream seem to make sense though???

Hmmmm, I wonder what the going price will be for Viewsats after the next round of hashes is done..??? I think I might just pick one up if the price is right...:yes: :lol:

Ok... so what's is the future... lets be realistic, Nagravision 2 could be cracked again... and maybe this time easier than the MAP 57 (as I heard this MAPs are going to be tricky but less complex than MAP 57).

But lets be a little bit futurists... maybe Echostar could part away from using Nagra 2 and ... maybe create a stronger crypto-system ... Nagra 3 for example or maybe totally parting from Nagravision to its own Enc System (as D-TV did!), this could be the next year!!! .

So ... the Underground FTA world could be dead after this?...

Is the IKS the only "reliable" technology in the future ???

Is this technology is able to crack D-TV... because is Key sharing thru the internet, to decode the packets to understand the data coming from the provider, it sounds theorically possible...!

But I'm not a High-Profile cracker (not even a low prof. one!! hehe) the Gods from this business could say something to this post...

Cheers

9ball..... Your post is why I posted this.... I know there are some people out there that really know what this is all about inside and out... your response is the response I am looking for.....


Doesn't that stream seem to make sense though???


The dis-assembly OP codes look like they may be valid.

Although, I never saw a 'POP' following the 'PUSH' instruction that was issued early in the instruction sequence.
Sooner or later that 'PUSH' has to receive a 'POP' from the 'Stack'.
Every 'PUSH' instruction in the code has to be followed by a 'POP' instruction, or the code will malfunction.

I will go back and read the dis-assembled code again, but I did not see a 'POP'.

Actually, after reviewing........there are two 'PUSH' instructions without a 'POP'




It's been a long time since I have done any coding.
And, I don't have the 'Instruction Set' for the processor in front of me.

BTW, does anyone in your 'circle' have the CS Processor 'Instruction Set' ?
Obviously, someone does.............given the dis-assembly shown above.

Sorry, I don't even know what Processor we are dealing with !!
Never been inside the box.

BUT..I WILL BE !!

The dis-assembly OP codes look like they may be valid.

Although, I never saw a 'POP' following the 'PUSH' instruction that was issued early in the instruction sequence.
Sooner or later that 'PUSH' has to receive a 'POP' from the 'Stack'.
Every 'PUSH' instruction in the code has to be followed by a 'POP' instruction, or the code will malfunction.

Not if one directly manipulates the stack pointer. Or one could push an address on the stack, jump to a routine and then execute a return from subroutine. Note that you did a jump, not a subroutine call. Executing a return from subroutine will pop the stack and start executing at whatever address you pushed on the stack. So, PUSHes should have corresponding POPs but it is not required for code to function properly. All that matters is that the programmer is aware of the value of the stack pointer at all times.

Not if one directly manipulates the stack pointer. Or one could push an address on the stack, jump to a routine and then execute a return from subroutine. Note that you did a jump, not a subroutine call. Executing a return from subroutine will pop the stack and start executing at whatever address you pushed on the stack. So, PUSHes should have corresponding POPs but it is not required for code to function properly. All that matters is that the programmer is aware of the value of the stack pointer at all times.

You are right Phant.........I stand corrected !!! The programmer can do ust about anything with his/her code...........as long he/she understands the execution sequence.

Boy, My head Hurts LOL

Boy, My head Hurts LOL

That is what testing is all about... Understanding the way the instructions are set in the code/stream and then being able to dis-assemble it, just like those guys are saying. I'm no coder but it kinda makes sense to me.