Posts by ilikenwf

    As suggested by fairbird, let's talk about and try to reverse the MTN/Anuvu nano 01 hash method...it has been suggested some Chinese boxes can decrypt this but I don't think this to be the case; I have also yet to determine what equipment is used officially by MTN or Anuvu to watch these feeds.


    See the attached dump of PID 0x177c - fox news.


    With ncam, the EMM is decrypted properly on 34.5W here, however black screen and occasionally I hear 10-100ms of audio before it drops. It appears the keys are changing every 1 second.


    I have the MTN EMM keys that are floating around - either those, a constant, or the Fox News keys that used to be in use allow me to get this far, but it's not quite right due to EMM hash method 01:


    Code
    2025/04/01 15:16:24 3C36238F c      (ecm) linuxsatsupport (P: 0E00::0067:177C:0000 #ECM_L:48 #CW=04C1BFE6B95815CB0000000000000000 HOP:00): found (1 ms) by Device_SoftCam (L/1/2/2) - FOX NEWS (lg)
    2025/04/01 15:16:25 3C36238F c      (ecm) linuxsatsupport (P: 0E00::0067:177C:0000 #ECM_L:48 #CW=0000000000000000577FE0B03137F8FD HOP:00): found (1 ms) by Device_SoftCam (L/1/2/2) - FOX NEWS (lg)
    2025/04/01 15:16:26 3C36238F c      (ecm) linuxsatsupport (P: 0E00::0067:177C:0000 #ECM_L:48 #CW=6223709176E945A70000000000000000 HOP:00): found (1 ms) by Device_SoftCam (L/1/2/2) - FOX NEWS (lg)
    2025/04/01 15:16:27 3C36238F c      (ecm) linuxsatsupport (P: 0E00::0067:177C:0000 #ECM_L:48 #CW=0000000000000000926192D9D0082AF8 HOP:00): found (1 ms) by Device_SoftCam (L/1/2/2) - FOX NEWS (lg)
    2025/04/01 15:16:28 3C36238F c      (ecm) linuxsatsupport (P: 0E00::0067:177C:0000 #ECM_L:48 #CW=EAA1C4CEBAA18C6D0000000000000000 HOP:00): found (1 ms) by Device_SoftCam (L/1/2/2) - FOX NEWS (lg)



    Previously, EnoSat Posted this, which may be of help/interest?



    classic nano00 - 20 0E 00 00

    Code
    81 30 3D 30 37 20 0E 00 00 00 00 C7 B0 00 10 51 82 19 32 24 21 8A 65 33 33 E5 42 3E 00 40 E0 09 00 68 83 92 07 22 A7 0C 93 5F 35 57 0C 95 54 3E 68 CA DF BD B3 10 B1 0F EB 55 24 90 FB 16 31 70

    new nano01 - 20 0E 00 01

    Code
    81 30 3D 40 37 20 0E 00 01 00 00 D4 B0 00 B4 E2 97 77 76 DB 39 77 AD B4 6C 47 09 E4 00 40 F0 15 40 4E 8C 7F 86 A7 38 B3 9E A8 C7 A0 52 6F 80 1A 2D 3E 27 D1 69 36 7B 3D E1 A0 18 63 8E 6D 95 D3

    Discovery - 20 0E 00 XX - dynamic change

    Code
    80 30 45 50 3F 20 0E 00 8D 08 A1 BB 35 15 1E 44 E0 EE 00 0D B0 00 38 B6 9A 3E EE 2D 60 5F B4 3E 63 31 50 89 5C 10 F0 09 00 2D 60 41 05 A1 5B A6 56 9D 0B DF 95 18 07 29 79 AD 74 CE 8E 18 1C 7D AF 33 5F 2C 59 56 B3 34

    PS: I can someone verify the FOX package?

    FX.jpg

    And is this powervu+ or something else? I get little bits of audio and a black screen...34.5 MTN/Anuvu mux:

    Public OSCAM-EMU does not contain Hash (ECM) support for MTN


    I'm using ncam. Is there a patch somewhere? Happy to change to oscam-emu if there's a private build or a patch for me to compile with.


    And is this powervu+ or something else? I get little bits of audio and a black screen...34.5 MTN/Anuvu mux:

    Public OSCAM-EMU does not contain Hash (ECM) support for MTN

    Or if there's a private build or version one can acquire, please do tell.

    And is this powervu+ or something else? I get little bits of audio and a black screen...34.5 MTN/Anuvu mux:


    Found these on another site. I'm barely hitting 34w through some trees so I can't really watch, but can confirm this works for autorolling AFN...


    For lightning in the RG6, I have gas tube surge suppressors with their own grounding lines, grounded to the house. I've checked the resistance between my RG6 and the house ground and it's well below even "acceptable" ranges for voltage differential in the ground.


    The house has a whole house surge protector with noise cancellation, and then the mover, tv, htpc, and satellite receiver are plugged into a sine wave UPS which also has built in surge suppression.

    My dish is on a steel pole, 3 feet in the ground. Because I can test the ground between the house and the dish using the RG6 shielding, I know that it is all properly grounded. I have not (yet) put a separate rod at the dish itself because it doesn't seem very necessary. I also read it is better to put the arrestors on the house side instead of the dish side.


    I have a quad LNB mount on my 10 footer, all 4 of the LNBs connect to a switch that is bonded to the pole and thus also grounded. I could put an arrestor between the switch line out and the coax, but since there is one on the other end, I don't see the point?


    I'm using the same arrestors you are, though mine have the grounding connector and are grounded to the shared house ground...


    The Ku LNB is an inverto pro, the C lnb primary is a Titanium Red. The other two LNBs are cheapos, one is so I can still try to get the ones lower in the spectrum, and the other is for circular feeds.


    My Zgemma is on the same coax, and has survived similar hits, but I didn't even have actual lightning strikes upon my dish - just lightning overhead and around the area - there are plenty of taller things around and the lightning has yet to even hit the huge oak tree in my neighbor's yard. This is why I believe that the actual EM fields generated by the lightning flying around is what's doing this, and not any actual current through any of the wiring.


    I do have a TBS card and have partially gotten Neumodvb working with that, but not fully yet. In addition, the Zgemma can blindscan, albeit slowly, and not at as low of symbol rates as the Octagons, at least with the dev builds of OpenATV...


    My two receivers didn't have any front panel issues; in fact, they were working fine one minute; then during a storm they'd suddenly power off entirely and never come back on again. I got them both from Rick and even he tried to revive one of them without any luck.


    Because Rick is very close to me I'd love to find a way to declare my setup safe enough to buy another SF8008, but because I think they may be flawed or that perhaps their wall warts don't like US wiring with the adapter (though I did use a normal US power brick once too and it worked fine...and all the power bricks still worked after the SF8008s died so I guess not)...

    I sent one to Rick, and he shipped it back to Octagon. I shipped one back to Octagon myself but because DHL in Germany is awful, it is currently lost and they aren't responding to my inquiries. The Octagon guys are certainly friendly and do want the unit to look at, but at this point I have no idea if it will ever make it there or if I'm screwed.

    I loved my Octagon SF8008 supremes for their signal quality and blind scanning and nvme slot. What I did not love is that despite having proper surge protection and lightning arrestors and good grounding, both of them died during thunderstorms. My Zgemma H7S is still doing fine and has had several thunderstorms pass while in use. I suspect the Octagon SF8008 has a design or shielding flaw.


    I tried to return one to Octagon (I am in the US) and it is currently lost by DHL Germany. I am very likely out of luck and thus out $200 for the receiver.


    For blind scans and signal processing quality, is there any other E2 receiver that compares to the Octagon SF8008? I know that some of the Ustym units are Octagon clones or made by the same factory, and I suppose this may be an option but if they are the same board, they probably have the same flaw.


    I am looking for an E2 box that is as capable or more capable than the SF8008, specifically for blind scanning and signal processing quality, without the flaw that causes it to die from wireless EMI - I don't care who makes it. Any suggestions?


    Thanks!

    I have had two SF8008 supreme boxes and I love them except for the fact they die any time I have a thunderstorm.


    I have spark arrestors, surge protection, and the LNBF, switch, positioner are not affected, so lightning is not striking the box, but EMI from lightning seems to make the SF8008 die (bad shielding?). My old zgemma h7s has not this problem, but it is old and slow compared to the SF8008 tuner.


    What other boxes exist that have the same or better capabilities? I suppose another option is TBS + headend.

    So the issue seems to be with OpenATV 7.5. On multiboot I went back to my 7.4 setup and it works now.

    I do think something's up with 125W. It used to decrypt easily. ncam thinks I have the valid keys, but I apparently do not as I am not getting audio or video.


    Code
    2024/08/06 19:01:47 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=00000000000000007F101310B383EAB6 HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:47 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=C7B61F86670E07FE0000000000000000 HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:48 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=00000000000000003458ADA89D40983B HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:49 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=1C01385B4C01F28F0000000000000000 HOP:00): found (0 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:50 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=0000000000000000863E549EA8941F4F HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:51 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=C28675DA79E3BF980000000000000000 HOP:00): found (1 ms) by Device_SoftCam 

    I do think something's up with 125W. It used to decrypt easily. ncam thinks I have the valid keys, but I apparently do not as I am not getting audio or video.


    Code
    2024/08/06 19:01:47 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=00000000000000007F101310B383EAB6 HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:47 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=C7B61F86670E07FE0000000000000000 HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:48 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=00000000000000003458ADA89D40983B HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:49 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=1C01385B4C01F28F0000000000000000 HOP:00): found (0 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:50 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=0000000000000000863E549EA8941F4F HOP:00): found (1 ms) by Device_SoftCam (P/3/3/3) - History East S (lg)
    2024/08/06 19:01:51 688AB28E c      (ecm) dvbapiau (P: 0E00::0016:1773:0000 #ECM_L:40 #CW=C28675DA79E3BF980000000000000000 HOP:00): found (1 ms) by Device_SoftCam 

    I think 4100H changed keys on 101W.


    Just to clarify, should ncam find the new EMM keys if I just leave it on that TP for a while?


    Edit: it just did...


    P 3101FFFF 00 E2ABD10FB64EC9 ; added by Emu Tue Jun 4 03:01:44 2024 UA: 0052254D

    P 3101FFFF 01 FA7EF5F76E86F8 ; added by Emu Tue Jun 4 03:01:44 2024 UA: 0052254D


    So is there a faster or better way to do this? I have nice hardware, including some cuda gpus and servers at my disposal. I know PVHE exists but does it even work any better? Is there a script or plugin to automate, at least, zapping between tps at night to find keys?

    I've tried on both my Zgemma and my SF8008, but despite having the package installed, and even when stopping all processes accessing /dev/dvb I still get this trying to use dvbtraffic:


    Code
    root@sf8008:~# dvbtraffic 
    dvbdemux_set_pid_filter: Invalid argument


    Aside from TV I enjoy playing with data, and this makes it exceptionally hard to do so. Thanks!

    I'm guessing it has to do with the 5G NR rollover. I'm guessing the sub-4ghz NA transponders will eventually be switched to other higher frequencies or disabled as stuff gets rearranged to fit the new bands...since Verizon is taking over a chunk of the c-band.