Proxmark3 community

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

New ProxSpace development environment available for download

Instead of creating detailed instructions on setting up the development environment, I opted to create a new ProxSpace archive with the entire environment already set up, with both ARM and x86 compilers, see packages.txt in the root of the archive for the packages used. It's available for download from here, use 7zip to extract it the root of C:\ then run 0setpath and 5makeall in the cockpit directory. The archive extracts to 10x the size so about 260Mb free space is needed.

If you choose to extract it to another drive/path = <new_path>, you must modify the paths in the files <new_path>\ProxSpace\pm3\cockpit\0setpath.bat and <new_path>\ProxSpace\msys\etc\fstab

I can't seem to use relative paths in 0setpath anymore due to "make -C .. -s _test" in _checkmake.bat throwing a uname not found error, if someone has any ideas, let me know.

Last edited by d18c7db (2010-02-22 03:08:17)

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

Sorry just realised that the ProxSpace was missing this lib. If you donloaded it, no need to re-download the new one, just put this lib in msys\mingw\bin

Would it be a good idea to compile the client binaries static so as not to have this issue of missing libs when moving them to a non development system ?

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

Has this environment been positively verified to produce working armsrc binaries under Windows?  Specifically, have you physically tried to use the bootrom, FPGA image, and OS image produced by the environment and latest SVN on an actual PM3?

I'm trying to figure out if my issues are related to the environment, to the current SVN code, or to the board and I need to start eliminating possibilities.

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

I'm still getting "Waiting for Proxmark to appear on USB..." when running flasher.exe compiled under this environment.  The PM3 definitely shows up as a real device in Device Manager.  Would you say this is related to the environment or the current SVN code?

Here is the output from 5makeall.bat:

C:\ProxSpace\pm3\cockpit>5makeall.bat
**************
*** armsrc ***
**************
perl ../tools/mkversion.pl .. > version.c || cp ../common/default_version.c version.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/version.o version.c
arm-eabi-objcopy -O elf32-littlearm -I binary -B arm --redefine-sym _binary____fpga_fpga_bit_start=_binary_fpga_bit_star
t --redefine-sym _binary____fpga_fpga_bit_end=_binary_fpga_bit_end --prefix-sections=fpga_bit  ../fpga/fpga.bit obj/fpga
.o
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/start.o start.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/iso15693.o iso15693.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/lfops.o lfops.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/hitag2.o hitag2.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/appmain.o appmain.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/printf.o printf.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/util.o util.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/string.o string.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb -mthumb-interwork -o obj/usb.o ../common/usb.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/fpgaloader.o fpgaloader.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/legicrf.o legicrf.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/iso14443crc.o ../common/iso14443crc.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/crc16.o ../common/crc16.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/iso14443a.o iso14443a.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/iso14443.o iso14443.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/legic_prng.o ../common/legic_prng.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -O6 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO1444
3a -DWITH_ISO14443b -I. -mthumb-interwork -o obj/crc.o ../common/crc.c
arm-eabi-ld -g -Tldscript -Map=obj/fullimage.map -o obj/fullimage.elf obj/version.o obj/fpga.o obj/start.o obj/iso15693.
o obj/lfops.o obj/hitag2.o obj/appmain.o obj/printf.o obj/util.o obj/string.o obj/usb.o obj/fpgaloader.o obj/legicrf.o o
bj/iso14443crc.o obj/crc16.o obj/iso14443a.o obj/iso14443.o obj/legic_prng.o obj/crc.o c:/proxspace/devkitarm/bin/../lib
/gcc/arm-eabi/4.4.2/libgcc.a
arm-eabi-objcopy -F elf32-littlearm --remove-section .fpgaimage obj/fullimage.elf obj/osimage.elf
BFD: obj/fullimage.elf: warning: Empty loadable segment detected, is this intentional ?

arm-eabi-objcopy -Osrec --srec-forceS3 --strip-debug --no-change-warnings --change-addresses -0x100000 --change-start 0
--change-section-address .bss+0 --change-section-address .data+0 --change-section-address .commonarea+0 obj/osimage.elf
obj/osimage.s19
arm-eabi-objcopy -F elf32-littlearm --only-section .fpgaimage obj/fullimage.elf obj/fpgaimage.elf
BFD: obj/fullimage.elf: warning: Empty loadable segment detected, is this intentional ?

BFD: obj/fullimage.elf: warning: Empty loadable segment detected, is this intentional ?

BFD: obj/fullimage.elf: warning: Empty loadable segment detected, is this intentional ?

BFD: obj/fullimage.elf: warning: Empty loadable segment detected, is this intentional ?

arm-eabi-objcopy -Osrec --srec-forceS3 --strip-debug --no-change-warnings --change-addresses -0x100000 --change-start 0
--change-section-address .bss+0 --change-section-address .data+0 --change-section-address .commonarea+0 obj/fpgaimage.el
f obj/fpgaimage.s19
***************
*** bootrom ***
***************
perl ../tools/mkversion.pl .. > version.c || cp ../common/default_version.c version.c
      4 [main] perl 4972 child_copy: linked dll data write copy failed, 0x332000..0x332370, done 0, windows pid 4972, Wi
n32 error 487
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb -mthumb-interwork -o obj/version
.o version.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb-interwork -o obj/ram-reset.o ram
-reset.s
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb-interwork -o obj/flash-reset.o f
lash-reset.s
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb-interwork -o obj/fromflash.o fro
mflash.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb-interwork -o obj/usb.o ../common
/usb.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb-interwork -o obj/bootrom.o bootr
om.c
arm-eabi-ld -g -Tldscript-flash --oformat elf32-littlearm -Map=obj/bootrom.map -o obj/bootrom.elf obj/version.o obj/ram-
reset.o obj/flash-reset.o obj/fromflash.o obj/usb.o obj/bootrom.o
arm-eabi-objcopy -Osrec --srec-forceS3 --strip-debug --no-change-warnings --change-addresses -0x100000 --change-start 0
--change-section-address .bss+0 --change-section-address .data+0 --change-section-address .commonarea+0 obj/bootrom.elf
obj/bootrom.s19
**************
*** client ***
**************
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/proxmark3.
o proxmark3.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/crc16.o ..
/common/crc16.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/iso14443cr
c.o ../common/iso14443crc.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/data.o dat
a.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/graph.o gr
aph.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/ui.o ui.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmddata.o
cmddata.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdhf.o cm
dhf.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdhf14a.o
 cmdhf14a.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdhf14b.o
 cmdhf14b.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdhf15.o
cmdhf15.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdhflegic
.o cmdhflegic.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdhw.o cm
dhw.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdlf.o cm
dlf.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdlfem4x.
o cmdlfem4x.c
cmdlfem4x.c: In function 'CmdEM4x50Read':
cmdlfem4x.c:279: warning: 'tmpbuff' may be used uninitialized in this function
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdlfhid.o
 cmdlfhid.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdlfti.o
cmdlfti.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdparser.
o cmdparser.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cmdmain.o
cmdmain.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/proxusb.o
proxusb.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3   -c -o guidummy.o g
uidummy.c
g++  -Wall -O3 obj/proxmark3.o obj/crc16.o obj/iso14443crc.o obj/data.o obj/graph.o obj/ui.o obj/cmddata.o obj/cmdhf.o o
bj/cmdhf14a.o obj/cmdhf14b.o obj/cmdhf15.o obj/cmdhflegic.o obj/cmdhw.o obj/cmdlf.o obj/cmdlfem4x.o obj/cmdlfhid.o obj/c
mdlfti.o obj/cmdparser.o obj/cmdmain.o obj/proxusb.o guidummy.o -L/opt/local/lib -L/usr/local/lib -lusb -lreadline -lpth
read  -o proxmark3
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/snooper.o
snooper.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/guidummy.o
 guidummy.c
g++  -Wall -O3 obj/snooper.o obj/crc16.o obj/iso14443crc.o obj/data.o obj/graph.o obj/ui.o obj/cmddata.o obj/cmdhf.o obj
/cmdhf14a.o obj/cmdhf14b.o obj/cmdhf15.o obj/cmdhflegic.o obj/cmdhw.o obj/cmdlf.o obj/cmdlfem4x.o obj/cmdlfhid.o obj/cmd
lfti.o obj/cmdparser.o obj/cmdmain.o obj/proxusb.o obj/guidummy.o -L/opt/local/lib -L/usr/local/lib -lusb -lreadline -lp
thread -o snooper
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/cli.o cli.
c
g++  -Wall -O3 obj/cli.o obj/crc16.o obj/iso14443crc.o obj/data.o obj/graph.o obj/ui.o obj/cmddata.o obj/cmdhf.o obj/cmd
hf14a.o obj/cmdhf14b.o obj/cmdhf15.o obj/cmdhflegic.o obj/cmdhw.o obj/cmdlf.o obj/cmdlfem4x.o obj/cmdlfhid.o obj/cmdlfti
.o obj/cmdparser.o obj/cmdmain.o obj/proxusb.o obj/guidummy.o -L/opt/local/lib -L/usr/local/lib -lusb -lreadline -lpthre
ad -o cli
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/flash.o fl
ash.c
gcc -std=gnu99 -I. -I../include -I../common -I/opt/local/include -Wall -Wno-unused-function  -g -O3 -c -o obj/flasher.o
flasher.c
g++  -Wall -O3 obj/flash.o obj/flasher.o obj/proxusb.o -L/opt/local/lib -L/usr/local/lib -lusb -lreadline -lpthread -o f
lasher
C:\ProxSpace\pm3\cockpit>

The perl error at the beginning of the bootrom compile seems to stand out at me, but I don't know what that would affect.

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

The environment was verified to compile without errors but that doesn't mean that the current SVN is without issues, hence the unstable label.

And that perl error is weird, the first call to perl in armsrc completes fine but the second call in bootrom seems to fail even though both call do exactly the same thing but in different directories, does that happen every time ?

Last edited by d18c7db (2010-02-22 06:56:04)

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

Yes, it does happen every time.

If you don't mind the suggestion, I would only package the environment with a code base that is fully verified on all platforms, including flashing all three files to a board for testing.

If all of this work is being done in the hopes of advancing usability and maintainability, then this it's essential that these types of "packaged" releases are stable.

A the very least, I suggest distributing the compile environment as a standalone instead of packaging non-verified code with it.

Also, just to help me out, could you try compiling the current SVN and let me know what your results are?  Do do all ARM images work fine on the PM3?  Does the client work?  If so, what platform are you working on?  Perhaps then I can start figuring out what the heck is going on on my end. :-)

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

Can you try something for me, run 0setpath.bat then cd ..\armsrc and run the command
perl ../tools/mkversion.pl .. > version.c || cp ../common/default_version.c version.c

Try it several times in a row, then cd ..\bootrom and try that command again, several times, does either of those tests cause the crash?

To answer your question, I tried this compile environment ina virtual machine on a pristine fresh install of WinXP Pro SP3 latest sevice packs, nothing else installed except AVG 8.5 antivirus. My compile output is exactly identical to the one you posted above except without the perl crash in the second call.

I have *only* tried the compile functionality and that it produces the expected output files, I have no flashed them yet on a board as my board was at home. Will try now and let you know.

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

OK and I just verified a flash, flashing the elf produced by the compiler will kill the board but that is not an issue with the compiler, it is a problem with the elf parser code in the current SVN (Adam, this is why you end up with a constantly rebooting board).

Since I know what I'm doing, I binary patched the elf file with a hex editor to kill the extra segments that are causing the problem and the flash was successful:

C:\ProxSpace\pm3\client>flasher.exe os ..\armsrc\obj\osimage.elf
Waiting for Proxmark to appear on USB... Found.
Flashing os from ..\armsrc\obj\osimage.elf
count=5 phoff=34
type=1 offset=0 paddr=0 vaddr=0 filesize=d4 memsize=d4 flags=6 align=8000
type=1 offset=8000 paddr=110000 vaddr=110000 filesize=140b8 memsize=140b8 flags=5 align=8000
flashing offset=8000 paddr=110000 size=140b8
WriteBlock(110000, 256, f8 b5 57 46 46 46 c0 b4 ... f0 b5 5f 46 56 46 4d 46)
WriteBlock(110100, 256, 44 46 f0 b4 95 b0 0d 90 ... 04 9e 40 42 76 42 03 96)
...blah blah...
WriteBlock(123f00, 256, 67 2c 20 67 6f 74 20 6c ... 29 e1 ff ea 78 47 c0 46)
WriteBlock(124000, 184, 99 fa ff ea 78 47 c0 46 ... ff ff ff ff ff ff ff ff)
type=1 offset=20000 paddr=0 vaddr=200000 filesize=4 memsize=4 flags=6 align=8000
type=1 offset=20008 paddr=0 vaddr=200008 filesize=0 memsize=8066 flags=6 align=8000
type=1 offset=27fe0 paddr=0 vaddr=20ffe0 filesize=0 memsize=10 flags=6 align=8000

done.
Have a nice day!

C:\ProxSpace\pm3\client>proxmark3
proxmark3> hw v
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 310-suspect 2010-01-10 03:38:55
#db# os: svn 368-suspect 2010-02-22 07:20:16
#db# FPGA image built on 2009/12/ 8 at  8: 3:54
proxmark3> exit

C:\ProxSpace\pm3\client>

To also answer your other question about "Waiting for Proxmark to appear on USB...", that is because the current development is driven mainly by the linux crowd and they have chosen in the name of uniformity and cross-platform compatibility to use libusb, and I'm not begrudging that since I know where they're coming from, but the hardware is no longer plug'n'play on the windows side, you have to install some drivers, so the proxmark appears in your device manager under "LibUSB-Win32 Devices" instead of under "Human Interface Devices".

Since this is a "hot off the press development", there are no instructions to make those drivers unless you know what you're doing.

This is the magic: run msys\mingw\bin\inf-wizard.exe, it is a GUI app, click next, select the device with PID/VID 9AC4/4B8F, on the next screen leave everything as is (or you can put proxmark3 in the manufacturer name), click next and save the files back in msys\mingw\bin

Next go into the Windows Device Manager (right click My Computer, select Manage) and expand the Human Interface Devices tree, double click each device in turn and select the Details tab until you find the one with PID/VID 9AC4/4B8F, exit that dialog and right click that last device, select Update Driver, select "No" to windows connecting to Windows Update, select advanced on the next screen, select "Don't search, I will choose...", select "Have Disk", then browse to msys\mingw\bin and let it install the driver.

Your PM3 should now appear under "LibUSB-Win32 Devices", phew... then you can flash it with the flasher (don't as it will kill it).

Final word, please both you and others understand that you are playing with NON STABLE code, brand new developments in procedures for using the board, etc so please don't whinge if things arent' smooth, stick to the "ProxSpace2009 Summer edition" for now and let us finish this to the point where we can make a proper release. BTW the new ProxSpace I just uploaded, the one marked UNSTABLE, is not a release, it should NOT be use by anyone except those that are doing active development on the Windows platform, I can't stress that enough. If this is causing too much confusion I'll be happy to delete that file (insert smilies in that last paragraph, I'm not angry, simply trying my hardest explain where we are so that everyone is crystal clear).

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

d, I understand that it's a development release and unstable, so I don't have a major problem with that.  I'm always happy to help test and provide useful feedback in any way that I can.  In that respect, you can consider me an advanced beta tester.  I just have some concern over people ripping apart Windows compatibility and and leaving others twisting in the wind.  As an example, I can point you to the change over to libusb, which doesn't provide signed x64 drivers.  This means that any Vista/7 x64 user now has to disable built-in security features and jump through hoops in order to get the unsigned driver to run.

I can already hear someone in the back yelling out "Well why don't you use a different OS!?".  I don't want to turn this into an OS debate.  I'm fairly comfortable with the three major platforms out there and in fact run them all to varying degrees, but for many reasons Windows is my primary platform.  I also understand that the nature of the project is such that the developers are more or less donating their time to the project in order to advance it, so I don't want to sound ungrateful either.  I am simply asking that the people contributing to the proxmark code consider how some of these sweeping changes affect the user base, including its Windows users.

Again, I know these are cutting edge development releases that are unstable.  However I do feel that if I don't speak up for other Windows users, we'll get left by the wayside by the time it's considered "stable".

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

How did the tests I suggested go?

Oh wait, you'll love this next one, the client doesn't build with the GUI "graph window" anymore, looking into what's required but it seems I need to download Qt for MinGw which is another 260Mb download, so the ProxSpace will most likely blow up after install to at least half gig of disk space

Last edited by d18c7db (2010-02-22 09:59:54)

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

After further investigation what appears to be happening is that Norton AV's heuristics scanner is freaking out about the compile.  After a few more runs, I found varying numbers of errors each time.  One time I got almost 6 errors before NAV declared that one of the executable files was performing highly suspicious operations and killed it.  Once I added the ProxSpace directory to the exception list, the problem appeared to go away, so I think we're clear on that.

In regards, to the x64 driver signing, I've found a *temporary* solution: http://www.ngohq.com/home.php?page=dseo

It enables the use of Windows' test mode without having to manually select "Disable Driver Checking" from the boot menu each time.  The reason this should be considered highly temporary is that test mode disables several key security checks within the OS and leaves the system vulnerable to certain avenues of attack.

If we can find a solution that can use normal HID profiles, that would provide the best compatibility with no mucking around with driver filters/replacements and the like.

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

Oh wait, you'll love this next one, the client doesn't build with the GUI "graph window" anymore, looking into what's required but it seems I need to download Qt for MinGw which is another 260Mb download, so the ProxSpace will most likely blow up after install to at least half gig of disk space

In my head I am imagining the classic "guy in a leaking boat" scenario where as he plugs one hole with his finger another pops up.  He plugs that one with another finger only to have a third pop up, etc. :-)

adam@algroup.co.uk

Contributor

From: UK

Registered: 2009-05-01

Posts: 203

Website

Re: New ProxSpace development environment available for download

Ah, great, thanks for looking into that d18c7db...

In order to try and get the build environment set up to go smoothly, I propose the following change:

Index: common/Makefile.common
===================================================================
--- common/Makefile.common    (revision 374)
+++ common/Makefile.common    (working copy)
@@ -41,7 +41,8 @@
FLASH_TOOL=client/flasher
DETECTED_OS=UNAME
# You may/should set this in your environment
-LIBGCC ?= $(shell $(CC) -print-libgcc-file-name)
+LIBGCC ?= $(DEVKITARM)/lib/gcc/arm-eabi/4.4.2/libgcc.a
+PATH := $(PATH):$(DEVKITARM)/bin

This means it should 'just work' under Linux if you follow the devkitPro installation instructions correctly... (once we sort out the elf stuff, of course!)

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

Sure, that looks good

The good thing with ?= assignments is that I can have overrides in my Eclipse IDE and switch compilers quite easily, but yeah, for a smooth transition the default should be as per your patch.

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: New ProxSpace development environment available for download

Let me clarify a few of what has been said here.

First of all, no, I'm not a linux guy, I'm running Mac OS X, so please don't think the choices are made out of pure selfishness. Quite the contrary. As a personal anecdote, all my personal projects are made crossplatform (including GUI) by default, and they all compile and run just fine under Windows. I even take the effort to static link them so it's easy for my windows users to just use them without any hassles. I plan to do the same for the proxmark. Usability and ease of installation are very important to me, so please stop being paranoid thinking the world doesn't like you because you're using windows and that we just plan to ditch you in a hole and set fire. Although it might cross my mind if you continue to complain with baseless reasons while we're still actively working on it

And guess what as well, under Mac OS, which is my primary dev OS, I also have to install libusb, I also have to install QT, gcc-arm-elf or whatever and so on. All of that were also a nightmare to setup (especially since snow leopard because of the 64bit switch which is causing a lot of trouble. It took me a whole day during 26c3). So don't think I'm trying to just make my life easier with these changes. Also don't think I'm ignoring windows on that. The reason the windows build had be broken for 2weeks, as you now can see, was because it was *not* a 10min change to fix it, since I wanted to have a cross-platform code.

Having a cross-platform code will NOT yield to a less stable code, quite the contrary. It is going to increase the stability because we won't have to maintain multiple version at once, and we'll be able to focus our effort on one codebase. And, the windows platform will especially NOT be left on the side (way less in fact than the old code), because the code will just be the same for all platforms. Having a unique codebase for the three platforms especially including using QT for the QUI (well, I don't really like QT, because it's too overkill for what we're using. I usually use wxwidgets for all my personal projects, because it yields to smaller binary standalone release for... WINDOWS! But I suppose there are reasons for the QT choice...), will allow us to improve the GUI and the windows users will benefit from it right away and will not rely on someone being courageous enough to port the improvement mades on linux/macos back to windows.

So really... don't think we're ditching windows, quite the contrary, we're planning for the future here, such that the three platforms will enjoy the exact same functionalities (which also will simplify the documentation process).

Yes, for the usb driver, it's currently slightly annoying. Don't think I really like that either. I spent hours trying to figure out why it was not working using the filter version (which didn't need the crazy .inf wizardy). But messages from mailing lists seems to indicate the filter version is buggy. But there are hopes. libusb 1.0 is in pre-alpha stage for windows. I initially tried to use it too to ease the pain for windows, but it seemed not mature enough so I went back to libusb-win32 until it gets better. Hopefully soon.

As a side note, the fact that I (or we) commit new changes doesn't mean it's a stable and finale change. At the moment, it seems that you are trying to compile every single commit I do. But that's not really helping. I haven't completed all the usability testings and so on (we don't even have regression test for them), because I'm still at the "compilation stage" process. I'm working at bringing the three platforms together for the compilation first, with the less amount of inconvenience. But it is *not* completed yet. So I think it's quite premature to try to provide a dev env. for windows (for instance), because I'm still working at making it simpler to setup etc. In other words, you are testing a work-in-progress work, and your feedbacks/complains/jokes are coming about stuff which are already in a process of being resolved or might even change tomorrow.

Code overhaul is tricky, because there are tasks we just can't parallelize/distribute easily. So please bear with me/us (marcan is working on the arm side), and hopefully, the play/test time will come soon. I'll let you know when I think the procedure for windows are simple enough to be tested (and to get feedbacks from you) and when the code is expected to really work. Until then, if it works, it is pure luck (so I don't really need to know it doesn't). After that, we'll prepare a binary release while we're at it. Because seriously, pure end users shouldn't have to compile anything, only dev should IMHO.

Thank you for your patience
Regards

Omikron

Contributor

Registered: 2010-02-12

Posts: 78

Re: New ProxSpace development environment available for download

iZsh,  I apologize if any of my comments came off as patronizing or criticizing, since that certainly wasn't my intention.  Some of the Windows support from other areas of the open source community has been somewhat...lacking...and I unfairly projected that onto you.

Part of my frustration comes from the fact that I came into the PM3 platform as a new user at a time when it was under a massive overhaul, and all of the Wiki info was out of date.  In absence of clear path to take, I started reading the forum and decided I'd try the latest stuff, which clearly is not an appropriate action for me.

At this point I'm just trying to get my PM3 board _working_ in some way.  If you can point me in the direction of the most recent revision that provided verified and stable operation under Windows, I can stick to that and ask for help on that revision only.

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

Hi iZsh, I'm simply trying to keep my own development environment up to date with the latest changes, I just today, with a bit of help from someone managed to compile in Qt libraries, so I can bring up the plot window on the client.

I believe that if I endure a lot of grief setting up a functional development environment and sorting out through the dozens of little things that usually go wrong when assembling a bunch of disparate systems into one intergrated environment, it is worthwhile packaging that up and sharing it with others, so they don't have to pull their hair out duplicating my efforts. Do you not agree that providing a ready made ProxSpace like environment is beneficial to others ?

I could for example now easily integrate Qt into ProxSpace and update it.

I also propose to delete the cockpit directory as that is no longer useful (and is windows specific), its functionality is replicated by the top level Makefile. As such instead of the windows users dropping into a windows command prompt, they will be instead dropped into the MSYS shell. This further brings together the different OS environments into a more unified one.

XEROEFFECT

Contributor

From: Sydney Australia

Registered: 2009-07-20

Posts: 132

Re: New ProxSpace development environment available for download

I bet my left testicle that soon there's going to be a huge demand for J-Tags. This is getting real interesing now.

bushing

Contributor

Registered: 2008-10-14

Posts: 42

Re: New ProxSpace development environment available for download

Hi iZsh, I'm simply trying to keep my own development environment up to date with the latest changes, I just today, with a bit of help from someone managed to compile in Qt libraries, so I can bring up the plot window on the client.

I believe that if I endure a lot of grief setting up a functional development environment and sorting out through the dozens of little things that usually go wrong when assembling a bunch of disparate systems into one intergrated environment, it is worthwhile packaging that up and sharing it with others, so they don't have to pull their hair out duplicating my efforts. Do you not agree that providing a ready made ProxSpace like environment is beneficial to others ?

There's two sides to this.

On one side, yes -- anything you can do to make life easier for other people is great, and means that it's easier for other people to get involved in using (or hacking on) the project.  I probably couldn't have gotten started on it without one of the earlier ProxSpace releases, because I wouldn't have been able to figure out how to build stuff under Windows.

On the other -- it requires the constant effort of you or someone else to maintain it, if we want to keep it up-to-date.  In some ways, this makes a "build script" (like the one in SVN to build an ARM toolchain) better, because it's pretty easily to update to accommodate new versions of the components it uses.

I could for example now easily integrate Qt into ProxSpace and update it.

I also propose to delete the cockpit directory as that is no longer useful (and is windows specific), its functionality is replicated by the top level Makefile. As such instead of the windows users dropping into a windows command prompt, they will be instead dropped into the MSYS shell. This further brings together the different OS environments into a more unified one.

Very much agreed about the cockpit directory.

As far as Qt goes -- I do not have too much of an axe to grind against it, but I would like to make the following observations:
* It's the only use of C++ in the entire project, which seems odd
* The only thing it does is provide the plot window
* I don't know what guided the choice to use Qt for the Linux port of the client (nor who put the work into doing so), but I suspect the choice to use it was similar to the choice made to originally use HID as the USB wire protocol.   It saved time in the short term, but could cause headaches later.

There isn't *that* much code in the plot window -- not so much that it couldn't be rewritten using a different toolkit if we had a compelling reason.   Maybe now would be a good time to start thinking about if we want to preserve this "a window for console output and a window for a plot" interface, or if we'd rather transition to an actual GUI.

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: New ProxSpace development environment available for download

My 2 cents:
GUI are usually more convenient with C++ than C. That's probably why it's used for the GUI. I know I won't touch the GUI code, ever, if we switch to C for it

I have more experience with wxwidgets (but still very limited though, I'm not a GUI master at all ^^ ), but I'm guessing QT is probably more powerful if we ever want to start doing a real GUI with advanced features.

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

Looking at the wxwidgets screenshots page and the plethora of applications using it, I imagine wxwidgets is powerful enough. Whether we want to switch from Qt to wxwidgets is probably worth some consideration or debate.

While tidying up cockpit, I also propose to delete doc/readme.txt as it's no longer applicable, also should doc/changes.txt go as well? I don't see a reason to keep it.

Last edited by d18c7db (2010-02-24 01:59:05)

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: New ProxSpace development environment available for download

with wxwidget, at least I know how to build a static version for both mac and windows, but that can't be a real major argument for it

One reason for QT though, is the availability of a good design tool. With wxwidgets, I always did the design manually (in plain code). I know there are some generators as well for wxwidgets, but they were 3rd party stuff (some of them even commercial), probably not as mature as qt designer. It could be nice to find someone who did real advanced GUIs for both wxwidgets and QT, and have his feedbacks. It's easy to oversee something, and that'd be a pain to have to switch again down the road once we have a fancy GUI.

As a side note, having to install QT did simplify the installation setup on windows because their SDK already comes with mingw, gcc 4.4, pthread and some other stuff.

Last edited by iZsh (2010-02-24 13:08:26)

aawnsd

Member

Registered: 2010-02-11

Posts: 4

Re: New ProxSpace development environment available for download

summary of windows dev situation, with reference to svn 383:
1. 383 does not work on windows:

Your PM3 should now appear under "LibUSB-Win32 Devices", phew... then you can flash it with the flasher (don't as it will kill it).

2. generally you need som hack on usb to get client (flasher, cli, proxmark3) up and running:

To also answer your other question about "Waiting for Proxmark to appear on USB...", ...
...then browse to msys\mingw\bin and let it install the driver.

3. former "prox gui" is not working on current version 383 and ProxSpace-20100222-r376.7z dev space: need QT to be also installed

Did I make some mistakes?

Can anybady upload a windows dev space with everything included to get "prox gui" and current code compiled?

Sorry if I understood something wrong

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: New ProxSpace development environment available for download

Please use the 2009 summer release. The trunk is not ready for primetime.

Ground Loop

Member

Registered: 2010-01-25

Posts: 15

Re: New ProxSpace development environment available for download

Y'all can laugh at me, but where does one get the "Summer Release" that worked?

I've been trying to build the tip SVN trunk on both Linux and Windows, and have come to understand that this is not fully baked.

Are there any instructions on how to get something that is known-good?

In other words, NOT this:

svn co http://proxmark3.googlecode.com/svn/trunk proxmark3-read-only

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: New ProxSpace development environment available for download

Since you know about SVN, why not go to http://code.google.com/p/proxmark3/ and click on the Downloads tab? There are Summer 09 binaries, Winter 10 binaries as well as the latest updated ProxSpace environment that should compile just fine under Windows?

Also where is this expectation coming from, that the latest SVN contains stable code. You are accessing a development environment undergoing constant changes, the code may well not be stable!!!

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: New ProxSpace development environment available for download

Yeah I don't know why in this project everyone expect the top of the trunk to be stable...
Maybe we should remove the compilation parts from the wiki all together (which is way outdated anyway). Any thought about this?

BTW it compiles just fine under the three platform, but you have to read COMPILATION.txt (!) first, but I wouldn't suggest using the top of the trunk if you didn't manage to compile it at first and/or if you're not a developer.

adam@algroup.co.uk

Contributor

From: UK

Registered: 2009-05-01

Posts: 203

Website

Re: New ProxSpace development environment available for download

I don't think we should make it even harder for people to compile. Actually it would be good if all docco was consolidated into a single up-to-date file and the wiki brought into line. We should also sort out the tools directory and get rid of scripts that install the wrong stuff....

iZsh

Contributor

Registered: 2010-01-02

Posts: 95

Re: New ProxSpace development environment available for download

The intent was not to make it harder to compile, it was to remove outdated information from the wiki (which is were non developers usually looks, hence all the questions we get from end users about compiling the trunk), and consolidate the COMPILATION.txt fle, which is intended for developers (since they will always have this file once they checkout the code from svn).

Last edited by iZsh (2010-03-08 15:15:14)