Ask/Manchester Demod new functions

marshmellow · 2015-01-02 19:04:28

should be possible. yes just need to program blocks 1 and 2 and set the config block to manchester RF/32 and transmit only 2 blocks. (check the datasheet.)

marshmellow · 2015-01-03 02:31:37

marshmellow wrote:

as a group if we are worried about the number of commands in the "data" group we could consider moving or removing some of the following:
Possible to remove:
bitsamples  (another data samples just without the argument for how many samples to get - it gets 12288 samples)
bitstream  (looks like another ask/manchester demod attempt)
fskdemod
askdemod
mandemod
threshold (we now have dirthreshold)
Possible to Move (maybe to data adv ?):
dec (decimate samples)
amp (amplify peaks)
hpf (zeros graph mean)
hexsamples
norm (min/max to +/-500) (note: will break new demod functions - should change to +/-128)
zerocrossings
thoughts?

This item had been buried, any comments?

joe · 2015-01-03 03:08:47

marshmellow wrote:

should be possible. yes just need to program blocks 1 and 2 and set the config block to manchester RF/32 and transmit only 2 blocks. (check the datasheet.)

Thanks, I will try that,
lf t55xx writeblock fcf200000 1
lf t55xx writeblock 000066c0 2
What about block 0 ?

iceman · 2015-01-03 03:11:20

I'm looking in the code, trying to make sense of what the original thought was. There are some "hardcoded" values like 12288 which doesn't make sense.

marshmellow · 2015-01-03 03:14:07

Agreed, however 12000 should be enough samples to demod most tags... It is possible that value used to be the max buffer size at one time?

iceman · 2015-01-03 03:15:29

This thread is about Marshmellows new LF demods enhancements.

We can lift the "clean up the data commands structure" to another thread.

And Joe, I suggest you start another thread for your questions.

marshmellow · 2015-01-03 03:18:57

Agreed. I'll start one for the data restructuring

http://www.proxmark.org/forum/viewtopic … 470#p13470

Last edited by marshmellow (2015-01-03 03:23:08)

iceman · 2015-01-03 03:21:09

FC 128 gives one bit (of data) every 128th sample. So 1byte = 1024 samples, 64bytes is way over BigBuffer capacity,
FC64, ... 1byte = 512 samples, 64bytes is 32768samples, just inside the BigBuffer capacity,

Or did I missunderstand it all?

marshmellow · 2015-01-03 03:25:02

Except most lf tags are 64 bits or 128 bits with a few at 192 bits. Not bytes.

iceman · 2015-01-03 03:30:49

Then it is enough with 6000-8000 samples

marshmellow · 2015-01-03 03:35:55

Correct, so it is possible the max used to be around 12000

iceman · 2015-01-04 23:11:09

I couldn't help but to notice that inside CmdIndalaDemod, at the end it changes the Graphbuffer. This will change the outcome for the new "LF SEARCH" command for the commands coming afterwards inside.

Some of the old commands has this kind of logic to them, where they tries to demod/decode/ if succesful then also change the raw data used.

marshmellow · 2015-01-05 12:38:51

This effect is desired for cloning and simulating right after reading. I am working on a new psk demod that has fewer errors and false reads. It is almost done.

We could make an argument to "save in buffer" or not for all the demods. Thoughts?

iceman · 2015-01-05 13:58:23

As I mentioned before where I suggested that we divide the demod/decode/, we could add optional step "prepare for sim" where it modifies the graphbuffer with new encoded data.

The original thought of LF commands, where you first do a "LF READ" (read and load data into arm), "DATA SAMPLES" (transfer data to client) "DATA PLOT" (visualise data) and then the testing of the data begins.
Then comes the notion of DATA ACQUISITION, from antenna or loaded from file..

This makes the LF Commands more of a testing tool.

Nowdays, there is a mixture of having fixed demods for certain tags and minimal info of the tag. (taginfo as manufacturing data, etc)

I would like to have the test-bench, the taginfo bench, the known tags implentations, the sim bench all nicely working together.

holiman · 2015-01-05 14:32:44

Regarding the fact that the graphbuffer content is ruined by certain commands has been nagging me a long time. I think someone should implement an undo-functionality. Memorywise, the graphbuffer is not an issue, we could keep a lot of buffers if we want to.

It should be implemented as a pretty generic mechanism, whereby an operation 'checkout' a new version of the graphbuffer, placing the old one in the 'undo-stack'. And a mechanism to pop the undo-stack. I may do it sooner or later myself, but there are a few other things I'm busy with atm.

iceman · 2015-01-05 14:43:36

it somewhere raw signal into demoded signal, then the decode signal have to be somewhere to go while it goes into decode and so one to sim..

* raw-array
* Demod-array
* Decode-array
* Sim-array

And a possibility to swap which array that is visualised in the plot window..

marshmellow · 2015-01-05 17:38:26

Why don't we just have a new buffer for writing and simulating, and all demoded data goes to that? I figured the original idea was to keep a minimal memory footprint, which is why there is only one global data array in each section. But for the client unless you want to run it on your phone it probably doesn't matter if we make a new one for data out buffer.

marshmellow · 2015-01-05 17:39:32

Then all the Sim and clone commands can pull from that. Easier than more arguments, or undo.

holiman · 2015-01-06 10:05:01

marshmellow wrote:

Why don't we just have a new buffer for writing and simulating, and all demoded data goes to that? I figured the original idea was to keep a minimal memory footprint, which is why there is only one global data array in each section. But for the client unless you want to run it on your phone it probably doesn't matter if we make a new one for data out buffer.

Yes, but it may be simpler to convert all old operations to just give them a new buffer to do their stuff, than to retrofit them to use one incoming buffer and one outgoing. But either way is fine with me...

marshmellow · 2015-01-06 15:48:54

strange thing is i can't find any routines that use the demoded data for a sim or clone command. it appears a connection it was intended but never made. so, I guess I'll make one after my pskrawdemod is finished. i am just going to use a single demod buffer. I've adjusted my demod functions in my fork to never change the graphbuffer ... i'm now going to work to get my fork back in sync with the main...

iceman · 2015-01-06 16:17:31

If you look into the EM410x commands, you'll see some decode -> sim.
I guess there was some in HID has the individual methods but not "hooked" up in a replay method.

Just to be clear, how about we use the same notion for all of these commands, like this:

REPLAY = scan for a tag, if found start simulating it.
SIMULATE = take a uid and send to PM3 where it begins to act as that uid.
CLONE = take a uid and make a copy to a t55x7 card.

marshmellow · 2015-01-06 18:15:53

CmdLFSim (used by EM410x simulate command) appears to pull from the graphbuffer - it also appears this command uses bitstream to demod if the wave in graphbuffer isn't demodulated yet.

this should be fairly easy to adjust. i don't see many other commands that pull data and write from or sim from the graphbuffer.

marshmellow · 2015-01-06 18:22:09

are any of the sim commands functional? i saw several bug comments lately. no point connecting them until they work.

iceman · 2015-01-06 20:04:43

After spending hours and hours in LF sim commands.. (lf em4x 410xsim) I advice not to touch all SIM functions until after we gotten your, Holimans and mine changes in the pm3-master.
If we do that, we at least don't have to bother figuring out if it was the "demod" that mess it up or not. The original simulatelftag in lfops.c was kind of working... but I've been rewriting it.. Almost there.

marshmellow · 2015-01-06 20:36:23

Sounds good. I'm not sure how to proceed with my psk additions, and a few bug fixes... If I create a pull request it would just create more conflicts with yours...

holiman · 2015-01-06 20:38:54

iceman wrote:

After spending hours and hours in LF sim commands.. (lf em4x 410xsim) I advice not to touch all SIM functions until after we gotten your, Holimans and mine changes in the pm3-master.

I don't have anything much to commit in there.. I also implemented sending larger chunks of data, but that's laying around somewhere and we may just as well use your implementation I guess... So don't let me hold you up

marshmellow · 2015-01-06 20:40:33

What will it take to get iceman's pull request ready for accepting?

iceman · 2015-01-06 20:58:47

I will try one different approach to fix the pull-request aftera tip from Holiman. After that I give up.

joe · 2015-01-07 14:10:23

joe wrote:

marshmellow wrote:
should be possible. yes just need to program blocks 1 and 2 and set the config block to manchester RF/32 and transmit only 2 blocks. (check the datasheet.)
Thanks, I will try that,
lf t55xx writeblock fcf200000 1
lf t55xx writeblock 000066c0 2
What about block 0 ?

Just for your info, the cloned card can't work.

marshmellow · 2015-01-07 17:36:39

@joe, if you start a new thread and can post a trace I may be able to help further. there are a few reasons an ata5577 may not work to clone some tags.

holiman · 2015-01-07 21:14:03

marshmellow wrote:

What will it take to get iceman's pull request ready for accepting?

Today I committed the first of the set of changes. I looked through the changes, made some comments, and iceman made some fixes - then I committed it. Testing is appreciated.

https://github.com/Proxmark/proxmark3/commits/master

So, ready for the next set of changes, @iceman.

iceman · 2015-01-07 21:25:52

Sweet work Holiman!

question, is the pm3 master ready for openssl?? It's one of the major issues everyone has with my fork to start with.

holiman · 2015-01-07 21:27:13

I don't know. Why not? but then again, perhaps the entire openssl isn't needed ?

asper · 2015-01-07 21:39:35

The needed openssl files are the following:

Put them in the /client/openssl/ folder. Here they are.
I obtained them while compiling and adding them 1 by 1 until it compiled fine (anyway I also have openssl installed).

Iceman also uses Qt 5.x while the main trunk 4.x so while compiling with the "old" environment, the QTDIR must be updated/changed.

Last edited by asper (2015-01-07 21:43:32)

iceman · 2015-01-07 21:56:47

I never changed the Qtdir variable, so the old makefile should work but then, never say never.

marshmellow · 2015-01-07 23:52:17

are we going to add these files to git? also I had trouble until I added the libeay32.dll (and added it to the make file). but might just be me...

Last edited by marshmellow (2015-01-07 23:52:45)

marshmellow · 2015-01-07 23:54:15

if we switch to qt 5 will we remake a zipped compile environment for download like was previously able to be downloaded from proxmark.org?

iceman · 2015-01-08 00:01:17

Depends, Asper has been maintaining a Pre-compiled Windows binaries distro. Which enables all of the people who don't know how to set up the development environment.

If Asper is up to making a new working version it would be nice.

Soon I have gotten all my minor changes in the Pm3-master, then I start with the Ultralight/Desfire stuff, which is where the fun begins.

iceman · 2015-01-08 00:02:20

We can also start thinking on moving up to Qt 5.x. The whole dev env is kind of outdated.

marshmellow · 2015-01-08 00:02:38

the precompiled binaries is different.
i meant: http://www.proxmark.org/files/Windows-C … vironment/

marshmellow · 2015-01-08 00:07:19

I'm going to issue a pull request from my fork to get the new PSK functions in (as well as a few bug fixes to my other functions, and a switch to Tab spacing).. it also has a fix to the tune command i broke in merge 33.

asper · 2015-01-08 00:19:50

I can maintain the precompiled win and android version.
The compiling environment I am using is the one you can find in the proxmark repostiory: http://code.google.com/p/proxmark3/downloads/list (maybe someone should copy/move it to github and maybe adding some more recent "stable" compiled version). I only updated Qt to 5.3.2. The guide I used is this one: http://code.google.com/p/proxmark3/downloads/list.

Last edited by asper (2015-01-08 00:20:15)

marshmellow · 2015-01-08 23:36:37

asper wrote:

proxmark repostiory: http://code.google.com/p/proxmark3/downloads/list (maybe someone should copy/move it to github and maybe adding some more recent "stable" compiled version)

+1 vote (once openssl is integrated)

NeiJPass · 2015-01-10 16:30:17

Hello everyone. This he has done has worked mars never read me "lf EM4x50" Now allow me to read these cards? can be recorded on these cards (EM4450)

iceman · 2015-01-10 16:47:43

Don't know if Marshmellows new lf-demods fixes the "lf em4x em4x50" commands. It does makes a correct decoding of "em410x" tags.

marshmellow · 2015-01-10 17:25:52

I don't have any em4450 tags to test those commands, and none of my adjustments affect the lf em4x em4x50 commands. It might be possible to askraw demod it, though I think it has clocking bit separators that may cause problems in the demod.

marshmellow · 2015-02-07 00:44:49

for a summary of the new lf commands see:http://www.proxmark.org/forum/viewtopic.php?id=2260

marshmellow · 2015-04-02 18:42:35

in my fork i have some new code to demod the em4x50 tags.

i finished off the lf em4x em4x50read command (data must be in graphbuffer first).
i also added it to the lf search.

i haven't looked at the readword/writeword commands yet.

asper · 2015-04-02 20:02:21

This is a summary for the EM4150 specs:

PROTECTION WORD (Block1): This block contains 4 bytes, each of which provides a setting for the read/write protection of transponder blocks - if a block is not write-protect it can be written, unless you change block1 settings to make it write-free - if a block is read-protect it can not be read (if you try to read you obtain all 0), unless you change block1 settings and make it read-free; these protections are used to ensure that only those who know the psw can read/write those blocks making them first free and then locking them again. In 4150 it is not possibile to select, block by block, the desired setting, since that function would require many more bits that were "wasted" for the configuration, so you can only seta range of blocks; in practice you must transform the block value in binary (by reading the bits from right to left) - bits from 0 to 7, returned into hex, give the first read-protected block - bits from 8 to 15, returned in to hex, give he last read-protected block - bits from 16 to 23, returned into hex, give the first write-protected block - bits 24 to 31, returned into hex, give the last write-protected block (you
can combine the 2 blocks range to get read-only, write only or both). CONTROL WORD (Block2): its Bit16 (the seventeenth) indicates the presence (1) or not (0) of Password Protection (default pwd: 000000), and the last two bytes indicate the range of write-protected blocks, eg. 00010504 indicates that the password is active for blocks from 04 to 05; when protection is active data can still be read but can only be modified using a valid password login presuming the fact that they write-free; if they are not write-free you must fistly modify the protection word. Bit 17 (the eighteenth), if set to 1, indicates that, once a write operation of a block is made, the block is immediately retransmitted (for confirmation purpose) from the tag to the programmer. Bits 18-31 are not used for configuration but are "user available". It is also possible to ser the word (1 only) that is transmitted from the transponder when it is near the programmer with the command "wordsel"; this allows to set a value between 3 and 31 (or OFF if you want to transmit the ID) that corresponds to the block to be automatically transmitted insted of the UID.

Proxmark3 community

Announcement

#51 2015-01-02 19:04:28

Re: Ask/Manchester Demod new functions

#52 2015-01-03 02:31:37

Re: Ask/Manchester Demod new functions

#53 2015-01-03 03:08:47

Re: Ask/Manchester Demod new functions

#54 2015-01-03 03:11:20

Re: Ask/Manchester Demod new functions

#55 2015-01-03 03:14:07

Re: Ask/Manchester Demod new functions

#56 2015-01-03 03:15:29

Re: Ask/Manchester Demod new functions

#57 2015-01-03 03:18:57

Re: Ask/Manchester Demod new functions

#58 2015-01-03 03:21:09

Re: Ask/Manchester Demod new functions

#59 2015-01-03 03:25:02

Re: Ask/Manchester Demod new functions

#60 2015-01-03 03:30:49

Re: Ask/Manchester Demod new functions

#61 2015-01-03 03:35:55

Re: Ask/Manchester Demod new functions

#62 2015-01-04 23:11:09

Re: Ask/Manchester Demod new functions

#63 2015-01-05 12:38:51

Re: Ask/Manchester Demod new functions

#64 2015-01-05 13:58:23

Re: Ask/Manchester Demod new functions

#65 2015-01-05 14:32:44

Re: Ask/Manchester Demod new functions

#66 2015-01-05 14:43:36

Re: Ask/Manchester Demod new functions

#67 2015-01-05 17:38:26

Re: Ask/Manchester Demod new functions

#68 2015-01-05 17:39:32

Re: Ask/Manchester Demod new functions

#69 2015-01-06 10:05:01

Re: Ask/Manchester Demod new functions

#70 2015-01-06 15:48:54

Re: Ask/Manchester Demod new functions

#71 2015-01-06 16:17:31

Re: Ask/Manchester Demod new functions

#72 2015-01-06 18:15:53

Re: Ask/Manchester Demod new functions

#73 2015-01-06 18:22:09

Re: Ask/Manchester Demod new functions

#74 2015-01-06 20:04:43

Re: Ask/Manchester Demod new functions

#75 2015-01-06 20:36:23

Re: Ask/Manchester Demod new functions

#76 2015-01-06 20:38:54

Re: Ask/Manchester Demod new functions

#77 2015-01-06 20:40:33

Re: Ask/Manchester Demod new functions

#78 2015-01-06 20:58:47

Re: Ask/Manchester Demod new functions

#79 2015-01-07 14:10:23

Re: Ask/Manchester Demod new functions

#80 2015-01-07 17:36:39

Re: Ask/Manchester Demod new functions

#81 2015-01-07 21:14:03

Re: Ask/Manchester Demod new functions

#82 2015-01-07 21:25:52

Re: Ask/Manchester Demod new functions

#83 2015-01-07 21:27:13

Re: Ask/Manchester Demod new functions

#84 2015-01-07 21:39:35

Re: Ask/Manchester Demod new functions

#85 2015-01-07 21:56:47

Re: Ask/Manchester Demod new functions

#86 2015-01-07 23:52:17

Re: Ask/Manchester Demod new functions

#87 2015-01-07 23:54:15

Re: Ask/Manchester Demod new functions

#88 2015-01-08 00:01:17

Re: Ask/Manchester Demod new functions

#89 2015-01-08 00:02:20

Re: Ask/Manchester Demod new functions