A little something for you sv guys - ABA DSS

**Beefeater1** · February 7th, 2009

Why Some Unit remain up while others go down with an ECM.

Now I'm sorry to say it's not because of the following reasons, (Smoke & Mirrors) or it's (MAGIC),it's all about the (MATH).

with every new (ECM) that comes down the stream after all viewsat go "AUTOROLL" and lose their signal. I also know you "test" every bin file available to see if it will bring up your viewsat alot like I do, but I don?t follow dates as you do. I personally try to see what the (stream log) tells me, and what MECM mapcalls is being used. Each mapcalls has its own bin file to fix processing "Audio" and "Video" Signals.

Under (Mapcall57) every mapcalls has its roots in this mapcalls and everything is made after this and used in making new mapcalls i.e.; oX03A, oXB3 and so on. Now what you're asking is why some receivers do work better, or hold up better than compared to 'Viewsat when it comes to a new "ECM" or electronic counter measures.

The answer is plainly; all bin files are based on the "Mapcall57" Code, which Viewtec owns after paying for. Now with that said, and since Cyphris has said' many times that the "Coders" are working hard in producing a "FULL and complete Bin File" that will not go down because of ECM's.
Which is bs to continue sorry about that now I have the "Source Code" from which the coders write ever new bin file from Viewtec, it (Incorporates only 256 known mapcalls) in each new release "A/R" Fix. This amount seems very large, but compared to the actual number of "mapcalls" that are used by DN, it remains small.
So what does this mean, and why? Does Sonicview stay up longer than Viewsat well its simply that sonicview incorporate more mapcalls tables than viewsat does, they will not allow there coder to uses more than the already known number of 256 tables. Why? Because they do not want any other fta manufacture from knowing how many map tables they have by reverse engineering there bin files.

So why do we not have a "FULL DUMP" File? Well I think most of you can guess it's all about MONEY!, nothing more. So I would think the only reason Cyphris even continues to post that type of rumors are for sales' to allow viewsat to continue sale to people with hopes they will come up with a fix that will last, or contain a fix for n3 codes, this of course is just hopeful thinking,

The reason sonicview and other boxes work on old file?s, are because they have incorporated more mapcalls tables into each bin file they released in the past. Where my Sonicview receiver has almost 800 mapcalls included in their files from "Oct", "Nov" and "Dec" 08, using something called; Montgomery Multiplication [ mapReg"A" = [ptr] * mapReg"M" ] coding. Now Map "A" is abbv. For ?Aladdin? and "M" is abbv. For ?Mervin? these of course are names of what type encryption DN is using at the time.

Note: this is not a Code, I just used this as an example to describe N2 codes used by DN.

Viewsat only remains with a set (number of 256), now old files on say "pansat" and "captive works" and of course other units contain several different amounts of these mapcalls, and so i.e.; will work on some versions of ECM because DN has only a set number they are now sending out at any one time.
The good news is that DN is no longer writing anymore "ECM" nor changing the map tables so what we see now are old version already used with just some modification made in the math.

So "BINGO" some older files continue to work with ECMs.

So does this answer why viewsat boxes need new bin files each time a "ECM" comes down the pike? well yes, because they simple will not change anything but the math involved, and their lies the problem. Without adding more map table numbers to each version of their bin files only a very few modified older files will work with some,(very few) "ECM"s. which one's I
One more point I want to make here, viewsat uses a single coder, not a group but sonicview does uses several people South Koreans as their coders. So by looking at each bin file for example: VS2000 "extreme unit" you will see after each date (PGM) that?s the coders name, no sonicview file has these after them that?s how you can tell if he wrote the file or not.

Since "Aladdin" N2 codes are still used and the new N3 encryption is still based on this code I do not think viewsat will just give it away. But there might also be another for reasons most people do not consider. Now if VS wrote a "Full Dump" code file was released, or say even 90% of the actual codes where put out in a new file, I believe some units would not be able to actual hold the amount of information involved, nor may not be able to full the full functions because of lack of CPU power, and Memory needed.

Also one more point, if 90% of the mapcall57 was used to produce a "full Dump" bin file then DN could finally write a new ECM to completely knock us down for good. Whether this is there legit reason for holding back, I personally do not know. But it's as good of a reason I would worry about if I owned the source Code.

**monoxid** · February 7th, 2009

Wow my friend that is a great explanation. Thank you for taking the time.

**marianne** · February 7th, 2009

thanks for the post i have a coworker who has a sonicview that stays up when my ultra goes down i guess i should buy a sonicview.

**Beefeater1** · February 7th, 2009

The info i posted above reasonably explains the sv's success in withstanding the last few ecm's (congrats to that great team) but unfortunately this technology will only apply to n2.....When n3 is fully in affect then all teams will start from scratch.

Lets hope its a quick game.

**morc68** · February 7th, 2009

mpeg 4 is showing up on 129 but is going to be switched to another sat soon my old DW9000 does 2+4 mpeg but is still a doorstop testing is gettin tougher

**slowboy** · February 7th, 2009

thanks for the info there

**FrankBokros** · February 7th, 2009

Thanks for a good info.

**asg** · February 7th, 2009

thanks for the info

**website_vandal** · February 9th, 2009

Roflmao .PGM is not the guys initials. PGM stands for "Portable Gray Map" and is a program understood by Adobe Photoshop and written in ASCII language. Which is what binary code uses. PGM files by nature are limited to 256 levels hence the limit on how much can be coded in the file.

Quote:

An ASCII text representation (which is extremely verbose).

Please Note:

For PGM files, when stored in the ASCII representation, there is a limit of 256 levels of gray.

Now I'm not a coder and don't know anymore then that. But I have dismantled .BINS with a hex editor and they are indeed written in ASCII code.

**MgGibson2** · February 9th, 2009

Awesome info Beef !!!!

I gonna start writing my own...he he he

!.A/ð!O$ö$@$û!.A/ñN!-O/ñ'N!.@/ñ@ÑqAòÑ"'!@q%ÿ¢`(@!-M/ñ!.A/ð!O$ö!.A/ñ$@!-N/ñ*@!-M/ñ"@!-E/ñ*@!-D/ñ"@!-A/ñ*@!-@/ñ(@!.H/ñ'OA/ñ"ð`¼/O,ý'OA#û/O,þ/O,ý&E@#û/O,þ@ÓsÓ'- @sù¢`/O,ý@#H#û/O,þ@ÓsÓ!"Lsù ¢`/O,ý(A#H#û/O,þ@ÓsÓ!"Lsù ¢`/O,ý*A#H#û/O,þ@ÓsÓ!"Lsù ¢`/O,ý*C#H#û/O,þ&A!ûÐp0Ñp1qàq0p1ô#¯/O,ý*G#H#û/O,þp1qàq0p1ô"¦/O,ý*K#H#û/O,þp1qàq0p1ô®/O,ý*O#H#û/O,þ/O,ýA'K#û/O,þ´"ð ÀxV4%ú2%úÁÀ £#ü@´'ù'ùÐ! —p0%ú9ÑZÒq!¢r1r0/õq`%úÑ¥rˆÒa.šp%ú0%ú3ð2õ`Œ#ü'ù`½%ú04ÑÒg @Ð$I!ûö"ðr¯@qàqQÑrDô%úÒ¢`"ðq1%úÑ0!¯q1$òô©q1q2q0$ú q0q2bqS%úÑ0 ¢a"ðpràrá@"ð@`¹@Ñ@Ò$ò#ò# D/ô$ö# D/õ$B!ûÚx,*%PÕx,*$^Öye‘x$ !/*"+quàvxdš¦AÑAÒ!zÓ@ÔÐAy0%ú4$ !/*#+—r¢c·"ð Aq,*$^ÒÓ $ !/*"-q,*%0"ð "ð"ð/G± @*ÀX*ÀÐ*ÀX*À”*À*ÀX*ÀÐ*À”*À AVMEM BOOT PIO0 PIO1 PIO2 PIO3 PIO4 PIO5 TBX UART UART1 UART2 EVT EVT1 BACK FRONT LLI PWM0 COUNT UART3 EMCASS1 À Ð à ð ¡ AUD0 HÉÀÌÀÀLÁÀPÉÀ0èÀ@èÀWÉÀíÀíÀOSD0? íÀBLASTER UHF CLKRV0 € ÿ ÿ ÿ ÿ ÿ èÀ ?ÿÿÿÿÿÿ[ÿÿÿOÿÿÿfÿÿÿmÿÿÿ|ÿÿÿÿÿÿÿÿÿgÿÿÿ ÿÿÿÿÿÿÿÿÿ€ÿÿÿ@ÿÿÿwÿÿÿÿÿÿTÿÿÿxÿÿÿ\ÿÿÿ>ÿÿÿxÿÿÿ@ÿÿ ÿ¿ÿÿÿ†ÿÿÿÛÿÿÿÏÿÿÿæÿÿÿíÿÿÿüÿÿÿ‡ÿÿÿÿÿÿÿçÿÿÿ ÿ ÿ ÿ |0À|0À|0À|0À|0À|0À|0À~0À€0À‚0À„0À†0Àˆ0 ÀŠ0ÀŒ0ÀŽ0À0À’0À”0À–0À˜0Àš0Àœ0Àž0À 0À¢0À¤0À¦0À¨0Àª0À¬0À®0À°0À²0À´0À¶0À¸0 Àº0À¼0À¾0ÀÀ0ÀÂ0ÀÄ0ÀÆ0ÀÈ0ÀÊ0ÀÌ0ÀÎ0ÀÐ0ÀÒ 0ÀÔ0ÀÖ0ÀØ0ÀÚ0ÀÜ0ÀÞ0Àà0Àâ0Àä0Àæ0Àè0Àê0 Àì0Àî0Àð0Àò0Àô0Àö0Àø0Àú0Àü0À1À1À"1À3 1À;1ÀD1ÀK1ÀV1Àj1Àn1Àt1À†1ÀŠ1À–1Àž1À£1 À·1À¿1ÀÆ1ÀÙ1Àí1À

almost there...he he he

**website_vandal** · February 9th, 2009

To add a little somethin' to my post

Quote:

PGMA to PGMB is an executable C++ program which converts ASCII PGM file to a binary PGM file.

I think this is actually the program they use to write the code but again I'm not a coder so I can't speak with a 100% certainty on that.

**tb1971** · February 9th, 2009

Great stuff, thanks Beef!

**monoxid** · February 9th, 2009

I think MgGibson got it better than any other. Great going.

span.jajahWrapper { font-size:1em; color:#B11196; text-decoration:underline; } a.jajahLink { color:#000000; text-decoration

ne; } span.jajahInLink:hover { background-color:#B11196; }

**website_vandal** · February 10th, 2009

Quote:

Originally Posted by Beefeater1

Why Some Unit remain up while others go down with an ECM.

So by looking at each bin file for example: VS2000 "extreme unit" you will see after each date (PGM) that?s the coders name, no sonicview file has these after them that?s how you can tell if he wrote the file or not.

OK this is driving me nuts here. Were you trying to say that the .PGM extension is the coders name or initials? Am I reading this right? Am I the only one that read this all the way through and noticed that?

richiemiami · February 12th, 2009

Sonicview and viewsat used to work together
Or I should say viewsat had information on all new projects that sonicview was working on that was until Viewsat cameout with the max and really pissed Sonicview off

If you remember correctly it was arround that time that sonicview starting having problems with file rumor was that viewsat's coders were pulled from sonicview. All you 360 premier guys remember the file that would not respond to remote commands that was the time in question

now sonicview seems to be doing well again and now viewsat is having issues

For those that went to the ces they saw viewsat unveil the twin tuner hd box again stolen from sonicview (their 360 hd). Now for those in the know it seems their a shortage of 360 elites (you can't find any in the last 3 weeks) well word is now sonicview is building their 360 hd twin tuner

r