Reply With Quotemate i hope that is not your HSN
logging info to share
hello
i want to share this info with you and i hope all to find answers
after logging for 3 hrs
the hsn programmed with gamma file for orbit on my card still working
examble
CB91929A000000307780CAF02D445C1FA37CD5ACECE60675C1 56D867AA560615C8B9251D10B67E559DDAC861E828E48373E6 F90B7FA98BA9
after i hit this data with gup loader
i got the provider changed to other
examble
after card programming 03F441
afetr hit the provider changes to 03F277
i tried to update the key in card still no joy
any hints
thanks
| Look Here -> |
mate i hope that is not your HSN
When you do things right, people won't be sure that you have done anything at all
lol it is not mine it is examble even mate i want you to know this hsn not in the log file evenOriginally Posted by best4less
mate i hope that is not your HSN
thanks
any hints guys
i am thinking if this logged data able to change the provider what calculation was applied to the card to change the provider
Yeah mate we are having the same problem you send the EMK line and it changes the prov00
When you do things right, people won't be sure that you have done anything at all
Hey B4L I wonder if they are sending EMM with correct signature but bad checksum.The sub card says wrong ckecksum and ignores it.
The whitey may do sigcheck but mightnt test checksum and lets it thru and it passes the sigcheck and updates to a bogus provid??
Heres another idea.Grab that string that stuffs the provid.
Corrupt the last checksum byte and send it to the card and see if it still does damage.
If it does then the whitey dont test checksums.
OR grab the string , and after the first lengthbyte I think you XOR each following byte with 3F and you should reach checksum.(same value)
That should test the string for checksum validity.
Its been a while but it works something like that .
Next corrupt a signature byte and send that to the card.
See if it sigchecks.If it does do checksum you will need to adjust the last byte.
Anyone else with positive ideas post away .
\
thanks alot oscar for your post i shall try and post here
cheers
Windows calculator in hex mode will do XOR for u
hello
i did this
I Corrupt the last checksum byte and send it to the card
in the examble
CB91929A000000307780CAF02D445C1FA37CD5ACECE60675C1 56D867AA560615C8B9251D10B67E559DDAC861E828E48373E6 F90B7FA98BA9
i changed it
CB91929A000000307780CAF02D445C1FA37CD5ACECE60675C1 56D867AA560615C8B9251D10B67E559DDAC861E828E48373E6 F90B7FA98BAF
seems whity not checking
and the provider changes
Well done mate
Now change the second last byte.That will corrupt the signature and see what happens.
it is accepting the chages gave in gup EMM Succsessfull
seems not cjecking last 2 bites
cheers
In your example, you are NOT changing the LRC Check byte
ie:
CB91929A000000 30 <- means 0x30 DATA bytes to follow
7780CAF02D445C1FA37CD5ACECE60675
C156D867AA560615C8B9251D10B67E55
9DDAC861E828E48373E6F90B7FA98BA9
the check byte is added when the stream EMM is convert to a card EMM and will also cover the 0101....... header.
I would expect the card is seeing an "invalid" packet, and just dropping it.
I've been also testing and if you change any Data bytes after 30 up to the first 16 bytes. The HSN number changes.
If you change the remaining bytes after the first 16 bytes.
In 95% times EMM Successful, the HSN remains unchanged while the provider number changes.
Is there a Hex calculator to achieve the correct known working provider that's read on other functional cards, i.e updated and working?
Just to confirm, when you say the first 16 Bytes, you mean any of these
7780CAF02D445C1FA37CD5ACECE60675 (from the example). and not the first 16 characters 7780CAF02D445C1F.
yes the following:
7780CAF02D445C1F
hello dear amr
nice to see you here can you comfirm that u change the provider after changing these 16 char
thanks
No the 16 char control your HSN number, i.e from your example 91929A, and if you change any char this will result in changing the active HSN number.
I changed the char after these 16 char and uploaded to card with GUP and reset card.
The HSN remains the same in more then 95% times and the provider number changes.
Try it and test, take another string from your logged data and past after the first 16 char.
yes amr provider changes but seems there is some hidden calclations to make the provider
if we got these calculation we can change it to working provider
btw i tried to change the HSN no luck i changed in the first 16 characters no luck to change it
Is there any software which calculate this 1Byte (8bit) checksum ?
cause i test with hex workshop and it gives me different checksum.
other softwares calculate many sort of checksums like MD5,.... but no 8bit
Oscar is right. The checksum is only for transport error detection, not tamper-proofing (that's what the signature is for). If the checksum in stream messages isn't right the CAM will discard them long before they get to the card.
All cards verify the checksum before going further as a basic transport error detection measure. That's a given. No emulator will ever omit the checksum test otherwise that makes discrimination by provider softcams trivial (and it's an oversight that a blocker could easily correct).
So card commands originating in the CAM (interrogation and camkey negotiation) will always have the standard checksum. Softcams testing card authenticity don't do it by checksum. Historically, when algorithms and private keys weren't always known, they did it by challenging the signature implementation, or during camkey negotiation, or exploiting discrepancies in error handling (eg unimplemented instructions or invalid parameters).
With gamma the code is unlikely to have much functional discrepancy, so you can bet the newer softcams are picking gammas by timing not logic. Clones will always be susceptible to timing attack of that kind (not to mention identity games which can provide an additional attack vector). Naturally the softcam won't show its hand by aborting communication straight away once the difference is picked, it will play along for a minute or so before shutting down. That should come as no surprise.
Posting Permissions
Bookmarks