Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Hey,
It is nice to see you have your proxmark finally running. Can you maybe summerize the problems you had to me, so I can write a HOWTO for people to fix the same kind of problems you have? Was the new 512kb chip the real problem so far?
Currently we finally have a LINUX version of the software working. For this we had to change the bootloader (kind of the same way as you did). We now changed it, that it will wait an infinite time for a new flash. But if the computer sends a CMD_START it will actually startup. This was needed because LINUX needs quite some time to initialize it. It looks a lot like the change you made to the bootloader. Do you think your way of starting up is possible for you to use? Can we try this out somewhere in the future?
For the antenna you can simple use a toilet-roll and wind 5 times a copper coil around it, solder it to the antenna connector plug. For tuning your antenna to avoid field-resonating you can use a potentiometer, I can lookup the resistance if you want to. Let me know if were able get the snoop function running. I would suggest you play a little with the distances since some readers have a stronger field than others. By playing I mean, putting the proxmark antenna 1CM on top of the reader and the card 1CM on top of the proxmark antenna, or variants to that.
If you run the command "tune" in the proxmark interface you will get a measure value of the antenna. Try to get that value at least to be 10000, then you have quite a good antenna.
Cheers,
Roel
Offline
Hey,
Thank you for the very clear explanation of the problems ya had. We are looking into the booting phase. The thing is, we don't have a Proxmark at the moment (with the 512kb chip) that produces the same problems. When we get our hands on one we will try to fix the firmware/bootloader.
I know for sure others who have similar problems can learn from your detailed description about the problems.
About the antenna, I must confess, I'm not a electronic engineer. For me it helped to play with a potentiometer, but you are right, when you know the correct resistor values, you could just as well use that.
If anyone would want to make a photo-shoot of the process of engineering an antenna, I guess a lot of users would be very pleased. Well, just drop me a mail if anyone is are willing to.
Thanks again, cheers,
Roel
Offline
Thanks for the offer, it could help, but maybe the (new) ones that will arrive soon have 512kb chips. I'll let you know
Offline
SummoningDark do you perhaps have a spare blank proxmark PCB. I've been trying to get some from theqlabs but almost 3 weeks later now he hasn't sent them and he's now gone overseas.
I'm all ready to build my proxmark, I have all the components, just missing a PCB, it's sooooo frustrating when I'm so close yet so far away and I'm itching to get one built.
If you do, let me know the cost. Cheers.
Offline
SD what's new? Have you made any progress with your problems? Now that I finished building my Proxmark3 (with 256K chip) I've delved deep into the code, bootloader, ARM and Windows client and I have a good understanding of it, maybe I can help.
That asm code above which is giving you problems effectively performs a jump to hardcoded address 0x2000 which is where the main code is expected to be (start.c) so be careful that when you change the source in armsrc your start address remains at 0x2000 otherwise the jump from bootrom to main code won't work properly.
I got sick of waiting for the flashing process taking so long and I thought that since the FPGA code doesn't change as often there is no need to keep reflashing it every time the main code changes. I've ended up splitting it up so that the Makefile in armsrc now produces two S-rec files, one with the FPGA code the other with the main ARM code.
The memory layout is so that the bootrom resides in range 0-0x1000 (same as before) the FPGA code sits in 0x2000-0x10000 and the main code is from 0x10000 onwards. Each of those three regions can be flashed individually and independently of each other from S-rec files , I had to change the bootloader code as it used to jump to 0x2000 but now it needs to jump to 0x10000. This seems to work well for me.
Last edited by d18c7db (2008-11-19 07:25:28)
Offline
I've put my code as 20081121_prox.zip in the Uploads section. In the /doc directory of that zip archive is a diff file (patch.txt) with the changes between my code and gerhard dekoninggans' code which I used as the base. Also see CHANGES.TXT for a plain English explanations of my changes.
Offline
Thank you d18c7db, it is moved to the sources map in the files section.
Offline
Please note that people wanting to use this new version must reflash all three sections of the FLASH, the bootrom the fpga and main arm code. This is due to the fact that the main arm code now executes at a different address and the bootloader jumps to this new address.
The best way to build the sources is to expand 2008.11.11.ProxSpace.zip giving you the development environment
ProxSpace
+20081013_prox
+devkitARM
+devkitWIN
Then extract the new version 20081121_prox.zip in there giving you
ProxSpace
+-20081013_prox
+-20081121_prox
+-devkitARM
+-devkitWIN
Get a command prompt in ProxSpace\20081121_prox\cockpit and run 0setpath.bat once then 5makeall.bat to build everything.
Finally flash all three sections like so:
..\winsrc\prox.exe bootrom ..\bootrom\obj\bootrom-merged.s19
..\winsrc\prox.exe fpga ..\armsrc\obj\fpgaimage.s19
..\winsrc\prox.exe load ..\armsrc\obj\osimage.s19
From there on, every time you change the ARM source code, you only need to reflash the new osimage.s19 and if you ever change the FPGA code you only need to reflash the new fpgaimage.s19
Have fun.
Last edited by d18c7db (2008-11-22 02:43:39)
Offline
Hey buddy, welcome back pretty cool you got to the bottom of your problem. Instead of ifdefs you could have it dynamically configurable in software by reading the DBGU_CIDR (Chip ID) register (on page 255, I think I added the defines for DBGU regs in the 20081121 code) not sure, seems so long ago, I've been making lots of changes to the code, ended up recompiling the FPGA code as well as I had to fixup an issue.
Still waiting on my color LCDs to turn up then I'll hook one up to the board, can't wait
What sort of stuff are you working on? You mentioned FPGA code changes.
Last edited by d18c7db (2008-12-06 09:52:24)
Offline
d18, did you get your board from me? if not e-mail me: i'm back from traveling and can send ASAP if not. I've sent a bunch out already.
Offline
Sure thing Andrew, thanks heaps. I emailed you but it may have ended in the junkmail at your end. I posted some pics in this forum and also up at flickr
The board is working great. You were right, the black soldermask is way sexy
Offline
TheQLabs,
I would like to place a order as well, but I have not gotten a return email from you.
Does anyone else provide Black Soldermask Proxmark3 Boards here?
I dont want to send $, and have to wait like 1 month or so for the boards
Offline
d18,
After reading your other posts it sounds like maybe you can give me some guidance. I'm unable to flash my pm3 with USB, but I can flash with JTAG. I've been able to successfully load the ebuller 09 17 image but that is about it. I've searched the threads and read the docs in the files directory and can't seem to figure out what I need to do next.
Is there a way to flash using the JTAG for the bootrom-merge, fpgaimage and osimage files? I'm using armpgm, hjtag and have the s256 chipset.
Thanks in advance to anyone with info or insight!
Offline
What exactly is the problem when trying to flash via USB ? Be aware that you have to issue the flash command twice. For example
prox load osimage.s19 (At this point the board reboots and the command fails, issue the command again within a couple of seconds)
prox load osimage.s19 (This second time the command should succeed and you should see some progress)
This behavior is by design, mainly because the code runs out of flash so you can't reprogram the flash you're running out of because the code would crash. What JW chose to do is reboot the board (first command) then as the board reboots the bootloader copies itself in RAM and checks if the PC is uploading code to it (second command). If the PC is sending code, the it gets flashed to FLASH which is OK because we're running out of RAM, if not, the board continues to boot and jumps to the main code back in FLASH. In principle this whole thing could be redesigned to avoid having to issue the command twice but since it already works OK, there's no great incentive to spend time on rewriting it.
Last edited by d18c7db (2009-01-23 08:14:58)
Offline
hi eldiabl0,
I'm a noob but I'd flashed the bootrom-merge, fpgaimage and osimage files succesfully with the wiggler adaptor (parallel port), u can use the following batch-script (I named it as "6flashall.bat" and put it into the "cockpit" folder) to flash all the 3 files with the "prox.exe", it's so easy. I'd tried the armpgm and hjtag as well, but armpgm can't open the 1211-version "bootrom-merged.s19" (same as j-flash arm ), hjtag can't flash "*.s19" file.
rem @echo off
..\winsrc\prox.exe bootrom ..\bootrom\obj\bootrom-merged.s19
..\winsrc\prox.exe bootrom ..\bootrom\obj\bootrom-merged.s19
..\winsrc\prox.exe fpga ..\armsrc\obj\fpgaimage.s19
..\winsrc\prox.exe load ..\armsrc\obj\osimage.s19
Offline
What exactly is the problem when trying to flash via USB ? Be aware that you have to issue the flash command twice. For example
When I attach the USB cable to pm3 Windows doesn't recognize the board. When I run any of the batch files that require comms to the board I get the beloved "..no device connected, polling for it now." message. I'm spinning my wheels on flashing but I don't think I'm even communicating with the board at this point.
shinechou - thanks for the batch file idea. You mentioned that you used the wiggler to flash the board. I'm going to assume for now that you're running this under Windows. Does your OS see the board when you plug it into the USB port? When I run prox.exe I keep getting the "polling" for board message.
Thanks.
Offline
After the board was programmed with ebuller, what happens with the LEDs when you plug it into the USB. Normally all LEDs light up, then only yellow, then yellow and green together, then only red, then all LEDs turn off ??? If that is not the case the board doesn't appear to be booting.
If no LEDs come on at all then (obviously) it might not be getting power from USB.
With the board off, check with a multimeter the USB connection from the USB plug all the way back to the ARM. Check if either D- and D+ on the USB plug shorts to each other or to VCC/GND (examine D8 visually as well for solder bridges), check that R4/R5/R6 are fitted correctly, measure their value, should be 27/27/1k5 respectively.
If the board appears to boot OK and you've checked the USB path from the connector all the way back to the ARM, you shouldn't have any comms problems. I suspect it might be a hardware problem.
Offline
After the board was programmed with ebuller, what happens with the LEDs when you plug it into the USB. Normally all LEDs light up, then only yellow, then yellow and green together, then only red, then all LEDs turn off ??? If that is not the case the board doesn't appear to be booting.
The version of the board I have doesn't have any LED's, so there's that. Is there a document or anything that would illustrate how I could install LED's? I haven't really found anything on that topic.
I'll try and check the other options you mentioned. There are no solder bridges btw.
Thanks for your input. I'll try and figure out the other items you mentioned and measure those.
Offline
d18,
On another note. When I run prox.gui and hit the "Reset&Run" button in armpgm, the gui seems to see the board for a split second and then closes and tells me that it lost communications.
Don't know if that helps at all.
Thanks.
Offline
The board schematics and component placement are freely available in the files section. Did you buy the board premade? Who from?
Offline
shinechou - thanks for the batch file idea. You mentioned that you used the wiggler to flash the board. I'm going to assume for now that you're running this under Windows. Does your OS see the board when you plug it into the USB port? When I run prox.exe I keep getting the "polling" for board message.
Thanks.
ya, I'd run it under Windows and OS will show "Unknown USB device" when I plug it into the USB port before I flash it successfully.
I think the LED d18c7db said means the component "D4/D5/D6/D9", ur board must has these components! u check it!
Offline
The board schematics and component placement are freely available in the files section. Did you buy the board premade? Who from?
I bought it premade. I've got the schematics and a few LED's, I'll set it up. I have a question on the LED. I've got a number of 5v 30mA LED's, will those work or do I need a lower voltage LED?
I picked this unit up from Qlabs.
Thanks.
Offline
eldiabl0 wrote:shinechou - thanks for the batch file idea. You mentioned that you used the wiggler to flash the board. I'm going to assume for now that you're running this under Windows. Does your OS see the board when you plug it into the USB port? When I run prox.exe I keep getting the "polling" for board message.
Thanks.
ya, I'd run it under Windows and OS will show "Unknown USB device" when I plug it into the USB port before I flash it successfully.
I think the LED d18c7db said means the component "D4/D5/D6/D9", ur board must has these components! u check it!
I've only been able to flash the board successfully with the 2008.09.17-ebuller code. I can't get any other code to successfully flash the board. Even after I flash it with the ebuller code I get the same unrecognized Windows error.
Still working on it...
Offline