RfidResearchGroup / proxmark3

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

Compiling issue for RDV20 target board #85

Closed Xoib closed 5 years ago

Xoib commented 5 years ago

Hello,

Following instruction :

    In order for  PM3 RDV20,  PM3 RDV30 etc to be flashed with RRG Repo ,  you must edit  these two Makefiles.  You need to remove 

    1. client/Makefile    (comment out one line   WITH_FPC etc )
    2. armsrc/Makefile   (comment out three line and move out.  WITH_FPC, WITH_SMARTCARD,  WITH_FLASH)

    recompile and your older device will work nicely

It fail on cmdflashmem.c compilation error, I guess cmdsources should also contain ifdef instruction to include or not fpc, smartcard and flash sources.

Side question: I flashed RDV40 HEAD on a RDV20 (without the mod above), the board doesn't appear anymore after the flash (bootroom and fullimage) in /dev. Is it normal? (I reverted to HEAD of main line in the meantime don't worry).

Thanks,

iceman1001 commented 5 years ago

Aha, thanks! I haven't tried compiling without those for awhile. I pushed some fixes which should allow for a error free compilation again.

What do you mean with cmdsources ?

Regarding not showing up, its too little information to go with. Which OS are you using? Did you take notice of the changed device port? Did you need to update blacklist files? ie make udev look into the flashing texts here in this repo and make sure you followed the instructions. Usually there were it fails.

Xoib commented 5 years ago

I meant https://github.com/RfidResearchGroup/proxmark3/blob/master/client/Makefile#L204 by mentioning CMDSRCS.

Regarding the board not showing up in /dev, rest assured I tried on Mac, Linux and even Windows. LED was staying red. My udev rules are up to date. Plus my board works fine with main and your fork.

iceman1001 commented 5 years ago

Strange, I just tried flashing it to a rdv2 this morning after I read this issue. The compilation failed, but that is fixed. The flashing of bootrom/fullimage went well and running of the client without problems. So there is still to little go with here. I still think you are failing the flashing somehow.

TomHarkness commented 5 years ago

Try holding the button down while plugging in, flashing and until the flashing process completes if nothing is showing up under /dev/cu.*

Xoib commented 5 years ago

@TomHarkness yep that's what I did to revert the board to a working state earlier. @iceman1001 your fixes work I confirm.

I didn't closed the issue yet because the great @cjbrigato standalone mod has been updated to use the flash, I get the improvement made here. Still, that's kinda sad because it used to work well without rdv40 flash.

obj/hf_colin.o: In function `ReadLastTagFromFlash':
hf_colin.c:(.text.ReadLastTagFromFlash+0x60): undefined reference to `FlashInit'
hf_colin.c:(.text.ReadLastTagFromFlash+0x74): undefined reference to `Flash_CheckBusy'
hf_colin.c:(.text.ReadLastTagFromFlash+0xdc): undefined reference to `FlashStop'
hf_colin.c:(.text.ReadLastTagFromFlash+0x108): undefined reference to `Flash_ReadDataCont'
hf_colin.c:(.text.ReadLastTagFromFlash+0x144): undefined reference to `FlashStop'
obj/hf_colin.o: In function `WriteTagToFlash':
hf_colin.c:(.text.WriteTagToFlash+0x80): undefined reference to `FlashInit'
hf_colin.c:(.text.WriteTagToFlash+0x90): undefined reference to `Flash_CheckBusy'
hf_colin.c:(.text.WriteTagToFlash+0x94): undefined reference to `Flash_WriteEnable'
hf_colin.c:(.text.WriteTagToFlash+0xa4): undefined reference to `Flash_Erase4k'
hf_colin.c:(.text.WriteTagToFlash+0x124): undefined reference to `FlashStop'
hf_colin.c:(.text.WriteTagToFlash+0x138): undefined reference to `Flash_CheckBusy'
hf_colin.c:(.text.WriteTagToFlash+0x13c): undefined reference to `Flash_WriteEnable'
hf_colin.c:(.text.WriteTagToFlash+0x170): undefined reference to `Flash_WriteDataCont'
collect2: error: ld returned 1 exit status
make[1]: *** [obj/fullimage.stage1.elf] Error 1
make: *** [armsrc/all] Error 2

I know it's the RDV40 repository, but I read here and there that backward compatibility would stay a priority for the community. What's your thought?

Edit: Apparently it doesn't launch anymore neither on iceman fork:

 #db# Installed StandAlone Mods          
#db#    HF Mifare ultra fast sniff/sim/clone - aka VIGIKPWN (Colin Brigato)          
pm3 --> 
pm3 --> 
pm3 --> 
#db# Stand-alone mode! No PC necessary.          
pm3 --> 
pm3 --> 
#db# [+] playing          
#db# [+] 0 408a02 0020fd60          
#db# [!] tags can only have 44 bits. - USE lf simfsk for larger tags          
#db# [!] simulation finished          
#db# [+] done playing          
pm3 --> 

Usually when starting the standalone mod, there was the header launching (like you demoed in black alps) of Colin mod etc.

libin-ka commented 5 years ago

20190125172202

iceman1001 commented 5 years ago

@Xoib As you said, this is the dedicated repo for RDV4, backward compability is not its focus. Get a new device ;) Otherwise the old code for @cjbrigato 's standalone mode is still access able in the history. You just need to take that copy, replace the current file, and you would just do fine. Feel free to contribute.

@libin-ka hm, undefined reference. Have you gotten the latest source? I can compile just fine with smartcard functionality and without it. I pushed a minor fix for when executing emv roca but that shouldn't have stoped the compilation.

Xoib commented 5 years ago

@iceman1001 that's what I did. Unfortunately I get the following:

 #db# Installed StandAlone Mods          
#db#    HF Mifare ultra fast sniff/sim/clone - aka VIGIKPWN (Colin Brigato)          
pm3 --> 
pm3 --> 
pm3 --> 
#db# Stand-alone mode! No PC necessary.          
pm3 --> 
pm3 --> 
#db# [+] playing          
#db# [+] 0 408a02 0020fd60          
#db# [!] tags can only have 44 bits. - USE lf simfsk for larger tags          
#db# [!] simulation finished          
#db# [+] done playing          
pm3 --> 

Instead of what's inside the RunMod() of the mod itself (cf. the video of the mod). For you it's working fine? Do you do something else than pushing the button to start it?

iceman1001 commented 5 years ago

The output looks confused. It starts with Vigikpwn, then it loops into samyrun... So you did something wrong. Remember that you can't have more than one standalone mode in the Makefile. I would only take the code from this repo's history, not mix from iceman fork.

Xoib commented 5 years ago

The first output is a part of hw status command that confirm the Colin mod is installed as standalone mod. Then I push the button and we see what appears to be log from samyrun mod. I double checked my makefile, only Colin mod is set, not samyrun.

On Fri, Jan 25, 2019, 14:01 Iceman <notifications@github.com wrote:

The output looks confused. It starts with Vigikpwn, then it loops into samyrun... So you did something wrong. Remember that you can't have more than one standalone mode in the Makefile. I would only take the code from this repo's history, not mix from iceman fork.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RfidResearchGroup/proxmark3/issues/85#issuecomment-457565800, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfO2QoS40Fj3m8noGmMyGixrRcV4zE5ks5vGwAlgaJpZM4aONM1 .

iceman1001 commented 5 years ago

make clean?

Xoib commented 5 years ago

The problem came from my local changes. Closing this issue, thanks!