Waiting for Proxmark3 RDV4 to appear

ah so it was extracted directly to your Downloads folder, which is really a path like C:\users\youraccount\Downloads … not a good spot for this.

Start over.

Create a folder off C:\ called ProxSpace and extract the .7z file contents there, then run runme64 from in there.

To run it, instead of clicking on it, try opening a CMD window first… this is a command shell for Windows and it’s from this shell you launch ProxSpace to enter the proxspace linux pseudo-shell environment, and inside that pseudo-shell environment you run the proxspace client.

To get into the CMD shell, press the Windows key or click the Windows menu icon and type cmd and press enter. When you type cmd you should see something like this, with Command Prompt listed as the top app;

Once in there, you will need to “cd” or Change Directory to c:\ProxSpace… to do that type cd \proxspace and press enter. My proxspace folder is under a “working” folder, so you can see my process here;

Once you are in the proxspace folder, type runme64.bat and press enter. This should get you into the proxspace environment… eventually… after it’s done doing its first initial build…

Once in the proxspace environment, you will need to pull down the github repo, then compile the code pulled down using the make all command. After make finishes compiling the code, you can use pm3-flash-all to update your RDV4 to the version of firmware that you pulled from git and compiled. The client is also compiled, so after the firmware is updated on the RDV4 hardware you can run the matching client by just using the pm3 command.

Once the PM3 command is run successfully, you will now be operating in the PM3 client environment… so yes, you are wrapped in several layers here CMD>PROXSPACE>PM3.

This is a very quick overview of steps… if you want to follow the whole thing through, follow these steps;

However, because you are using the RDV4 then your Makefile changes will be different as the guide linked above is for the Proxmark3 Easy we sell. Still, all the other parts of the process are the same for the RDV4.

3 Likes

Those first two bunches of errors are just part of proxspace’s runme64.bat doing its thing, mine did that too but still resulted in a functional install

And those last two errors seem to be the same problem as before, which just means that it’s probably a real error and not due to the pre-compiled binaries you were using before

At this point you should have a usable install, I’d try the button trick again through proxspace:
Open runme64.bat
cd proxmark3
do the button trick
./pm3-flash-all

The script will warn you if you try to use a file path with spaces, I’ll have to do some testing on longer file paths, see if I can figure out when it might cause issues

1 Like

runme64.bat is a file, not a command

It’ll be in the unzipped folder, click it to run it

1 Like

Makefile.Platform only needs to be adjusted for non-RDV4 devices, and the generic version of my scripts automatically adjust it for you

I’m not certain what’s going on in that last screenshot…

1 Like

In the last screenshot he’s trying to run the client directly. He’s only missing a -p specify the port. Try starting with;

./proxmark3.exe -p COM3

1 Like

Running an exe from within proxspace?

I didn’t know the PM3 client folder even contained an exe…

1 Like

This problem does not apply to the rdv4 because the rdv4 never had an old bootloader because the rdv4 is not old :slight_smile:

1 Like

Yeah the pm3 command you run is just a script that does a bunch of stuff. Open it in notepad and see what I mean. The exe file is not compiled for Windows it is compiled for the proxspace environment… it won’t run in Windows. It just happens to have an exe extension but you can name it proxmark.MickeyMouse and it would still run in linux. The extension is meaningless to Linux, only the X (executable) file attribute flag means the difference between data and runnable code.

2 Likes

Very interesting

I guess I need to play around with the Windows version some more, I thought the whole thing with proxspace was getting a Linux environment to do the build in, so I guess I figured it would still use Linux-type executables

1 Like

Shoot me a DM and we can try to schedule something if you’d like

1 Like

It is a linux-type executable. As I said you can’t just double click on the proxmark3.exe file in windows explorer. It won’t run because it’s not a windows executable. I think you’re just getting derailed by the .exe file extension.

1 Like

I definitely am…

Why have that extension at all then in the proxspace version? It’s not been on my Linux installs…

I’d love to see what file proxmark3.exe says, I’ll have to check later…

1 Like

Just tap on @Aoxhwjfoavdlhsvfpzha avatar

then tap message

1 Like

shrug

Maybe because it detects proxspace and it knows the user is a Windows user and .exe is what they are used to?

1 Like

… and yet, when I double click on it from Windows Explorer…

So maybe it could be executable directly if file necessary paths were set up for required DLLs? Dunno… maybe ProxSpace is only required to easily git pull and compile it? There are no DLLs in the file paths or subdirectory structures of the proxmark3 folder, at least not from the Windows Explorer side of things.

:man_shrugging:

1 Like

oh nm I found the DLLs… they are in \msys2\mingw64\bin … i’m going to try copying all that shit into one giant folder to see if the proxmark3.exe client will run directly from Windows Explorer.

holy shit… well it kinda runs… for a second… then the window disappears. notice it’s also in offline mode and didn’t seem to attempt to find my connected proxmark at all…

My guess is that there is a lot of TTY and python related interactions that are still rooted in the linux environment and proxspace is set up with all that stuff that would have to be separately installed / configured on a host native windows environment to function.

1 Like

Well, we tried everything I could think to throw at it, and even tried a second RDV4 and a different cable with no luck…

Those pictures he posted are the errors we finally ended up with…

The ./pm3* scripts couldn’t find the PM3 ever, and client/proxmark3 wanted me to go use those to flash just the bootrom first… A vicious cycle…

Any ideas?

Borked batch of PM3s? Seems weird to me…

Do you think any of this is anyone’s fault here?

After reviewing a couple other similar cases;

It seems to me trying a different computer is the next step. There might be some configuration on this computer that is causing problems.

1 Like

I mean have we done the normal USB cable and port swap?

1 Like