Multirom Unlocker < here

thats pretty much the 64 thousand dollar question, there really isn't any evidence that an a86 is actually glitching in any expected way other than it runs the payload to unlock the cards.


i subscribe to the theory that a serious processor mishap during glitching is what initiates the jump to payload and maybe just about anywhere else that in many cases causes card death. i am not so sure the any hi or low byte is being glitched to return a $00, it is inevitable that at some stage during glitching that the effected byte will flip to $00 - a 255/1 chance infact, so that might rate the unlock chances in the realms of actually getting 255 successful bod unlocks lol.

now if someone where to sit down and work out the possibilites of jumps that could result from the glitch at that point, bare in mind that the possibility of interferring wth a critical card function may also be very high and indeed unrecoverable card death would seem more likely than unlcking it lol.

the risk can be brought down by testing over and over again, i finally myself settled on 150-200 delays as being the least likely to kill a card, chose glitchtypes that seemed more likely in testing to cause a payload jump on the powersync. but that was simply my own notes resolved into something workable like the doubletbc flash, my romscript and the powersync now sold my TMC.

but as i said it is not definative what actually is dong the damage, it is 100% certain that if a card can survive long enough in a glither capable of unlocking an a86 that it will unlock.

TBC
 
sshhhhh don't say that too loudly tbc :) the CC's might decide just to ditch nagra2 and settle for new rom10 revisions lol
 
:Laugh::Laugh:i woulod be rather more concerned about those modem firmware hits and that nvram dumps that were doing the rounds lmao
 
Last edited:
very nice mate, like the implication off the watchdog also. would you mind if i embeded xpatmel into it for my own personal use, or maybe you could do a public version with this included. great tool for beginners my mate will love this as opening a script confuses him in winexplorer.

thanks again
 
hi all - just some thoughts on the situation
thats pretty much the 64 thousand dollar question, there really isn't any evidence that an a86 is actually glitching in any expected way other than it runs the payload to unlock the cards.
the evidence is in the fact that the payload code is actually executed. this is the only way i can see that the card woulkd open.

i subscribe to the theory that a serious processor mishap during glitching is what initiates the jump to payload and maybe just about anywhere else that in many cases causes card death.
i fail to see how a serious processor mishap could cause the payload to execute m8. the only mishap could possibly be called the glitch. despite the number of cards looped it isnt that easy to software loop the card. only glitching in very specific places would cause this and ultimately changes to the card eeprom would need to occur in this event.
i am not so sure the any hi or low byte is being glitched to return a $00, it is inevitable that at some stage during glitching that the effected byte will flip to $00 - a 255/1 chance infact, so that might rate the unlock chances in the realms of actually getting 255 successful bod unlocks lol.
lmao - if i understand u correctly then we should be glitching each delay 255 times. the reason i laugh is because there arent any flips involved. effectively we dont want to flip any bits of the memory attachment register as this would give us values other than zero. for reading bytes of branches or jumps we need to glitch on the rise of the clock line and for writes it would be on the fall of the clock line. there is no comparative proof that we dont glitch the high byte of the operand so that we end up in lower ram but it seems the only logical explanation of the events. this is my opinion and the opinion of others far more technically advanced than myself.

now if someone where to sit down and work out the possibilites of jumps that could result from the glitch at that point, bare in mind that the possibility of interferring wth a critical card function may also be very high and indeed unrecoverable card death would seem more likely than unlcking it lol.
you have to remember that the databus is 8 bits therefore with the current glitch pulse timing we are either going to hit the glitch point and read nothing or the register will read the address and continue on into its normal flow of code. other non responses are in my opinion caused through glitching the wrong instructions. i admire ure tenacity but u have to look at the BOD script and ask what the big difference is and why we get so little looping.
the risk can be brought down by testing over and over again, i finally myself settled on 150-200 delays as being the least likely to kill a card, chose glitchtypes that seemed more likely in testing to cause a payload jump on the powersync. but that was simply my own notes resolved into something workable like the doubletbc flash, my romscript and the powersync now sold my TMC.
this is the nature of testing my friend :) and there arent many true testers around who really get to grips with the processes involved. ive only ever been asked once about the implications of the glitch command and why it actually works. i doubt very very few people spotted the significance of it however its used everyday and it workd well so people dont question it.


regards SK
 
my hypothosis for an ascertian that i believe that the bits could be set randomly is simple based on the idea that if you have an array of 8 logic gates and attempt to glitch them there is every chance that any number or none could be affected so although we see 8 bits which are processed simultaneously it is reasonable to expect that the electronic process that derives this state could be affected as though to alter the state of any or all of the bits. now i realise this could be a flaw in my own thinking (wouldn't be the first time you had opened my eyes sk lol) but it kinda fits the profile of the other question as to why certain glitchers seem completely incapable of actually making the glitch in the first place!


i also fail to see how a serious processor mishap could cause such a random series of events that lead to a fortuatous jump to the payload lol, indeed as i previously said the only evidence the the glitch works is the running of the payload and the opening of the card.

i would extend my hypothosis to the rom11 reliability for glitching as simply the card is far better made and thus the propogation characteristics are very much closer to identical. so we don't end up with a random scenario.

as ever i have to bow to your better knowledge but felt the need to state my hammy reasoning lol.

TBC
 
well my friend - u think very much as i did a while back.i asked a tester who is probably one of the best around why we couldnt just glitch a jump to the i/o buffer of the card. my thinking was due to the fact that we can easily payload the i/o buffer lmao. first the i/o buffer wont execute ops but at the time i wasnt aware of that. plus the glitch pulse width isnt really upto such an event as to hit specific bus bits.this of course is all relevant as the i/o buffer starts @ $0300. off memory it takes 5 cycles to perform a jump so loading the jump address takes only a small amount of a cycle to complete.
as ever i have to bow to your better knowledge but felt the need to state my hammy reasoning lol.
nah m8 - in my eyes you are a proven tester and need bow to nobody. i enjoy a chat with someone who has a desire to understand rather than watch TV lol.

SK

ps. i will get back to u soon on the payload stuff - just as per norm other things keep getting in the way.

pps. i wonder why we dont jump back to 9D? ive always wondered why rofl. heads up to sunrise for being the one :)
 
very nice mate, like the implication off the watchdog also. would you mind if i embeded xpatmel into it for my own personal use, or maybe you could do a public version with this included. great tool for beginners my mate will love this as opening a script confuses him in winexplorer.
thanks again


i have no objection in anyway as to how sidewinder is used collectively - of course that doesn't extend to me posting the source code.
i didn't beg borrow or steal one single line of code from anywhere else to write it, i simply applied what i know about glitching thus far and put it into code lol
borrowing of course the payloads and the relevant entry method from skyteams bod script and 'Sunrise' a86 payload. in order for me to embed xpatmel i would have to write my own source code lol so it infact wouldn't actually be xpatmel anymore!, this is tbh more than i would be prepared to do in the name of easy glitching as i feel sidewinder makes it pretty easy now lol.

tbc
 
Hi TBC
I'm keen to have a play with a few things this evening and Sidewinder is one of em.
Firstly I'm unsure what version to use? There seems to be 1.2a which seems most recent, but you did version 2 a few days before that..?
If it's not something you'd like to keep secret, then what way does this Sidewinder program work, as in.
Does it just do something like...
if card type is xxx and flashtype is yyy then choose script zzz and execute?
(I'm not even sure if the flash type can be detected when the looper is in glitch mode (or even flash mode at that))
And maybe you don't even use the scripting engine at all and have just ported the important parts of various scripts into ur code..
What card types exactly are supported?
What I would be afraid of is damaging a card if say the revision was not catered for (say it’s an uncommon blocker image or something) or if i had the wrong flash type...
I would presume the general rule of using T911 for ROM11 and the powersync for ROM10 still applies with the sidewinder program?
Thanks
CI
 
sidewinder isn't a script at all, it is an executable programme - it determnines not what flash type is installed but which glitchtypes the loader says are valid, the only ascertain it makes about as fars as card is concerned is wether it is a rom10 or rom11. if a card has a blockered image then the payload won't execute in most cases so it will just go round and round and not open.

it isn't finished by any means lol, far from it. i am working on more itteligent reasoning so the programme can become more self learning and efficient - but free time as always is the enemy lol.

tbc
 
Well i know it, i've been egging to have a go at the A88 aswell and it's only tonight i'll get to try your flash and script..
And tmc has sorted me out with a logger so I want to have a play with that too..

thanks for your reply.
ci
 
iv used the sidewinder to open 4 or 5 cards with no problems infact each card popped open in under a minute but im having problems with a rom11 bod now using the sidewinder, it wont go past the testing stage, i reverted back to an earlier version and it couldnt find a provider id is this wots causeing the sidewinder to stick on the testing stage, thanks in advance guys for any help given
 
you need to adjust your pot most likely, if the pot resistance is too low then it will stop the card from talking to the programme and the unlooper
 
you need to adjust your pot most likely, if the pot resistance is too low then it will stop the card from talking to the programme and the unlooper

iv read about adjusting the pot resistance but how do i do that, im using the t911 from tmc if that helps any
 
try turning it full anti clockwise as you facing the card reader
 
wen i turn it full anti clockwise sidewinder fails to detect a comport wen i turn it full clockwise sidewinder detects comport 4 then does nothing else, im running out of hair fast lol
 
post a comms log of the nagra report when you try to read the card!
 
Back
Top