I am using the Telpo TPS300 POS terminal to try and read information from a VISA bank Card. The terminal comes with C libraries so sending commands is a lot more easier. However the when I run the SELECT APDU command
(00 A4 04 00 )Lc=0, it returns the following hex data 18byte long as below
6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 01 FF.
I read the ISO 7816-4 specification and the EMV specification and from the look of things, my returned data seems to be lacking one of the mandatory tag 88 as specified in EMV Specification 11.3.4
When I try to SELECT the returned DF name i.e one with tag 84 (A0 00 00 00 03 00 00 00), it returns the same information. All other commands were not successful as well specifically I tried READ RECORD, VERIFY, GET PROCESSING OPTIONS, GET CHALLENGE and they all return the SW 6D 00 (Instruction code not supported or invalid). I just want to retrieve user info from the card and perform an offline authentication of the PIN using the verify command.
I have looked around the web but no one seems to answer me. I have read the standard ISO 7816-4 and EMV Specification again and again on the commands and response interactions but no luck so far because I can't go beyond this step (SELECT command response)
I am using the Telpo TPS300 POS terminal to try and read information from a VISA bank Card
As you said you tried with blank card , here information is coming from card is correct.
when you send select command like,
00 A4 04 00 00 , it select ISD - Issuer Security Domain and return ISD AID i.e. A0 00 00 00 03 00 00 00 with tag 9F 65 that means -Maximum length of data field in command message
Recv - 6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 01 FF
what you receive showing AID of ISD and value of tag 9F65. it seems correct.
my returned data seems to be lacking one of the mandatory tag 88 as specified in EMV Specification 11.3.4
Tag 88 -SFI of the Directory Elementary File is come out from card when you select PSE directory with using command,
00 A4 04 00 0E 315041592E5359532E4444463031 (select PSE command)
it will give you tag 88 if PSE is installed in the card.
I tried READ RECORD, VERIFY, GET PROCESSING OPTIONS, GET CHALLENGE and they all return the SW 6D 00 (Instruction code not supported or invalid).
for reading emv card, EMV application should be installed and personalize in the card then only you can get information from the card with using sequence of commands. try- how to read emv card
it gives basic idea to read emv card with sequence of commands.
hope it helps you..
Related
I'm trying to scan the list of available networks and enumerate the security type for each SSID. I'm at a point where I can issue a SIOCSIWSCAN ioctl and parse the results. However, when I try to differentiate between a WEP network and an open network, I seem to be getting the same type of IE from the AP.
For example, I configured my Dlink DIR-655 router to be of open type vs WEP.
Since the network is a WEP network, I look for the hex byte 0xDD to tell me that this is an IE describing a WPA/WEP/open network. For this case, I only get one byte that says 0xDD for both open and WEP networks and the corresponding IE looks the same for both:
DD 18 00 50 F2 02 01 01 83 00 03 A4 00 00 27 A4 00 00 42 43 5E 00 62 32 2F 00
Does that mean that the router doesn't populate information about open networks under the byte 0xDD and I should be looking somewhere else?
PS: I've been reverse engineering the source from iwlist to tell me how to read the IEs returned. But they only seem to be describing WPA and WPA2 networks
I got a fdb file, I thought it's a firebird database file, but cant't open using firebird, and I try sybase again, not work.
this file used for a B/S software (java) client cache, maybe pretty old database, and this is not a compressed file,I can see may strings in file, the file head start with:
10 00 00 00 00 40 00 40 00 00 00 00 00 00 04 00
any suggestion?
this is the file,please have a look
https://www.dropbox.com/s/qorhd21f328pfj2/PRINT_TEMPLATE_CACHE.fdb?dl=0
I've got a legacy collection of DBF, FPT and CDX files left from file organizing software. Judging from CDX and FTP suffixes, I presume it is a Visual FoxPro database. From the first glance into DBF file, it looks like it has field descriptors there. I'd like to examine what data stored there and use or extract any useful stuff.
00000000: 31 0B 06 0E-2F 00 00 00-08 02 28 01-01 00 00 01 1/ (
00000010: 00 00 00 00-00 00 00 00-00 00 49 40-01 7F 00 00 I#
00000020: 4E 41 4D 45-00 00 00 00-00 00 00 43-01 00 00 00 NAME C
00000030: FF 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00
00000040: 43 41 54 5F-52 4F 4F 54-49 44 00 42-00 01 00 00 CAT_ROOTID B
00000050: 08 00 04 00-00 00 00 00-00 00 00 00-00 00 00 00
00000060: 50 52 4E 54-5F 49 44 00-00 00 00 42-08 01 00 00 PRNT_ID B
00000070: 08 00 04 00-00 00 00 00-00 00 00 00-00 00 00 00
00000080: 41 54 54 52-49 42 53 00-00 00 00 49-10 01 00 00 ATTRIBS I
00000090: 04 00 04 00-00 00 00 00-00 00 00 00-00 00 00 00
000000A0: 49 53 5F 45-58 43 4C 55-44 45 00 49-1A 01 00 00 IS_EXCLUDE I
000000B0: 04 00 04 00-00 00 00 00-00 00 00 00-00 00 00 00
000000C0: 43 41 54 5F-49 44 00 00-00 00 00 42-1E 01 00 00 CAT_ID B
000000D0: 08 00 0C 00-00 00 00 00-00 00 00 00-00 00 00 00
000000E0: 54 53 00 00-00 00 00 00-00 00 00 37-26 01 00 00 TS 7&
000000F0: 08 00 14 00-00 00 00 00-00 00 00 00-00 00 00 00
What I tries so far:
upgrading out-of-box Windows 7 ODBC driver stub to version 6.01.8629.01
creating User DNS as "Free Tables Directory" and pointing its path to the file collection
no tables are listed for that OBDC DNS in variety of tools, like SQL Explorer and SQL Server Import/Export Wizard.
manual attempt to SELECT * FROM any DBF file gives me [Microsoft][ODBC Visual FoxPro Driver]Not a table. error.
Also, I tried:
creating BDE alias with FOXPRO driver
opening any of DBF files in Database Desktop
Both attempts to open a table resulted in Corrupt table/index header. error.
Also, I just tried tDBF component but it looks abandoned and loaded with Kylix Libc dependencies thus not compiles in Delphi w/o fixing that.
Tons of questions:
How do I confirm what files are really Visual FoxPro?
Does symptoms described above indicate real data corruption or just incompatibility/misconfiguration?
And finally, how to use something modern to access tables and start examining data?
Q: How do I confirm what files are really Visual FoxPro?
Based on your dbf data dump it would seem to be Visual FoxPro. The first byte has a value of 0x31 which is Visual FoxPro, autoincrement enabled according to Microsoft's MSDN documentation of the .dfb Table file structure http://msdn.microsoft.com/en-US/library/st4a0s68(v=vs.80).aspx
Additionall information about the file extensions you mention:
.dbf = Data for fixed-length fields.
.cdx = Compound index.
.fpt = Data for memo fields, images and objects.
Q: Does symptoms described above indicate real data corruption or just incompatibility/misconfiguration?
Sorry cannot help you here...
Q: And finally, how to use something modern to access tables and start examining data?
I’ve previously managed to access dfb files by using Delphi’s ADO (dbGo) components. I downloaded the FoxPro OLE DB Provider that is included in ”Microsoft Access Database Engine 2010 Redistributable” http://www.microsoft.com/en-us/download/confirmation.aspx?id=13255.
An initial connection string looks as follows:
Provider=VFPOLEDB.1;Data Source=[MY_FOXPRO_DIR_PATH];Password="";Collating Sequence=MACHINE
When I study my code I have used a much longer one and unfortunately don't have any notes why. I'm throwing it in anyway:
Provider=VFPOLEDB.1;Data Source=[MY_FOXPRO_DIR_PATH];Mode=Share Deny None;Extended Properties="";User ID="";Mask Password=False;Cache Authentication=False;Encrypt Password=False;Collating Sequence=MACHINE;DSN="";DELETED=True;CODEPAGE=1252;MVCOUNT=16384;ENGINEBEHAVIOR=90;TABLEVALIDATE=3;REFRESH=5;VARCHARMAPPING=False;ANSI=True;REPROCESS=5
Why don't you try to find a copy of Visual Fox Pro, version 9, and see if it will open the files. (The UniversalThread has a VFP section and VFP experts where you can ask the question as well.)
If you can open it in VFP, you can simply copy it to a .CSV or tab-delimited file and you should be able to import it into whatever system you want.
Sometimes VFP tables (.DBF, .CDX, .FPT) are linked to a "data base" (kind of container), which expands their field names and adds things like triggers, etc. Look for a .DBC file somewhere. Or they can be free-standing. I'm not sure what happens if you try to open a VFP table what was part of a DBC (data base container) and you don't have the container available.
How do I confirm what files are really Visual FoxPro?
dbf extension and the first byte h31 indicates that it is a Visual FoxPro Table.
Does symptoms described above indicate real data corruption or just incompatibility/misconfiguration?
The Microsoft ODBC driver has some problems with VisualFoxPro
And finally, how to use something modern to access tables and start examining data?
Best method in my opinion is to use the Apollo database engine from Vista Software.
http://www.apollodb.com/default.asp
While debugging an ASP.Net MVC application running under IIS Express, I get the following error when attempting to use the membership provider:
Cannot open database "MyDB" requested by the login. The login failed.
Login failed for user 'MY-PC\MyName'.
I attempted to troubleshoot using the steps outlined in
https://stackoverflow.com/a/2577854/141172
SELECT SUSER_ID('MY-PC\MyName')
returns an ID.
SELECT USER_ID('MY-PC\MyName')
returns NULL
CREATE USER [MY-PC\MyName] FROM LOGIN [MY-PC\MyName]
returns the error message
The login already has an account under a different user name.
Indeed, there is a login account, automatically created when I created the database, called
dbo
which maps to MY-PC\MyName.
My connection string is
Data Source=.\SQLEXPRESS;Initial Catalog=MyDB;Persist Security Info=True;Integrated Security=SSPI;
Running in a production environment I would know how to create appropriate users and logons. I'm stuck on how to resolve the fact that IIS Express is using my Windows account name to try and log into MyDB when that Windows account is already associated with dbo.
It turned out to be a typo in the Initial Catalog portion of the connection string.
Looking in the event log, I saw an error like
Login failed for user 'MY-PC\MyName'. Reason: Failed to open the explicitly specified database. [CLIENT: ]
Then looking on the details tab of the same event, I saw that the Binary Data In Bytes information contained
0000: 18 48 00 00 0E 00 00 00 .H......
0008: 17 00 00 00 45 00 52 00 ....E.R.
0010: 49 00 43 00 2D 00 4F 00 I.C.-.O.
0018: 52 00 49 00 47 00 49 00 R.I.G.I.
0020: 4E 00 5C 00 53 00 51 00 N.\.S.Q.
0028: 4C 00 45 00 58 00 50 00 L.E.X.P.
0030: 52 00 45 00 53 00 53 00 R.E.S.S.
0038: 00 00 07 00 00 00 6D 00 ......m.
0040: 61 00 73 00 74 00 65 00 a.s.t.e.
0048: 72 00 00 00 r...
Notice how the last portion of that is UTF-16 encoded the word "master". That got me on the track that the connection is being made to the master catalog rather than the requested one, which in turn lead to noticing the typo in the catalog name in the connection string.
It would have been so much nicer if Microsoft would have just show an error like "No such catalog: MyCatalog".
I have no idea why I am getting this error and cannot find any solutions for it. I can connect to a SQL Server database using freetds tsql but I keep getting an error when connecting using pymssql.connect.
The specific error is:
pymssql.OperationalError: (18456, "Login failed for user 'xxx'.DB-Lib error message 18456, severity 14:\nGeneral SQL Server
error: Check messages from the SQL Server\nDB-Lib error message 20002,
severity 9:\nAdaptive Server connection failed\n")
I have the configuration set for freetds as:
[custom_config]
host = myhost
port = 1433
tds version = 7.0
encryption = request
dump file = /tmp/freetds.log
running:
tsql -S custom_config -U tsmv -P xxx
returns:
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1>
which allows me to query the database.
However, running:
python
>> import pymssql
>> pymssql.connect(server='custom_config', user='user', password='xxx', database='database')
raises the above error.
I am using Linux CentOS, python 2.6.6, freetds 0.92 dev (I have tried other versions compiling with tdsver=7.0).
The freetds log is:
log.c:196:Starting log file for FreeTDS 0.92
on 2012-04-12 10:39:15 with debug flags 0x4fff.
iconv.c:330:tds_iconv_open(0x1391b70, ISO-8859-1)
iconv.c:187:local name for ISO-8859-1 is ISO-8859-1
iconv.c:187:local name for UTF-8 is UTF-8
iconv.c:187:local name for UCS-2LE is UCS-2LE
iconv.c:187:local name for UCS-2BE is UCS-2BE
iconv.c:349:setting up conversions for client charset "ISO-8859-1"
iconv.c:351:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion
iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion
iconv.c:394:tds_iconv_open: done
net.c:205:Connecting to xx.x.x.xxx port 1433 (TDS version 7.1)
net.c:270:tds_open_socket: connect(2) returned "Operation now in progress"
net.c:310:tds_open_socket() succeeded
util.c:156:Changed query state from DEAD to IDLE
net.c:741:Sending packet
0000 12 01 00 34 00 00 00 00-00 00 15 00 06 01 00 1b |...4.... ........|
0010 00 01 02 00 1c 00 0c 03-00 28 00 04 ff 08 00 01 |........ .(......|
0020 55 00 00 02 4d 53 53 51-4c 53 65 72 76 65 72 00 |U...MSSQ LServer.|
0030 c7 39 00 00 - |.9..|
net.c:555:Received header
0000 04 01 00 25 00 00 01 00- |...%....|
net.c:609:Received packet
0000 04 01 00 25 00 00 01 00-00 00 15 00 06 01 00 1b |...%.... ........|
0010 00 01 02 00 1c 00 01 03-00 1d 00 00 ff 0a 00 0f |........ ........|
0020 a0 00 00 02 00 - |.....|
login.c:1057:detected flag 2
login.c:782:quietly sending TDS 7+ login packet
token.c:328:tds_process_login_tokens()
net.c:555:Received header
0000 04 01 00 72 00 51 01 00- |...r.Q..|
net.c:609:Received packet
0000 04 01 00 72 00 51 01 00-aa 5e 00 18 48 00 00 01 |...r.Q.. .^..H...|
0010 0e 1d 00 4c 00 6f 00 67-00 69 00 6e 00 20 00 66 |...L.o.g .i.n. .f|
0020 00 61 00 69 00 6c 00 65-00 64 00 20 00 66 00 6f |.a.i.l.e .d. .f.o|
0030 00 72 00 20 00 75 00 73-00 65 00 72 00 20 00 27 |.r. .u.s .e.r. .'|
0040 00 74 00 73 00 6d 00 76-00 27 00 2e 00 0c 4d 00 |.t.s.m.v .'....M.|
0050 43 00 53 00 2d 00 44 00-41 00 54 00 41 00 42 00 |C.S.-.D. A.T.A.B.|
0060 41 00 53 00 45 00 00 01-00 fd 02 00 00 00 00 00 |A.S.E... ........|
0070 00 00 - |..|
token.c:337:looking for login token, got aa(ERROR)
token.c:122:tds_process_default_tokens() marker is aa(ERROR)
token.c:2588:tds_process_msg() reading message 18456 from server
token.c:2661:tds_process_msg() calling client msg handler
dbutil.c:85:_dblib_handle_info_message(0x14e2e30, 0x1391b70, 0x7fff8b047e40)
dbutil.c:86:msgno 18456: "Login failed for user 'xxx'."
token.c:2674:tds_process_msg() returning TDS_SUCCEED
token.c:337:looking for login token, got fd(DONE)
token.c:122:tds_process_default_tokens() marker is fd(DONE)
token.c:2339:tds_process_end: more_results = 0
was_cancelled = 0
error = 1
done_count_valid = 0
token.c:2355:tds_process_end() state set to TDS_IDLE
token.c:2370: rows_affected = 0
token.c:438:tds_process_login_tokens() returning TDS_FAIL
login.c:466:login packet accepted
util.c:156:Changed query state from IDLE to DEAD
util.c:331:tdserror(0x14e2e30, 0x1391b70, 20002, 0)
dblib.c:7929:dbperror(0x1383c70, 20002, 0)
dblib.c:7981:20002: "Adaptive Server connection failed"
dblib.c:8002:"Adaptive Server connection failed", client returns 2 (INT_CANCEL)
util.c:361:tdserror: client library returned TDS_INT_CANCEL(2)
util.c:384:tdserror: returning TDS_INT_CANCEL(2)
dblib.c:1443:dbclose(0x1383c70)
dblib.c:258:dblib_del_connection(0x7fa462faf540, 0x1391b70)
mem.c:615:tds_free_all_results()
dblib.c:305:dblib_release_tds_ctx(1)
dblib.c:5882:dbfreebuf(0x1383c70)
dblib.c:739:dbloginfree(0x1533a40)
I am completely lost as to why this is not working. Any help would be much appreciated.
The "Adaptive Server connection failed" seems to be a fairly generic message, but here are some things to try.
This mailing list thread (http://lists.ibiblio.org/pipermail/freetds/2010q3/026060.html) says that using the incorrect TDS protocol results in an "Adaptive Server connection failed" message. That doesn't seem to be the case in chewynougat's log, but perhaps it helps others.
This FAQ gives a lot of steps to try:
https://github.com/pymssql/pymssql/blob/87f4383ec153962b7ca7e63a05042d3f09005178/docs/faq.rst,
One is attempting to test the tds connection via tsql -H, which bypasses reading from the conf and only reads in the passed in values. Given that the conf above holds both the port and protocol version, it might be worthwhile to check that along with tsql -C to see if there are adjustments needed.
Also, at the bottom of the FAQ, it states that
real "Login incorrect" messages has code=18456 and severity=14
That is the error message being sent, so perhaps try Login Auditing (http://msdn.microsoft.com/en-us/library/ms175850.aspx) to see if pymssql is passing your credentials in properly.
That same section talks about different character sets messing up the mssql.connect, so also perhaps try a basic password (i.e., ASCII 65-90) to ensure that nothing is lost in translation. It looks like Aki works with Japanese, so perhaps this is a cause as well.
I faced the same problem when I installed via pip install pymssql because this installed a pre-built OS-specific binary wheel which does not support encryption.
This, even though I had installed a specific version of freetds, that I had expected would be used. Installing instead with pip install --no-binary pymssql pymssql gave an installation that works.
If you want to encrypt your database connections you will need to first build/install freetds, and then install pymssql as described here.
In this event I highly recommend ensuring your freetds.conf file specifies 'require' as opposed to 'request', to avoid silently falling back to unencrypted traffic. Using tcpdump -A and grepping for SQL keywords can help determining whether traffic is really encrypted.
I faced the same problem. Fortunately, I found out what is wrong. I had two different versions of FreeTDS on my machine. I installed one of them(v 0.91)by:
sudo apt-get install freetds-dev
later I found out it is not the last version and I downloaded the tar file of Freetds from freetds.org. When I ran tsql -C. it showed the correct path and I manipulated that freetds.conf correctly. With changing environment variable (http://www.freetds.org/userguide/envvar.htm), I could connect to database. However, each time I tried to connect by Pymssql I got error.
Finally, I looked at the log file and I figured out that Python is using the old version (v 0.91) but my last one was version 0.95.
>>> import os
>>> os.environ['TDSDUMP'] = 'stdout'
>>>
>>> import pymssql
>>> conn = pymssql.connect(server="sqlserverhost")
So, I deleted the version 0.91 with:
sudo apt-get purge freetds-common
and pymssql connected to the right version with correct configuration.
It may help you as well.
try follow the new notes in the pymssql documentation: azure need to take care of the user part. it's so weird, but worked. ms sql warehouse makes work on linux/mac so difficult..
http://pymssql.org/en/latest/azure.html
IMPORTANT: Do not use username#server.database.windows.net for the user parameter of the relevant connect() call! You must use the shorter username#server form instead!