In addition, there are TP-MMS, TP-SRI, TP-UDHI, TP-RP fields. Where are their data located? How do they appear in the digital representation for an ordinary person?

1. If I understand correctly, TP-SCA can be absent and taken from the SIM card itself.

it's unclear how the entire number is encrypted and where it is displayed,

2. I read that the SCA number type can have several types, but I only found descriptions for 91 and 81. I also read that there are other types like....

However, I don't know how to translate bits, and it doesn't seem necessary to write a function for decoding such a small piece of information.
I would like to understand how these encrypted data will be represented in human-readable form

https://www.activexperts.com/serial-por ... technical/ see how PDU Type is encoded.

Now let's talk about the sender's address field (TP-OA). Although it may resemble the SCA number at first glance, there are certain aspects that are not clear:
1. Why does the same length of the SCA number get encoded as "07," while for the sender's address it is "0B"?

4. And how can we determine the length of an alphanumeric address in terms of the number of characters allocated for it, rather than the number of bytes?

0x91 and 0x81 do not exist (everytime use hex when the number are hex...)
are BIT 10010001 and 10000001 and must be checked what each bit is.

Is not encrypted, and you are forced to check BIT by BIT or you need one "if" function for each 256 possibilities....

0x91 and 0x81 do not exist (everytime use hex when the number are hex...)
are BIT 10010001 and 10000001 and must be checked what each bit is.

I was referring to the fact that 81 and 91 don't exist because they are hexadecimal numbers, not decimals.
As I have written several times, put something before or after the number to understand the difference... 0x81 / 81H / hex 81, etc.
How does it not exist? It's even mentioned in the link above. Here is a screenshot from the article.

Is not encrypted, and you are forced to check BIT by BIT or you need one "if" function for each 256 possibilities....

Why do this if there are only a few such values? Perhaps even one value. In addition to "07" I have not yet met.

you have already your reply, and is not encrypted anything at all
viewtopic.php?t=196637#p1005497

0x91 and 0x81 do not exist (everytime use hex when the number are hex...)
are BIT 10010001 and 10000001 and must be checked what each bit is.

It's obvious... 0x07 is 7 bytes and 0x0B are 11 characters, because 0x0B = 11...

10.5.4.7 (not 6, the article is also wrong)

The possible total not-reserved values combination for that field are ~48. Approx, not counted exactly.
So, must be checked every BIT, or create one array of 48 or more values are one nonsense...

It's obvious... 0x07 is 7 bytes and 0x0B are 11 characters, because 0x0B = 11...

It's obvious... 0x07 is 7 bytes and 0x0B are 11 characters, because 0x0B = 11...

That is, "07" is not the length of characters, but bytes? Does "0B" count characters, not bytes?
If so, am I right in thinking that 7 bytes means 7 pairs of characters? That is, one pair of characters - the type of number, and 6 pairs - the length of the number? Ie 11-12 characters.

PDU decode code

..............

I understand not knowing the programming language, but at least what is a Byte you should know...

0x is written in front to avoid ambiguity when using only symbols that could be mistaken for decimals (or even binary), for example how much is "10"? or "91"?
therefore the possible values of a Byte, in hexadecimal, range from 00 to FF,
and that's why 0x07 represents 7 Bytes, which obviously are represented by 14 characters because every single Bytes is represented with two.

This is just a starting point for one complete function, on this function you have all needed example for decode everything inside.

:put [$PDUdecode 07912180958739F1040B917120069876F000009140503223218A21D4F29C0E6A97E7F3F0B90CA2BF41412A68F86EB7C36E32885A9ED3CB72 48]
}

    :local length [:tonum "0$2"]

You never said what 48 is on a line

Code: Select all

:put [$PDUdecode 07912180958739F1040B917120069876F000009140503223218A21D4F29C0E6A97E7F3F0B90CA2BF41412A68F86EB7C36E32885A9ED3CB72 48]
}

From the previous messages I did not understand where it came from. I understand that it has something to do with the length of the message.

Also interested in this line:

Code: Select all

    :local length [:tonum "0$2"]

Do I understand correctly that this is the second argument in the function and is somehow related to the number 48?
Can you elaborate on the syntax of this argument?

I understand not knowing the programming language, but at least what is a Byte you should know...

I know people who write programs / applications perfectly, but do not understand bits and bytes. A program is just an algorithm and syntax, and it doesn't care what information to process, even a command to brew coffee, even count bytes. Programmers don't know how to do barista work, but they can make a program to make a coffee machine work. Or a more complex example with drones. A man does not fly, but he can write a program for a drone. However, he does not need to count bytes. Only if they set such a task.

How many time same question?

If you do not know waht $1, $2, etc, are inide one function, at least deign to read what already exists on scripting.

If programmers don't know the subject of what they are programming, maybe they will eventually do something that works, but they will never come up with a program worth calling it that name...

Only if they set such a task.

In addition, there are TP-MMS, TP-SRI, TP-UDHI, TP-RP fields. Where are their data located? How do they appear in the digital representation for an ordinary person?

https://www.activexperts.com/serial-por ... technical/ see how PDU Type is encoded.

@DyadyaGenya: for what it's worth, ChatGPT is way better than Google Translate at understanding important nuances of the language which is also the real strength of a language modell like GPT (as opposed to facts that shouldn't be trusted at all).

Okay, I'll try to register in the GPT chat today

Just don't post ChatGPT generated code here, rextended will not love you after that

Now let's talk about the sender's address field (TP-OA). Although it may resemble the SCA number at first glance, there are certain aspects that are not clear:
1. Why does the same length of the SCA number get encoded as "07," while for the sender's address it is "0B"?

On the smsc the first "07" is the needed bytes, on the senders are the length of the number, not the bytes...

PDU decode code

{
:local PDUdecode do={
    :local pdu    [:tostr $1]
    :local length [:tonum "0$2"]
    :local return [:toarray ""]

    :if (!($pdu~"^[0-9A-F]*\$")) do={:error "ERROR: Only 0-9 and A-F are valid hexadecimal PDU digits."}

    :if (([:len $pdu] % 2) != 0) do={:error "ERROR: PDU length must be even."}

    :local skip (2 + ([:tonum "0x$[:pick $pdu 0 2]"] * 2))
    :if ($length > 0) do={
        :local PDUlength (([:len $pdu] - $skip) / 2)
        :if ($length != $PDUlength) do={:return "ERROR: Provided Length does not match SMS PDU part."}
        :set ($return->"PDUlength") $PDUlength
    }

    :local invertnibble do={
        :local string [:tostr $1]
        :local positn 0
        :local output ""
        :while (([:len $string] + 1) > $positn) do={
            :set output "$output$[:pick $string ($positn + 1) ($positn + 2)]$[:pick $string $positn ($positn + 1)]"
            :set positn ($positn + 2)
        }
        :return $output
    }

    # BEGIN SMSC section
    :local smsc    "<SIM>"
    :local type    "<SIM>"
    :local smscLen [:tonum "0x$[:pick $pdu 0 2]"]
    :if ($smscLen != 0) do={
        :set type [:tonum "0x$[:pick $pdu 2 4]"]
        # 0x91 = 145
        :if ($type = 145) do={
            :set smsc "+$[$invertnibble [:pick $pdu 4 $skip]]"
            :if ($smsc~"F\$") do={:set smsc [:pick $smsc 0 ([:len $smsc] - 1)]}
        } else={
            :return "ERROR: Unexpected SMSC number type (0x[:pick $pdu 2 4])"
        }
    }
    :set ($return->"smsc"    ) $smsc
    :set ($return->"smscType") $type
    # END SMSC section

    # BEGIN SMS Type section
    :local type [:tonum "0x$[:pick $pdu $skip ($skip + 2)]"]
    # 0x04 = 4
    :if ($type = 4) do={
        :set ($return->"SMStype") $type
    } else={
        :return "ERROR: Unexpected SMSC number type (0x$[:pick $pdu $skip ($skip + 2)])"
    }
    :set skip ($skip + 2)
    # END SMS Type section

    # BEGIN SENDER section
    :local sender    ""
    :local senderLen [:tonum "0x$[:pick $pdu $skip ($skip + 2)]"]
    :if (($senderLen % 2) = 1) do={:set senderLen ($senderLen + 1)}
    :local type [:tonum "0x$[:pick $pdu ($skip + 2) ($skip + 4)]"]
    # 0x91 = 145
    :if ($type = 145) do={
        :set sender "+$[$invertnibble [:pick $pdu ($skip + 4) ($skip + 4 + $senderLen)]]"
        :if ($sender~"F\$") do={:set sender [:pick $sender 0 ([:len $sender] - 1)]}
    } else={
        :return "ERROR: Unexpected SENDER number type (0x$[:pick $pdu ($skip + 2) ($skip + 4)])"
    }
    :set ($return->"sender"    ) $sender
    :set ($return->"senderType") $type
    :set skip ($skip + 4 + $senderLen)
    # END SENDER section

    # BEGIN PROTOCOL section
    :local protocol ""
    :local type [:tonum "0x$[:pick $pdu $skip ($skip + 2)]"]
    # 0x00 = 0
    :if ($type = 0) do={
        :set protocol $type
    } else={
        :return "ERROR: Unexpected PROTOCOL number type (0x$[:pick $pdu $skip ($skip + 2)])"
    }
    :set ($return->"protocol") $protocol
    :set skip ($skip + 2)
    # END PROTOCOL section

    # BEGIN CLASS section
    :local class ""
    :local type [:tonum "0x$[:pick $pdu $skip ($skip + 2)]"]
    # 0x00 = 0
    :if ($type = 0) do={
        :set class $type
    } else={
        :return "ERROR: Unexpected CLASS number type (0x$[:pick $pdu $skip ($skip + 2)])"
    }
    :set ($return->"class") $class
    :set skip ($skip + 2)
    # END CLASS section

    # BEGIN DATETIME section
    :local datetime [$invertnibble [:pick $pdu $skip ($skip + 12)]]
    :if ([:tonum "$[:pick $datetime 0 2]"] > 39) do={:set datetime "19$datetime"} else={:set datetime "20$datetime"}
    :local separators {"";"-";"-";" ";":";":"}
    :local positn -1
    :local output ""
    :while (13 > $positn) do={
        :set output "$output$[:pick $datetime ($positn + 1) ($positn + 2)]"
        :if (($positn % 2) = 0) do={:set output "$output$($separators->($positn / 2))"}
        :set positn ($positn + 1)
    }
    :set ($return->"datetime") $output
    :set skip ($skip + 12)
    # END DATETIME section

    # BEGIN TIMEZONE section
    :local tza [:tonum "0x$[:pick $pdu ($skip + 1) ($skip + 2)]"]
    :local tzb [:tonum "0x$[:pick $pdu $skip       ($skip + 1)]"]
    :local tzs "+" ; :if (($tza & 0x8) = 0x8) do={:set tzs "-"}
    :set tza ($tza & 0x7)
    :local tzmin ((($tza * 10) + $tzb) * 15)
    :set ($return->"tzminutes") [:tonum "$tzs$tzmin"]
    :local tzhou ($tzmin / 60) ; :if ($tzhou < 10) do={:set tzhou "0$tzhou"}
    :set   tzmin ($tzmin % 60) ; :if ($tzmin < 10) do={:set tzmin "0$tzmin"}
    :set ($return->"timezone") "GMT$tzs$tzhou:$tzmin"
    :set skip ($skip + 2)
    # END TIMEZONE section

    # BEGIN SMSlength section
    :local SMSlength [:tonum "0x$[:pick $pdu $skip ($skip + 2)]"]
    :set ($return->"SMSlength") $SMSlength
    :set skip ($skip + 2)
    # END SMSlength section

    # BEGIN SMSPDU section
    :local smspdu [:pick $pdu $skip [:len $pdu]]
    :set ($return->"SMSPDU") $smspdu
    # END SMSPDU section

    :return $return
}

:put [$PDUdecode 07912180958739F1040B917120069876F000009140503223218A21D4F29C0E6A97E7F3F0B90CA2BF41412A68F86EB7C36E32885A9ED3CB72 48]
}

I understand not knowing the programming language, but at least what is a Byte you should know...

A Byte consists of 8 bits ranging from 00000000 to 11111111, because bits can only have 2 values, either 0 or 1,
this so that there are 256 possible combinations,

:put [ :tonum ( "0x" . "bits" ) ]

For example, two dates are provided: 22112051314180 and 32501031613521. Ideally, the first date should be interpreted as 22/11/02 15:13:41 with an 08 time zone offset, and the second date as 23/05/01 13:16:53 with a 12 time zone offset. However, according to the PDUspy program, the first date is displayed as 02.11.22 15:13 GMT+2.00, and the second date as 01.05.23 13:16 GMT+3.00. Both dates are considered correct by the program.
How do you actually convert the time zone?

9.2.3.11 TP-Service-Centre-Time-Stamp (TP-SCTS)
The TP-Service-Centre-Time-Stamp field is given in semi-octet representation, and represents the local time in the following way:
Year, Month, Day, Hour, Minute, Second, Time Zone (2 semi-octets each)
The Time Zone indicates the difference, expressed in quarters of an hour, between the local time and GMT. In the first of the two semi-octets, the first bit (bit 3 of the seventh octet of the TP-Service-Centre-Time-Stamp field) represents the algebraic sign of this difference (0: positive, 1: negative).

9.2.3.11 TP-Service-Centre-Time-Stamp (TP-SCTS)
...(bit 3 of the seventh octet of the TP-Service-Centre-Time-Stamp field) represents the algebraic sign of this difference (0: positive, 1: negative).

See https://www.etsi.org/deliver/etsi_ts/12 ... 60000p.pdf

See https://www.etsi.org/deliver/etsi_ts/12 ... 60000p.pdf

Honestly, I would prefer not to deal with these octets. I would prefer a simpler explanation.

Create one array with all 256 possible values with corresponding real value...

But if we take two bits, then everything becomes clear.

10.5.4.7 (not 6, the article is also wrong)

Possible plausible values used only on SMS (read the full guide to understand what are)...

[…]
************************
about 40 0D D0 4669B1487C3601
************************
0x40 type
0x0D on decimal is... 13 because for store seven 7-bit GSM-7 characters are needed 13 nibble (half byte), [for store 7 bit, each 8 bytes, one less byte is required]
and because the nibble can't be one odd number, the last nibble is unused, but is still required 13+1 nibble = 7 bytes and 46/69/B1/48/7C/36/01 is 7 bytes long...
0xD0 is the coding: binary 1101 - 0000 = PDU encoded name with GSM-7 alphabet
4669B1487C3601 = 0x64961B84C76310 = binary 01100100100101100001101110000100110001110110001100010000 (notice the unused last nibble / 4 bits)
and the 7-bit 0x64 0x96 0x1B 0x84 0xC7 0x63 0x10 converted to 8-bit GSM-7 is 0x46 0x52 0x45 0x45 0x44 0x4F 0x4D,
and 8-bit GSM-7 0x46 0x52 0x45 0x45 0x44 0x4F 0x4D converted to readable CP 1252 is....
FREEDOM
[…]

instead of constantly asking the same questions in a circle, it would be enough for you to read what has already been written...