I wonder how mobile phone companies generate both PIN and PUK for their SIM cards?
I have a large database of already generated codes, this database contains 3 columns:
* MSIN : Mobile Subscriber Identification Number (10 digits)
* PIN : Personal Identification Number (4 digits)
* PUK : Personal Unblocking Code (8 digits)
So far, maybe both PIN and PUK are generated from MSIN because the MSIN column is incrementing, while others, are generated with a logic, something like;
MSIN PIN PUK
1000000000 3234 20005627
1000000001 5993 92870018
1000000002 3465 30327846
...
is it possible to know how this serials are generated? Using the existing database is it possible to guess the algo used?
I'm asking this for the sake of knowledge only not to use the provided information in any illegal activity ;)
thanx.
UPDATE
I searched for how many times some pin codes are repeated and found this
0000 –> 261 times
1111 –> 429982 times
2222 –> 275
3333 –> 233
4444 –> 279
5555 –> 277
6666 –> 242
7777 –> 263
8888 –> 249
9999 –> 242
the pin 1111 is used more than others! so maybe the algo is changed from time to time.. or ther's no logic at all inside :(
UPDATE 2
I checked the MSIN and found that they make jumps in the incrementing system, so for example;
1011000000
1011000001
… here they followed incrementing until 1011499999
1011499999 and they jumped to 1031000000
1031000000
… the same thing here
1031299999
1131000000
…
this leads to an idea that whenever they want to issue new cards, lets say 500 000 cards, they start with a new MSIN that doesn't follow the incrementing rule in the database and the may change the algo behind the code generation (that's why we find in some cases they issued all the next cards with pin 1111)
The answer can go from really easy to pretty complex.
If I had to design the system, the f function (Pin,Puk) = f(MSIN) wouldn't be easy to guess, and, moreover, not reversible (meaning if you know (pin,puk) you cannot guess MSIN).
Because the subject is around security and payment, you can probably expect a complex function.
Unless it is documented somewhere on the net (which I doubt) it is very unlikely you will find the function f.
If we make the assumption that PUK/PIN are generated from the MSIN, there's a virtually infinite number of ways they could be doing this. To take one (reasonable) example, they could be using an HMAC. Even assuming you knew what hash algorithm they're using, you'd still have to determine the secret key, and the search space for that is on the order of 2^160 (for HMAC-SHA1) - totally impractical to search exhaustively.
The only chance you have is if they're doing something stupid, like using an easily guessed or determined algorithm to generate the PIN/PUK - and there's no practical mechanical procedure to work that out, just trial, error, and intuition.
Usually its not the mobile network operator who generates the PIN and PUK. The SIM card manufacturer does this unless ordered otherwise by the operator.
What makes you believing that one can calculate SIM and/or PUK from the MSIN? Neither the network operator nor the SIM manufacturer would have any advantage from this. I would assume that PIN and PUK are as random as economically feasible in order to implement the intended security.
However, I find the 1111 anomaly interesting. Is your sample right from manufacturing? Or did you get an HLR dump? The latter one might provide an explanation for the 1111 cumulation: People change their PIN to something easy to remember and to type, 1111 would be the most common candidate for this.
Related
I am debugging some snmp code for an integer overflow problem. Basically we use an integer to store disk/raid capacity in KB. However when a disk/raid of more than 2TB is used, it'll overflow.
I read from some internet forums that snmp v2c support integer64 or unsigned64. In my test it'll still just send the lower 32 bits even though I have set the type to integer64 or unsigned64.
Here is how I did it:
a standalone program will obtain the capacity and write the data to a file. example lines for raid capacity
my-sub-oid
Counter64
7813857280
/etc/snmp/snmpd.conf has a clause to pass thru the oids:
pass_persist mymiboid /path/to/snmpagent
in the mysnmpagent source, read the oidmap into oid/type/value structure from the file, and print to stdout.
printf("%s\n", it->first.c_str());
printf("%s\n", it->second.type.c_str());
printf("%s\n", it->second.value.c_str());
fflush(stdout);
use snmpget to get the sub-oid, and it returns:
mysuboid = Counter32: 3518889984
I use tcpdump and the last segment of the value portion is:
41 0500 d1be 0000
41 should be the tag, 05 should be the length, and the value is only carrying the lower 32-bit of the capacity. (note 7813857280 is 0x1.d1.be.00.00)
I do find that using string type would send correct value (in octetstring format). But I want to know if there is a way to use 64-bit integer in snmp v2c.
I am running NET-SNMP 5.4.2.1 though.
thanks a lot.
Update:
Found the following from snmpd.conf regarding pass (and probably also pass_persist) in net-snmp doc page. I guess it's forcing the Counter64 to Counter32.
Note:
The SMIv2 type counter64 and SNMPv2 noSuchObject exception are not supported.
You are supposed to use two Unsigned32 for lower and upper bytes of your large number.
Counter64 is not meant to be used for large numbers this way.
For reference : 17 Common MIB Design Errors (last one)
SNMP SMIv2 defines a new type Counter64,
https://www.rfc-editor.org/rfc/rfc2578#page-24
which is in fact unsigned 64 bit integer. So if your data fall into the range, using Counter64 is proper.
"In my test it'll still just send the lower 32 bits even though I have set the type to integer64 or unsigned64" sounds like a problem, but unless you show more details (like showing some code) on how you tested it out and received the result, nobody might help further.
I have just entered into AVR MCU programming using gcc-avr, but when I see sample programs I am not able to make out much from the code:
DDRD |= (1 << PD7);
TCCR2 = (1 << WGM21) | (0 << WGM20);
TCCR2 |= (1 << COM20);
TCCR2 |= (6 << CS20);
I do not see also any declarations variables : DDRD, PD7, TCCR2, WGM21, WGM20, COM20, CS20, but they are directly used. Please let me know how I can know all pre-defined variables and its usage? It becomes very difficult in understanding the code without knowing the same.
Thanks in advance.
That kind of code is very common when programming embedded systems, although you will need to look at the header files and the AVR documentation to learn what those specific identifiers mean. Be aware that it can be very complex if you're new to this, and you will need to understand how to work with raw binary and C-style bit shifts/operators. (There are lots of tutorials online if you need to learn more about that.)
I'll try to explain the basic principle though.
All of the identifiers you saw will be preprocessor constants (i.e. #define ...), rather than variables. DDRD and TCCR2 will specify memory locations. These locations will be mapped onto certain functionality, so that setting or clearing certain bits at those locations will change the behaviour of the device (e.g. enable a clock divider, or set a GPIO pin high or low, etc.).
PD7, WGM21, WGM20, COM20, and CS20 will all be fairly small numbers. They specify how far you need to offset certain bit patterns to achieve certain results. Bit-wise operators (such as | and &) and bit-shift operators (typically <<) are used to create the patterns which are written to the memory locations. The documentation will tell you what patterns to use.
I'll use a simple fictional example to illustrate this. Let's say there is a register which controls the value of some output pins. We'll call the register OUTPUT1. Typically, each bit will correspond to the value of a specific pin. Turning on pin 4 (but leaving the other pins alone) might look like this:
OUTPUT1 |= (1 << PIN4);
This bitwise OR's the existing register with the pattern to turn pin 4 on. Turning that pin off again might look like this:
OUTPUT1 &= ~(1 << PIN4);
This bitwise AND's the existing register with everything except the pattern to turn pin 4 on (which results in clearing the bit). That's an entirely fictional example though, so don't actually try it!
The principle is basically the same for many different systems, so once you've learned it on AVR, you will hopefully be able to adapt to other devices as well.
Where can I get the structure for an HID device?
For example:
raw data from a device, using GetRawInputData:
( 0 137 117 0 146 130 24 128 0 )
( 0 137 117 0 146 130 8 128 0 )
/\
at this I can see that || there is being a button released
that means, at the 6-th char at 4-th bit
By analyzing the raw stream I can figure out where are the buttons, switches and analog data. Is there a way to ask this information from Windows.
My main goal is to basically get structure:
Button - 6th char, 4th bit.
Analog - 2nd char
Switch - 6th char, 0-3th bit.
The only solution I found was HID Descriptors. But I'm not sure how to use them.
After reading documentation I felt like running into a brick wall. Is there
maybe a good example how to use them or a book that describes them better. (Or a easier way
doing it without descriptors)
I found HidP_GetButtons and HidP_GetUsages but still no idea how to extract the structure (as described above).
Oh, you have to use GetRawInputData. There is a somewhat crummy example on msdn.
The problem seems to be that each device has it's own structure. There doesn't seem to be a universal way through the win32 api to get the interpretation of the structure.
The combination of
GetRawInputDeviceInfo which gives you a RID_DEVICE_INFO struct
GetRawInputData
GetRawInputBuffer
Seems to get you all the information you can from win32.
After that, you probably need some external source of information (or generated by you), that describes specific fields etc.
I can't find any help to implement PROV_RSA_AES CSP in c++. is there any article or book to help me out with it?
Here is an article about it.
Here is another one.
i just want to use one, i figured
how to get context but i'm still
thinking about the size of buffer i
need to use for CryptEncrypt() to get
it working with aes256 ? i also want
to use random salt.
AES256 in CBC-mode with PKCS#7-padding (which is the default) will need a buffersize that is the input-data rounded up to the next multiple of 16 (but always at least one byte more). Ie. 35 -> 48, 52 -> 64, 80 -> 96.
There is no salt involved in AES256. Are you talking about key-derivation? Or do you mean the IV?
I'm using the WML function "providelocalinfo" to put location information into Short Messages send via a WIB menu on a GSM handset.
I'm using the WIG WML v.4 Spec from SmartTrust. The relevant section is "9.4 providelocalinfo Element"
I use the code as in the example, and then transmit the variable via SMS, and use Kannel to retrieve the message from the SMSC.
Here's the code that I'm using, with the exception of [myservicecentre] being my actual service centre:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE wml PUBLIC "-//SmartTrust//DTD WIG-WML 4.0//EN"
"http://www.smarttrust.com/DTD/WIG-WML4.0.dtd">
<wml wibletenc="UCS2">
<card id="s">
<p>
<providelocalinfo cmdqualifier="location" destvar="LOC"/>
<setvar name="X" value="loc=" class="binary"/>
<sendsm>
<destaddress value="367"/>
<userdata docudenc="hex-binary" dcs="245">
$(X)$(LOC)
</userdata>
<servicecentreaddress value="[myservicecentre]"/>
</sendsm>
</p>
</card>
</wml>
What I see in my received messages is "loc=" followed by 7 bytes (octets) or binary data. I have tried to find documentation explaining how to decode this data, but found nothing the explains this clearly.
Of the decoded 7 octets,
the first 3 octets are always the same,
The next 2 octets tend to vary between three unique values,
the last 2 octets appear to be the cellid.
So I have coded the receiver to pull the last two octets and construct a 16-bit GSM cellid. Most of the time it matches known cellids from the network. But quite often, the value does not match.
So I'm trying to find information on the following:
How to properly transmit the location information in a safe manner (encodings, casts, etc)
How to decode the information properly
How to configure Kannel to honor binary location data
I've examined the following documents in my vain searching, but not found the relevant data:
GSM 03.38, GSM 04.07, GSM 04.08, GSM 11.15, as well as the WIG WML Spec V .4
Any insight into what I might be doing wrong would be appreciated!
To decode the location info, you need to look in GSM 11.14 page 48
1.19 LOCATION INFORMATION
Byte(s) Description Length
1 Location Information tag 1
2 Length (X) of bytes following 1
3-5 Mobile Country & Network Codes (MCC & MNC) 3
6-7 Location Area Code (LAC) 2
8-9 Cell Identity Value (Cell ID) 2
The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the
cell ID are coded as in TS GSM 04.08 [8].
From personal experience, the first octet mentioned here is usually left off, so your first three unchanging bytes are the length and the country. The next 2 are the network operator code.
Not too many bites on this question! I wanted to summarize my findings in case others can find them useful:
Need to send messages with a dcs setting not equal to 0. dcs="0" sends data packed (honoring the lower 7-bits of each octet; this allows 160 character SMS messages when the max message size is actually 140 octets)
Need to parse the data in a binary safe manner: regex expressions that stop searching when 0x0A is encountered will fail when the binary data itself can be that value.
I found no need to change Kannel's default configuration.
Cheers
Disclaimer: Safe transmission of 16-bit GSM Cell-Ids requires dealing with a few settings that I understand only because they weren't configured by default. There are probably other defaults that I've depended on but am unaware that they can vary.