Found this the other night thought it might come in usefull for someone. Translated from italian
UPDATE THE HAND CARD
Thanksgiving WebJoker that wrote the tutorial 01/08/2011 and now carry.
I hope to please by opening this thread that maybe can be a reference for those who, like
me, they want to try to have more control over what happens in their own decoder.
To update the card in $ KY little hand first you need to log the EMM that come from the sky. There are many ways to do this, but here we are on the site of oscam and I'll take care of how to do it with our favorite cam!
As many of you already know, oscam has an option to be included in each card reader (file oscam.server) that is called SAVENANO.
Setting savenano = all, ALL EMM direct to your paper will be logged to a binary file
(Readerlabel.bin) or on a text file (readerlabel.log).
The files are usually located in the same folder where the settings are entered as (oscam.conf,
oscam.server and oscam.user for instance), unless you specify a specific path in the file oscam.conf by parameter emmlogdir.
There are currently two problems with this option though:
1) Duplication of data in a bin file and a text file takes up space unnecessarily,
2) Lately sent mountains of EMM-G (useless for our purpose) but which are cm ² stored in the file and fill flash decoder in a few hours.
If we do not use a hdd and we are only interested in updates, then we can change the function
which handles the emm in oscam, either login only for the EMM-U and save them only in a binary file.
I choose the binary file, because there are mountains of software that let you read and then filter the log this type (tritalogNDX, LogJMS and my NDXLogTool).
Report below the detailed configurations to fit into your reader mode oscam + dvbapi
X Settings to log with oscam dvbapi:
blockemm-u = 1
blockemm-g = 1
blockemm-s = 1
blockemm-unknown = 1
savenano = all
You must have at least one user with AU = 1.
Once you have a log file, you can use a program to filter and extract only the EMM that
have a specific byte of LENGTH. For the record, currently updates sent from heaven have LEN following in hex: 22, 32 and 42. To be an upgrade is usually conveyed with a len 32 for 0919 that does not have the service tier 000B. As for the other cards, or is sent to a len 42 (which is all the updates that the service tiers 000b) or by means of two ins: a slowly upgrading 22 only the 000B and 32 which updates the tiers to which we subscribe.
Why is this?
Probably a matter of compatibility with the past ... Also because they do convey the len 22 also deactivations, so if the card is expiring touches to go with leaden feet!
CAUTION:
The EMM stored in the log of oscam are "precam", so normally there is only your EMM
inside.
What does this mean?
In NDS, the EMM precam are a block of bytes starting with 82 XX YY ZZ where:
1) the first byte (82) indicates that it is an EMM (while 80 and 81 indicate ECM),
2) the second byte (XX) indicates the type of EMM contained in precam: XX can be worth 00 or 10 in the presence EMM-G, XX = 30 (ins directed at specific UA) or XX = 70 (premium) for EMM-U, etc. ...
3) the third byte (YY) indicates the length of precam in hexadecimal, or how many bytes are to follow
YY ... (author's note: precam total is then a long YY +3).
4) the last byte (ZZ) indicates how many EMM 'post-cam' are the entire contents of the block precam: ZZ = 10 means say "no serials" - ins to direct public all the cards, ZZ = 40 vuoldire only 1 EMM, ZZ = 50 there are 2 EMM, ZZ = 60 there are 3 EMM, ZZ = 70 4 EMM ...
To understand better this is an example of parsing an EMM that contains two precam ins for two card
different.
8230695000AC8B280132623B0000D302002290204402AA44BE63C77F8639D8F350CB8422BADFD5F114EB
A3C0B6CC36A1C067AFCF00DB020032903044038E27D78CF3
823 069 (50) <<< 50 means 2 EMM
00AC8B28 = UA before SC
0132623B = second UA SC
0000
D30200 here are the specific ins on the first UA (len has 22 hex)
(22) 90204402AA44BE63C77F8639D8F350CB8422BADFD5F114EBA3C0B6CC36A1C067AFCF
00
DB0200 is below the ins on the second UA (len has 32 hex)
(32) 903044038E27D78CF356EAF66828316B52E6C237E1DC24BDB03613EC2C1E378063A996EAE3B172373F
0CDB52DA73DEF13856
00
At this point, imagine that your card is the latter, then you have to take the bytes 32-56, and
add us D0420000 head. Then the yourins from send a paper means smartmouse will
D0420000 32 90 30 44 03 8E27D78CF356EAF66828316B52E6C237E1DC24BDB03613EC2C1E378063A996EAE3B72373F0CDB52DA73DEF13856
If the update is unsuccessful, you will have an answer 9081 or 9181 (in the case going to write
something in ROM).
If instead responds 9080 means that the date of the tiers of the card before sending the ins was the same as that contained nell'EMM. I forgot to send the ins via smartmouse there are several programs I normally use NTSite ... look for it on google.
How to check if the ins is actually well-formed and not garbage, take heed that follow
byte len (32, 22 or 42 that is) there are byte 90 and byte LEN-2 (30, 20 or 40 depending on the len you are using).
Updates are sent encrypted using the nano 90 with nano-ins and a 90 always has this form
D0420000 (LEN) 90 (LEN-2) (XX) (YY) BODY DATA ENCRYPTED.
Where:
1) the byte LEN indicates the number of bytes that follow from nano 90.
2) The 2-byte LEN indicates the remaining bytes to follow.
3) XX is the byte that indicates the type of key used to encrypt the payload of nano 90 (40 = public key, 44 = private key)
4) YY indicates the type of card it is geared to the ins (02 = 0919, 03 = 093B, 04 = 09cd).
NOTE:
Above I described the manual procedure to create an EMM "post-cam" that they can send via smartmouse / smargo, once you have located the precam of our interest; if you do use various tools
processing of logs, they will do this automatically for you, just that programs behave different. The suffix Dx420000 for example in the case of tritalogNDX is D1420000, while in the case of NDXLogTool is inserted D0420000.Sono correct both, are just two classes of ins different.
Read the Bible? Ezekiel ... er .. Fabar83 ... 25:17 ... (NDS2 ITALIAN COMMANDS). "D0 CLASS: Class
D0 is used at boot time before the receipt of the INS BE acts "in the clear" with no crypt. CLASS D1: D1 class is the class "standard" used after sending the INS BE infase boot, acts "in clear "without any process of crypt." My choice fell on the class D0, because it can be sent in any time / phase of the paper. So 'choices ...
RESPONSE CODES OF SENDING EMM and meaning:
9000 = EMM invalid, BOXID invalid, no writing in EEPROM
9020 = EMM invalid, BOXID valid, no writing in EEPROM
9080 = EMM valid BOXID invalid, no writing in EEPROM
9081 = EMM valid, invalid BOXID, writing in EEPROM
90A0 = EMM valid BOXID valid, no writing in EEPROM
90A1 = EMM valid BOXID valid write to the EEPROM
