search

iceman1001 / proxmark3

[Deprecated] Iceman Fork, the most totally wicked fork around if you are into proxmark3
http://www.icedev.se/pm3.aspx
GNU General Public License v2.0
465 stars 116 forks source link

hf mf mifare starts with an error #150

Closed pmorange closed 6 years ago

pmorange commented 6 years ago

... And then seems to do nothing : pm3 --> hf mf nested 1 0 B FFFFFFFFFFFF d Testing known keys. Sector count=16
#db# unknown command:: 0x0625
.............................................................

The dots go on and on but nothing more ever happens... I am on Ubutu, have cloned, pulled and compiled the latest in the repository so I think I'm up to date.

My proxmark HW is at : [ ARM ] bootrom: iceman/master/ice_v3.1.0-299-g741bb1f 2017-12-15 10:31:29 os: iceman/master/v1.1.0-2247-g45d46ab 2017-09-08 09:45:13 [ FPGA ] LF image built for 2s30vq100 on 2015/03/06 at 07:38:04 HF image built for 2s30vq100 on 2017/05/17 at 17:48:26

[ Hardware ]
--= uC: AT91SAM7S256 Rev B
--= Embedded Processor: ARM7TDMI
--= Nonvolatile Program Memory Size: 256K bytes, Used: 217718 bytes (83%) Free: 44426 bytes (17%)
--= Second Nonvolatile Program Memory Size: None
--= Internal SRAM Size: 64K bytes
--= Architecture Identifier: AT91SAM7Sxx Series
--= Nonvolatile Program Memory Type: Embedded Flash Memory

Is it a new bug in latest version ?

Thanks

iceman1001 commented 6 years ago

This indicates that your fullimage is not the same as the client...

bootrom: iceman/master/ice_v3.1.0-299-g741bb1f 2017-12-15 10:31:29
os: iceman/master/v1.1.0-2247-g45d46ab 2017-09-08 09:45:13
pmorange commented 6 years ago

True.

I have a hard time doing the updates as my Ubuntu is in VirtualBox and I have to play with buttons, connections and disconnections in order to be able to update evertyhing.

Waiting for Proxmark to reappear on /dev/ttyACM0....... If I disconnect the proxmark from the USB connections in VirtualBox and reconnect, or press the proxmark button, sometimes the flasher correctly goes on with the flashing process. I succeeded in flashing the bootloader but I am struggling with the fullimage.

Now when flashing the fullimage it also tells me the following although you see I have the latest bootrom, no?? 

Note: Your bootloader does not understand the new START_FLASH command
      It is recommended that you update your bootloader

Doing as I said I get to this point :

Flashing...
Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x0013945f [0x37460 / 443 blocks]

But the process gets stuck there.

joanbono commented 6 years ago

Maybe yo have to reflash the new bootloader with the old_flasher.

Download this old proxmark3 version, compile using make all.

Then connect the pm3 to the computer and ⚠️ WITHOUT RELEASING THE BUTTON ⚠️ , find the port: 

ls /dev/ttyACM*

Suposing that the port is /dev/ttyACM0:

./proxmark3-2.3.0/client/flasher /dev/ttyACM0 -b icemark3/bootrom/obj/bootrom.elf

Then you can use new flasher to flash the new image:

./icemark/client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf

This sould work 😄

iceman1001 commented 6 years ago

Why running in a virtual box? its quite easy to set up gator96100 dev env on windows.

[edit] NO, he already has a new bootrom. No need to do that. Just stop that.

pmorange commented 6 years ago

I was using Docker previously, but each time I let some weeks pass by and try again I get into many problems. So as I already had a VM lying around I thought I'd get your git repository setup inside to simplify things. But if I can get everything working directly in Windows, even better :-)

So I downloaded the gator96100 proxspace, and from this thread http://www.proxmark.org/forum/viewtopic.php?id=3975 the latest iceman. Compiled stuff and tried flashing again my COM port is 7:

F:\download\ProxSpace-master\pm3\win32>flasher.exe com7 -b ..\firmware_win\fullimage.elf
Loading ELF file '..\firmware_win\fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00035700->0x00035700) [R X] @0x94
1: V 0x00200000 P 0x00137700 (0x00001a10->0x00001a10) [RW ] @0x35794
Note: Extending previous segment from 0x35700 to 0x37110 bytes

Waiting for Proxmark to appear on com7. Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on com7.................................................... Found.
Note: Your bootloader does not understand the new START_FLASH command
      It is recommended that you update your bootloader

Flashing...
Writing segments for file: ..\firmware_win\fullimage.elf
 0x00102000..0x0013910f [0x37110 / 441 blocks]

As I said when it begins waiting for proxmark to reappear I have to press button or disconnect and reconnect before the script is satisfied. Again I get the "does not understand START_FLASH" message.

I then tried to flash bootloader again and get :

flasher.exe com7 ../firmware_win/bootrom/bootrom.elf
Loading ELF file '../firmware_win/bootrom/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000d44->0x00000d44) [RWX] @0x298
Attempted to write bootloader but bootloader writes are not enabled
Error while loading ../firmware_win/bootrom/bootrom.elf
iceman1001 commented 6 years ago

This is the problem. Normally when I get this, I interupt program, I unplug device and reconnect it.
and try running the command once more. Usually does it for me.

Note: Your bootloader does not understand the new START_FLASH command
      It is recommended that you update your bootloader

However you have gotten this several times.

iceman1001 commented 6 years ago

What firmware did you have on your device before ?!?! it looks like it was locked down.

Attempted to write bootloader but bootloader writes are not enabled

pmorange commented 6 years ago

I think I had an earlier one from you repository as I have not been the official way for a long time, but I could not say when. Maybe Docker 1.6 I'd say...

iceman1001 commented 6 years ago

lets try @joanbono 's suggestion for flashing bootrom... doubt it work since the messages say its locked..

Do you have jtag?

pmorange commented 6 years ago

No Jtag I fear.

iceman1001 commented 6 years ago

this error message comes from elf segments out-of-bounds... directly from defines HAS_512_FLASH...

make clean && make all...

iceman1001 commented 6 years ago

are you running a pre-compiled bin-distro inside gator96100 ?!?

iceman1001 commented 6 years ago

since you are flashing /firmware_win/bootrom/bootrom.elf because when you compile you flash bootrom/obj/bootrom.elf

pmorange commented 6 years ago

indeed. In Ubutu I did the compiling, but in gator96100 I placed in /pm3 the downloaded binaries from https://drive.google.com/drive/folders/0B03wIb-JZ6VQOUJQQVI5NUN2bWc I'll get the source code from your repository and try again compiling from scratch.

iceman1001 commented 6 years ago

Its better to get the source code and compile on your machine, never mix firmware/client with eachother. firmware hell is a existing place

That means also getting the updated flasher when compiling...

iceman1001 commented 6 years ago

which means @joanbono 's suggestion with using older flasher makes sense now...

pmorange commented 6 years ago

Well I never understand how I manage to flash in the end. Now after compiling I launched the bootloader flash, got stuck, unplugged, killed the program, tried again... In one of the many struggles I saw the COM port change. So I killed the process, and launched it again with the new COM port... and :

Loading ELF file '../bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000d44->0x00000d44) [RWX] @0x298

Waiting for Proxmark to appear on com8. Found.

Flashing...
Writing segments for file: ../bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 1 blocks]. OK
 0x00100200..0x00100f43 [0xd44 / 7 blocks]....... OK

Resetting hardware...
All done.

Have a nice day!

And.... Now I understand why it did not work before. When I flash (either bootloader or fullimage) the process does some things and then expects the proxmark to come back on the same COM port, but in my case it comes back on another port, so the process can never find it. If I follow these steps it works :

Here is the result :

pm3 ~/client$ flasher.exe com7 ../armsrc/obj/fullimage.elf
Loading ELF file '../armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00035700->0x00035700) [R X] @0x94
1: V 0x00200000 P 0x00137700 (0x00001a10->0x00001a10) [RW ] @0x35794
Note: Extending previous segment from 0x35700 to 0x37110 bytes

Waiting for Proxmark to appear on com7. Found.
Entering bootloader...
(Press and release the button only to abort)
pm3 ~/client$ flasher.exe com8 ../armsrc/obj/fullimage.elf  ~/client$
Loading ELF file '../armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00035700->0x00035700) [R X] @0x94
1: V 0x00200000 P 0x00137700 (0x00001a10->0x00001a10) [RW ] @0x35794
Note: Extending previous segment from 0x35700 to 0x37110 bytes

Waiting for Proxmark to appear on com8. Found.

Flashing...
Writing segments for file: ../armsrc/obj/fullimage.elf
 0x00102000..0x0013910f [0x37110 / 441 blocks]......................................................................................................................................................................................................................................................................................................................................................................................................................................................... OK

Resetting hardware...
All done.

Have a nice day!

kill the COM7 process

pmorange commented 6 years ago

And now :

 [ ARM ]
 bootrom: iceman// 2017-12-15 14:30:28
      os: iceman// 2017-12-15 14:30:50
 [ FPGA ]
 LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
 HF image built for 2s30vq100 on 2017/11/10 at 19:24:16

Mini problem (but keep reading afterwards because there's hope in the end): Still, the "hf mf mifare" does not end (I waited 5 minutes when it should end in some 30 seconds) on a card that works and for which I correctly dumped keys and wrote blocks in the past... When I do an "hf tune" I see the voltage change when I put the card on the antenna. If I do an "hf search", it correctly guesses the Mifare Classic type of card.

Finally, I could now do a "hf mf nested", no more error as I explained in my first post !!! NICE !!! Working again, and this time directly in Windows, and now with an easy solution for flashing new images! So the morning was not lost at all and I'm better now that when I started :-D

Thanks a lot for your precious helps.

iceman1001 commented 6 years ago

funny thing learning, btw yr title states 'hf mf mifare' problems while yr first post states 'hf mf nested' problems.

The darkside attack has a tendensy to not sync so good. I usually add "hf mf dbg 4" which seems to help out. How is the 'nested' command going? it should be quite fast ;)

pmorange commented 6 years ago

The nested works like a charm (but dit not before reflashing everything correctly). I remember using this one in the past, but I saw mifare command which did not even require parameters so I tried using it instead. Anyway what I wanted was a full dump so any working command is fine to me.

iceman1001 commented 6 years ago

Found a bug in hf mf darkside (renamed) and the succesrate and execution time is back to normal :)