search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
4.08k stars 1.07k forks source link

[ISSUE] hf_msdsal emulation mode #1548

Closed cabiamdos closed 2 years ago

cabiamdos commented 2 years ago

Things to try before submitting bug report read the troubleshooting guide

Compilation problems Try compiling with verbose. make VERBOSE=1 with main makefile or make V=1 with cmake.

flashing problems Have you followed the instructions properly? ie, flashed bootrom seperately first if you are going from Offical repo to RRG/Iceman repo.

-

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. Go to '...' proxspace
  2. Click on '....' runme64.bit
  3. click the button with the hf_msdsal mode
  4. See error: it tries reading the card but it enters in an infinite loop

Expected behavior read the card and after that enter in emulation mode

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

[usb] pm3 --> data tune [=] REMINDER: 'hw tune' doesn't actively tune your antennas, it's only informative [=] Measuring antenna characteristics, please wait... [/] 10 [=] ---------- LF Antenna ---------- [+] LF antenna: 25.87 V - 125.00 kHz [+] LF antenna: 16.81 V - 134.83 kHz [+] LF optimal: 26.68 V - 122.45 kHz [+] Approx. Q factor (): 7.1 by frequency bandwidth measurement [+] Approx. Q factor (): 7.8 by peak voltage measurement [+] LF antenna is OK [=] ---------- HF Antenna ---------- [+] HF antenna: 14.88 V - 13.56 MHz [+] Approx. Q factor (*): 4.3 by peak voltage measurement [+] HF antenna is OK

(*) Q factor must be measured without tag on the antenna

[+] Displaying LF tuning graph. Divisor 88 (blue) is 134.83 kHz, 95 (red) is 125.00 kHz.

[usb] pm3 --> qt.qpa.fonts: Unable to enumerate family ' "Hidden Treasures of the Bauhaus Dessau" '

Additional context Add any other context about the problem here. When I load an existing track2 to the proxmark3 and go to the card reader it doesn't interact correctly.

cabiamdos commented 2 years ago

My contacts are @cabiam for telegram and cabiam@criptext.com for email. Thanks

iceman1001 commented 2 years ago

Your description of the issue is one sentence and it doesn't make any sense in terms of the hf_msdsal standalone mode.

Do spend time to make a clean and precise description on what the issue is and how to replicate it.

cabiamdos commented 2 years ago

Yes,

So I enter into the proxspace, I run the runme64.bat file, cd proxmark3, and run the command pm3. Now, once I am inside it, I press the button with the hf_msdsal standalone mode loaded, and I try to scan a mastercard card, and after that I expect the proxmark3 to enter in emulation mode (waiting for the card reader), but that never happens! When I am scanning the card for the track2, it enters in a infinite loop, and it never end up emulating the card. The video of the issue can be watched here (https://vimeo.com/659974338).

The expected behaviour is this one (https://vimeo.com/411655632)

Thanks

iceman1001 commented 2 years ago

Which PoS reader are you using?
What do you mean with "I am scanning the card for the track2" ?

Try using a file sharing service that doesn't require one to create an account.

Have you read the comments in the source file https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/Standalone/hf_msdsal.c ? Where it states it works on VISA?

cabiamdos commented 2 years ago

If it doesn't read the card data, the card can't be emulated automatically by scanning (as we can see here https://vimeo.com/659974338 or https://www.mediafire.com/file/5xl2sg29c9h82lf/IMG_7652.MOV/file). So I end up editing the hf_msdsal.c file, end up writing the track2 of that card that I previously scanned with other command "emv exec -sat" and loaded there the track2 as hf_msdsal.c documentation states.

// It is possible to initialize directly the emulation mode, having "token" with data and set "chktoken" = true ;)

Which PoS reader are you using? I am using a SUMUP POS terminal, but it never completes the transaction. Here is another video that shows the transaction is not completed and it end up in "please insert the card" (https://vimeo.com/manage/videos/659991198 or https://www.mediafire.com/file/u5p9fxbzxbtrecl/IMG_7653.MOV/file).

What do you mean with "I am scanning the card for the track2" ? I mean (https://salmg.net/2020/04/24/hf_msdsal-new-proxmark-standalone-mode/). When the you put the card next to the proxmark and the standalone is in reading mode it should end up getting all the card data, and enter in emulation mode automatically, but in my case I end up in an infinite loop and never enters in emulation mode (https://www.mediafire.com/file/5xl2sg29c9h82lf/IMG_7652.MOV/file)

I have read the comments on that file, and I have read the article.

[#] Stand-alone mode, no computer necessary [#] >>Reading Visa cards & Emulating a Visa MSD Transaction a.k.a. MSDSal Started <<

the description says "reading visa cards & emulating visa msd transactions"

  • The initial mode is reading with LED A as guide.
  • In this mode, the Proxmark expects a Visa Card,
  • and will act as card reader. Trying to find track 2.
iceman1001 commented 2 years ago

You state that you are using a mastercard. image

cabiamdos commented 2 years ago

Yes, I am using a mastercard card (I thought it was VISA&MASTERCARD only, not discover, or amex, or unionpay). But I have used a VISA card too and it didn't work out. It also didn't work out my VISA card when trying to find track 2 when exececuting "emv exec -sat", it only detected the first 16 digits. I will try with more VISA cards because right now I only have one VISA and a few MASTERCARD, and will determine if the error persist.

Thanks

cabiamdos commented 2 years ago

I have tried with one more VISA card (different to the one I tried before on my own appart all the mastercards I have and the one that appear on the video) and I enter exactly in the same loop. And if I load the track2 myself of this VISA card into the hf_msdsal standalone mode, and then go to the card reader, I get exactly the same loop

What is going wrong? Is anybody having the same issue?

merlokk commented 2 years ago

Some cards don't send track2 in some modes.

    By default:                    Transaction type - MSD
    -v, -V, --qvsdc                Transaction type - qVSDC or M/Chip.
    -c, -C, --qvsdccda             Transaction type - qVSDC or M/Chip plus CDA (SDAD generation).
    -x, -X, --vsdc                 Transaction type - VSDC. For test only. Not a standard behavior.
    -g, -G, --acgpo                VISA. generate AC from GPO.

Better to use MSD mode. But VISA deprecated it several years ago( but maybe your card can work in this mode...

cabiamdos commented 2 years ago

According to (https://www.uspaymentsforum.org/wp-content/uploads/2020/02/Contactless-Operating-Mode-Requirements-Clarification-WP-FINAL-Feb-2020.pdf) on page number 6 and number 7, mastercard support msd, and visa deprecated on 2019.

cabiamdos commented 2 years ago

Also I have loaded a track2 in the standalone mode, and with the acr122u nfc reader connected to a raspberry pi, I have tried emulating a card payment with another program.

When I put the proxmark3 in emulating mode (of a working VISA card) next to the acr122u, the command prompt doesn't display the TLV encoded data (that it should output as when I try a normal card), and eventually the proxmark automatically disconnect from the laptop (but not phisically, the computer makes the sound as if I unplugged physically but it doesn't in reality)

iceman1001 commented 2 years ago

So far I see no evidence of a bug. I will close this issue, when you find a way to replicate a bug feel free to open a new issue.

The forum is the right place to discuss how to use it.

cabiamdos commented 2 years ago

Well, I have loaded the hf_msdsal standalone mode on the proxmark, tried to scan a VISA card and it didn't work (it enters in a infinite loop, with video proofs). Also I have tried to scan it with a card reader and it also didn't work (it enters in a infinite loop, with video proof).

How is that you don't see any evidence of a bug?

Thanks

iceman1001 commented 2 years ago

Because you are not providing any details than videos to a place which needs a login. Ie unuseable for me. You don't provide any information about your card that you are testing with, not to mention you used mastercard first when you starting this issue. You don't take in consideration @merlokk answer about the VISA card, and you act that you done it all.

I will give you one more chance to bring relevant detailed information about the issue you think you are experiencing.

merlokk commented 2 years ago

let me explain something about payments) (maybe I add this text to documents....) there are several actors in the payment systems. we will talk about:

  1. EMV
  2. payment networks
  3. card vendors
  4. bank issuer
  5. pos terminal vendors
  6. acquirer (bank or specialized company)
  7. many more, but we don't talk about them ok)

there is an EMV standard for payment methods. The EMV documents describe payments rather vaguely, and EMV has too much room for technical implementation options.

payment networks, some of which are the EMV members (we have like 7 big and many domestic). It is Visa, Mastercard, JCB... they have additional documentation about payment processing, and usually, it provides by signing NDA only. this documentation has less space for imagination how to make payments than the EMV and include tests (one of the payment networks have like 2500 pages with like 6-8 tests per page - as sample)) ) but this documentation is not clear and univocal too.

card vendors) There are many card vendors, and each card vendor has its own hardware for the card and its own filesystem and sometimes its own SDK (java, basic, c, whatever...). And it strange) but it is incompatible. to be honest, there is the Java Card specification, and they tried to fix this situation. and they almost succeeded) but if we have a complex applet - it usually cant be just launched on another java card from the other vendor. It needs to adapt the applet to launch it (mainly because of differences in the crypto API and sometimes lack of another functionality).

bank issuer buy card, the applet (usually from one vendor) and personalize it with his understanding of the EMV. And it is strange) but sometimes it personalizes it differently for the same card, and there are some differences in the card's batches, and maybe the next batch will be from another card vendor. So records on the card differ on the same card types from the same bank...

pos terminal vendors (here many actors, but we do not split them) create kernels for payment processing and some software developers create payment applications according to EMV. But) each pos vendor has its own unique kernel API, and the software on pos works with some deviations...

acquirer buys pos terminals and pos terminals vendor adapt them to acquirer's processing system. and here big differences. All the acquirers have a unique processing system (sometimes they use the same software, but the settings are always not the same). and on this phase, we have the situation that the same pos with the same software/hardware may behave differently from different acquirers

conclusion) there is no strict standard about personalization/payment/etc each vendor of each hardware/software have a slightly different implementation of the standards and now we have big pain in the payment industry because some pos are just not reading some cards, and there is no pos-payment gateway system that can process all the cards. So) there is no universal method that can emulate all the EMV cards. Emulators from consulting companies (like proxmark3) but with closed design) cost like $20k-$50k. And inside, they have a data file with a script file to emulate each card... And I saw many times in the pos transaction processing code "magic if" - just several lines like: if (BIN=='444444') {do something} else {do another}. or elseif))))

so) for emulation (if you want), it needs to be as close to the original card as possible. And it cant be done without deep knowledge of EMV standards and payments. And EMV is pretty well protected if all the parts are done correctly. There is no "magic" emulators.

btw) I mentioned some attack vectors) these "magic if" sometimes they do evil things inside and sometimes cards with them will be easily hacked) I saw very strange things like just skipping fDDA for visa cards... or making the only first part of the m/chip transaction for mastercard...

p.s I hope this text is interesting info about "state of the art" in the payment industry)

cabiamdos commented 2 years ago

Well, the videos I have uploaded to mediafire which doesn't require login. And I thought vimeo didn't require login to watch a video, at least to me it doesn't. I don't find a way that you can replicate this bug because you may not have the same bank card that I have. So even if I show the full card data, you could not replicate the bug.

I see some cards doesn't send track2 on some modes. Maybe in the modes hf_msdsal is configured, my card doesn't send track2. And the information @merlokk is talking about in the last comment is very interesting.

I thought everything was more unified, and that if some guy in USA is making work hf_msdsal mode with a VISA cards (without taking care of the bank issuer) I could replicate it. But I see, each acquirer may uses different hardware, with different software to program their cards... very difficult to replicate. I also didn't know about private companies that do this emulation ting. And the kernel stuff. So I guess if I go with my cards to pay for goods in other countries they are supposed to work but as there is too much friction even a non-emulated card can fail.

I really appreciate your text. I have search also books in amazon but I find too little info about EMV stuff.

Thanks again