Ask/Manchester Demod new functions

marshmellow · 2014-12-22 23:58:24

i have completed an additional function "data askmandemod for ask demoding that can handle a LOT of tags that current functions can't.
it takes 2 arguments: [clock] and [invert] both can be omitted to accept the default values of 64 and 0 (or no invert).
to identify the clock sometimes you can use the data detectaskclock function, other times you will have to eye it with data plot - data grid xx (xx=possible clock values) and line up the grid.

right now it just outputs the binary (and saves it in the GraphBuffer for further use) but i plan on extending it to allow a supplemental command to detect EM410x formats and output the ID. (or other formats if identified)

this will work to read the binary of phidgets, EM4050, g-prox-II, casi, and many many em410x formats. (also homeagain.pm3 in the traces directory, (FDX-B) )

currently this code is in my fork - marshmellow42 on github. once my fsk pull is accepted i will create a pull request for this as well. (maybe i'll finish my em410x format command by then)

just wanted to throw this out there.

NOTE: this command requires the data to already be in the GraphBuffer - so either a data load or a lf read and data samples xxxxx needs to be done first
this is done so that we can maintain offline mode and the save/load traces functionality.

Edit: see this post to see new cmds.

Edit2: see this post to see summary of all the new lf commands

Last edited by marshmellow (2015-08-18 17:38:34)

marshmellow · 2014-12-23 17:57:52

added the EM410x format check to askmandemod in my fork. it will automatically search for a valid EM410x format in the binary after demodulating the ask waves. if it finds the start sequence and if the parities work for the EM410x format it will output the EM ID, the Unique ID, and a few others after the raw binary output of askmandemod.

it works well. i've always experienced trouble with this type of demod on the proxmark (and others too if you look at the forum posts) and often had to do it by eye, this fixes that.

enjoy.

(ps. it is not yet in the master)

Last edited by marshmellow (2015-01-01 18:45:55)

iceman · 2014-12-23 19:10:20

so what the difference between existing data askdemod and your new one?

marshmellow · 2014-12-23 19:47:13

the existing askdemod strictly identifies high bar and low bar transitions, it inserts a 0 for every sample collected from the high bar found until a low bar is found, then it switches to inserting 1s for every sample collected until a high bar is found. it relies on all high bars and low bars to be exactly the same values (or clipped). it also does not account for the clock so it cannot truly demod the wave to valid binary (manchester demod then does that in the current implementation).

so if you have ask modulated manchester encoded data of 010110 you might have the data askdemod of 000000001111111111111111000000000000000011111111111111110000000011111111000000001111111100000000
(really for rf/64 this would be 64 1s and 0s to make one binary digit)
then manchester demod attempts to make sense of this, which works (some of the time).
manchester demod doesn't always work because while it does attempt to use a clock to figure out the binary the waves are no longer there (they are muddied by askdemod) so it cannot always line up the clock to the binary correctly

instead of all that work, we can get the demod by knowing the clock and aligning the data to the clock. then we can ignore the extra waves in manchester encoding (by ignoring anything between the clock cycles) while capturing the important binary. the extra benefit is it doesn't have to be manchester encoding to work, it just has to always have a high wave or low wave that lines up in the area of the clock. (basically this is the procedure often used to demod by eye by applying a grid to the plot and lining it up)

i also built in an auto clipping of the waves at 75% height to ensure the highs and lows are all the same. (similar to what the threshold commands attempt to do.) in case of poor reads or card output variance.

Last edited by marshmellow (2014-12-24 18:54:15)

marshmellow · 2014-12-23 21:10:20

I've confirmed it works well with all the following traces:

EM4102-1.pm3
EM4102-2.pm3
EM4102-3.pm3
Transit999-best.pm3
em4102-clamshell.pm3
em4102-thin.pm3
em4x05.pm3
em4x50.pm3 (note: this has some sort of null bit separators, these will show as errors in the bit stream as 77)
homeagain.pm3
homeagain1600.pm3
modulation-biphase.pm3
modulation-manchester.pm3

as well as others not in traces db
phidgets
g-prox-ii

marshmellow · 2014-12-23 21:13:09

just one warning, a rf/32 clock wave will allow you to demodulate it as 64 without any errors, but the output will be missing 1/2 the bits. setting the clock correctly is the only way to get good output from this command.

iceman · 2014-12-23 23:28:29

Marshmellow, I really really like the new functions. Xmas came early this year!

marshmellow · 2014-12-24 00:05:03

sometime i might look at the detect clock function and see if i can make it more robust, so we can rely on that instead of user input. [DONE]

speaking of emulation I would like to further allow a sim command after the data was demodulated to simulate the tag (maybe given the # of bits to simulate as an argument)

also todo: would be to combine these improvements into the EM410x code in the arm. (that goes for the recent FSK demod improvements as well) [PARTIALLY DONE]

also in my opinion the original fskdemod, mandemod can be removed, but since those have been the heart of the PM3 LF commands I left them alone for now.

but in my spare time...

Last edited by marshmellow (2015-01-01 18:48:32)

marshmellow · 2014-12-24 18:46:40

i am going to name this function askmandemod... (sorry for the confusion). it works very well for the various implementations of manchester encoding with ASK modulation.
it does not decode ask/biphase or ask/direct properly.

i am going to look at those at a later time.

Last edited by marshmellow (2015-01-01 18:49:04)

marshmellow · 2014-12-29 02:22:38

I've added a new shared common file lfdemod.c and lfdemod.h
this contains the functions to demod ask and fsk. it has EM410x specific, HID specific and IO prox specific decoding functions.
lfops.c in armsrc now calls the same demod functions as cmddata.c in the client.

this reduces duplicate code. i did have to adjust the make files to make it work and i readily admit i'm not an expert on this. but it does compile and work.

I also added data askrawdemod that will demod any ask wave (in theory) and wait for de-encoding. you can then currently do a data manrawdecode to decode manchester. (or use the direct data askmandemod if you know it is manchester encoded ask)

I plan to add biphase decode function to be run after data askrawdemod.

once i do a little more testing and put the finishing touches on i will initiate a pull request. but i have updated my fork with what is complete for now.

marshmellow · 2014-12-30 05:56:50

Are we extra concerned over arm memory usage? If yes the I may want to refactor the lfdemod.c a little to not declare any new byte arrays. (They aren't global.). But aren't entirely necessary, just easier.

iceman · 2014-12-30 10:52:11

If you can minimize the arrays, then that is a good thing. There is not alot of memory to play with for starters.

marshmellow · 2014-12-30 15:49:31

i will refactor those to reuse /overwrite the array pointer passed to them. (bigbuf in the case of the arm) on the client side are there any reason to keep a small memory footprint? i would like to use new arrays in the client (cmddata.c) (as my code currently does) so as to not have to overwrite the graphbuffer in instances where it is beneficial.

iceman · 2014-12-30 16:04:35

On the client side I don't see any reasons. In some of my changes I make copies of graphbuff, I'm ok with it.

marshmellow · 2014-12-31 08:31:23

i finished removing the extra byte arrays from the lfdemod.c functions. i also fixed a few bugs while i was at it. I also came across a need to handle more than just fsk2a with my data fskrawdemod function. so i added a few more arguments. it now accepts [clock] [invert] [rchigh] [rclow]. clock is the overall bit clock (usually 50 or 64). invert ... rchigh and rclow for fsk2a = 10 and 8 for RF/10 and RF/8 (a 0bit has 10 samples per wave, a 1bit has 8)

marshmellow · 2014-12-31 08:34:42

I also added a new lf command - lf search this checks if you are online or offline - if online it will do an "lf read" - "data samples 20000" - then it will check the read samples against EM410x, HID Prox, IO Prox, and Indala and output the result. if you are offline it will check whatever is in the graphbuffer (so do a data load first)

iceman · 2014-12-31 11:22:38

yeah, I implemented all your lf changes now. It seems to work on my lf tags. I will try some different settings on a t55xx card and test some more later.
I like the new "lf search", I'm fiddleing with it a bit... Great work!

asper · 2014-12-31 12:08:34

Hi guys, I have been busy for a while (and I have still many things to do);
@marshmellow: are those changes already in the main trunk ? It seems to be not...
@everybody: can someone sum up the recent commands changes/additions in the main trunk ? What is the correct command to send to dump the entire help file ? I am trying to update my GUI settings.txt but I become "rusty" at pm3 each weeks passed without using it... aging process ?

Great work and thanks to everybody involved !!!

Last edited by asper (2014-12-31 12:09:12)

marshmellow · 2014-12-31 16:28:16

These are not yet in the main trunk. And while there are a couple more items I would like to add I think what is complete can be put in the main.. I did not test compile on a Linux platform. It might be nice if someone can confirm it works fine on Linux (don't know why it wouldn't but just to be safe...). I will write up the new commands I've added about the time they get added to the main.

marshmellow · 2014-12-31 19:24:09

once it is committed to the main the settings.xml text will be something like:

NEW Commands:
DATA SECTION:

	<section title="DATA DEMODULATE ASK/MANCHESTER RAW" tooltip="Attempt to demodulate simple ASK modulated Manchester Encoded tags" uniqueId="dataaskmandem" >
		<item type="textbox" defaultValue="" tooltip="Clock Rate" uniqueId="askmanclk" label="Clock Rate (empty = auto-detect):" width="40" />		
		<item type="textbox" defaultValue="" tooltip="Invert" uniqueId="askmaninv" label="Invert output (empty for no - 1 for invert):" width="40" />		
		<item type="button" text="DEMODULATE" tooltip="Press button to try to demodulate simple ASK tags" action0="data askmandemod $askmanclk $askmaninv" />
	</section> 
	<section title="DATA DEMODULATE ASK RAW" tooltip="Attempt to demodulate simple ASK modulated Encoded tags" uniqueId="dataaskrawdem" >
		<item type="textbox" defaultValue="" tooltip="Clock Rate" uniqueId="askrawclk" label="Clock Rate (empty = auto-detect):" width="40" />		
		<item type="textbox" defaultValue="" tooltip="Invert" uniqueId="askrawinv" label="Invert output (empty for no - 1 for invert):" width="40" />		
		<item type="button" text="DEMODULATE" tooltip="Press button to try to demodulate simple ASK tags" action0="data askmandemod $askrawclk $askrawinv" />
	</section> 
	<section title="DATA HID DEMODULATE FSK" tooltip="Demodulate graph window as a HID FSK Tag " uniqueId="datafskhid" >
		<item type="button" text="DEMODULATE" tooltip="Press button to demodulate graph window as a HID FSK Tag " action0="data fskhiddemod" />
	</section> 
	<section title="DATA IO PROX DEMODULATE FSK" tooltip="Demodulate graph window as an IO PROX FSK Tag " uniqueId="datafskio" >
		<item type="button" text="DEMODULATE" tooltip="Press button to demodulate graph window as a IO Prox FSK Tag " action0="data fskiodemod" />
	</section> 
	<section title="DATA RAW DEMODULATE FSK" tooltip="FSK Demodulate graph window to raw binary  " uniqueId="datafskhid" >
		<item type="textbox" defaultValue="50" tooltip="Clock Rate" uniqueId="fskrawclk" label="Clock Rate (Default 50 for RF/50):" width="40" />		
		<item type="textbox" defaultValue="0" tooltip="Invert" uniqueId="fskrawinv" label="Invert output (0 for no - 1 for invert):" width="40" />		
		<item type="textbox" defaultValue="10" tooltip="RC High" uniqueId="fskrawrch" label="RC High (Default 10 for RF/10):" width="40" />		
		<item type="textbox" defaultValue="8" tooltip="RC Low" uniqueId="fskrawrcl" label="RC Low (Default 8 for RF/8):" width="40" />		
		<item type="button" text="DEMODULATE" tooltip="Press button to demodulate graph window as a FSK RAW Tag " action0="data fskrawdemod $fskrawclk $fskrawinv $fskrawrch $fskrawrcl" />
	</section> 
	<section title="DATA MANCHESTER DECODE RAW BIN" tooltip="Manchster Decode graph window binary " uniqueId="datamanraw" >
		<item type="button" text="DECODE" tooltip="Press button to Manchster Decode graph window binary " action0="data manrawdecode" />
	</section>
	<section title="DATA BIPHASE DECODE RAW BIN" tooltip="Biphase Decode graph window binary " uniqueId="datamanraw" >
		<item type="button" text="DECODE" tooltip="Press button to Biphase Decode graph window binary " action0="data biphaserawdecode" />
	</section>

LF SECTION:

	<section title="LF Search" tooltip="Read 125 kHz LF ID-only tag and test known tags to get ID" uniqueId="readlfid">
		<item type="button" text="Search" tooltip="Press button to search for known 125 kHz LF ID-only tags" action0="lf search" />	
	</section>

LF EM SECTION:

	<section title="EM4x">
		<section title="EM410xdemod" tooltip="Continuously Extract ID from EM410x tag" uniqueId="em4xdemod">
		<item type="textbox" defaultValue="" tooltip="Clock Rate" uniqueId="em4xdclock" label="Clock Rate (empty = auto-detect):" width="40" />		
		<item type="button" text="EXTRACT ID" tooltip="Press button to extract ID from EM410x tag" action0="lf em4x em410xdemod $em4xdclock" />		
	</section>

COMMAND UPDATES:

DATA SECTION:

	<section title="DATA DETECT ASK TAG CLOCK" tooltip="Detect ASK clock rate " uniqueId="datadetclock" >
		<item type="button" text="DETECT ASK CLOCK RATE" tooltip="Press button to detect clock rate " action0="data detectaskclock" />
	</section>

LF HID SECTION:

	<section title="HID FSK DEMODULATE" tooltip="Realtime HID FSK demodulator" uniqueId="lfhiddemfsk" >
		<item type="button" text="DEMODULATE" tooltip="Press button to read and FSK demodulate HID Prox Cards" action0="lf hid fskdemod $hidfskdemodfo" />
		<item type="label" label="
HID FSK demodulator, it loops continuously (or until the button is pressed) and if a HID 
tag enters the field it will capture and do the FSK demodulation and manchester decoding 
of the waveform to return the tag ID as a hex number. It seems the TAG ID is a 44 bit number 
and the number printed on the tag is usually bits 16 though 1 (bit 0 is possibly a parity bit)" />
		<item type="textbox" defaultValue="" tooltip="Find One" uniqueId="hidfskdemodfo" label="Find One (empty = continuous, 1 = find one):" width="40" />						
	</section>

LF IO SECTION:

	
	<section title="ioProx FSK DEMODULATOR" tooltip="Continuous Read and FSK demodulate ioProx 64bit UID" uniqueId="iopfskdemod">
		<item type="button" text="DEMODULATE" tooltip="Press button begin reading and FSK demodulating ioProx TAGS" action0="lf io fskdemod $iofskdemodfo" />	
		<item type="textbox" defaultValue="" tooltip="Find One" uniqueId="iofskdemodfo" label="Find One (empty = continuous, 1 = find one):" width="40" />						
		<item type="label" label="
Output example:
(for 1 tag only option)
#00000000 0
#11110000 1
#10111110 1 facility
#00000001 1 version 
#00001011 1 ID1
#11000011 1 ID2
#00001011 11 checksum
(for all reads)
#XSF(01)BE:03011 (00786fa030be1e0b)" />
	</section>

. Edit: em410x command above was incorrect.

Last edited by marshmellow (2015-01-01 06:56:27)

asper · 2014-12-31 19:58:46

Thank you very much guys !

marshmellow · 2014-12-31 20:36:04

one more new DATA cmd:

	<section title="DATA R-TRIM SAMPLES" tooltip="Trim samples back to entered location" uniqueId="datatrim" >
		<item type="textbox" defaultValue="" tooltip="Enter Location to trim back to" uniqueId="datartrimsam" label="Samples:" width="120" />	
		<item type="button" text="R-TRIM" tooltip="Press button to trim samples from right of trace" action0="data rtrim $datartrimsam" />
	</section>

the control widths were not tested and may need adjusting...

marshmellow · 2015-01-01 06:50:57

So the current list of new lf commands is as follows

data askmandemod (clock) (invert)

Will accept up to 2 arguments but they are not required.
This function will ask demodulate while Manchester decoding.
It uses the clock to best align the samples to get the best possible read on the samples in the graph buffer and outputs the binary to the screen and log.
The function then tests the binary for a match to em410x std format, if a match it will output the em IDs and save the bitstream to the graph buffer.

data askrawdemod (clock) (invert)

This function will strictly ask demodulate to binary and save it in the graph buffer. We can then attempt a decoding method to get the final binary. (Decoding functions below)

data manrawdecode

This function strictly takes binary already in the graph buffer and Manchester decodes it. It makes two passes on the data checking which results in less errors and outputs the resulting binary inserting 77 for any error it hits.

data biphaserawdecode (offset)

Again takes binary from the graph buffer and attempts to biphase decode it. The offset is intended to be used to align the encoding as unlike Manchester the binary alone doesn't help us do this. Still a work in process.

lf em em410xdemod (findone)

This command will continuously attempt to read an em410x tag until the button is pressed. An argument of 1 will make it search for one tag only.

lf search

This function when in online mode will send lf read - data samples 20000 - and then attempt to find an hid prox card, an em410x tag, an io prox tag, or an indala tag. And output the found info.
When offline it will use what is in the graph buffer and perform the same tests.

data fskrawdemod (clock)(invert)(rchigh)(rclow)

This command attempts to get demodulated binary from an FSK wave in the graph buffer. This is for unknown tags. The input options allow for multiple FSK implementations.

data fskhiddemod

This command allows for hid tag demodulating and decoding from the graph buffer.

data fskiodemod

This command allows for io prox tag demodulating and decoding from the graph buffer.

data rtrim (location)

This allow you to truncate the graph buffer samples.

Last edited by marshmellow (2015-01-01 07:01:46)

iceman · 2015-01-01 11:48:58

Is it only me or is the first level of commands in "data" getting filled up?
How about we make two subgroups, like

Where the decode doesn't "destroy" the demoded data?

data
 | 
 ---Demod
 |        |
 |        --- Ask
 |        --- Fsk
 |        --- Psk
 |
--- Decode
         |
         --- Em41xx
         --- hid
         --- io

marshmellow · 2015-01-01 14:34:26

As long as all the new functions work for all, we could get rid of the original askdemod, mandemod, and fskdemod. Or move them and other unused commands to another menu say data misc. There are a few even after looking at the code I couldn't figure out how they would be useful today.

marshmellow · 2015-01-01 14:37:15

I'm not opposed to what you suggest, I'd just think I'd keep the most used commands lowest in the menu. Maybe move things like amp, Dec, hex samples... That don't get used often(or ever?)

marshmellow · 2015-01-01 14:48:18

The new commands are now merged with the master.

asper · 2015-01-01 17:42:23

Settings.xml reworked thanks to the great marshmellow contribution and description !

A question: about "data ltrim/rtrim", how many samples are suitable to collect to use it properly ?

Last edited by asper (2015-01-01 17:42:50)

marshmellow · 2015-01-01 17:44:56

it is used to trim unwanted data at the end of a read. like for reading blocks of ata5577s or for using the lf snoop. so if the modulation is changing in the data you can isolate only the samples you want in the plot window and trim down to that so you can then demodulate/decode (and it won't break the demodulation functions)

marshmellow · 2015-01-01 17:47:02

as in the case of lf snoop, you will capture the card output and the reader output, but they may be in different modulations, so you have to trim out the undesired area to isolate and demod the area you're interested in.

asper · 2015-01-01 17:49:41

Ok so I will leave the parameter blank. A new compiled version will follow soon !

marshmellow · 2015-01-01 18:26:05

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?

Edit: added new thread for this discussion here: http://www.proxmark.org/forum/viewtopic.php?id=2227

Last edited by marshmellow (2015-01-03 05:14:40)

marshmellow · 2015-01-01 18:36:28

anyone know the purpose of data norm and why it normalizes to +/-500?

in my fork i've adjusted it to +/-128 so all the demod functions still work.

Edit: created new thread here:http://www.proxmark.org/forum/viewtopic.php?id=2226

Last edited by marshmellow (2015-01-03 02:40:14)

joe · 2015-01-02 10:37:08

Hi, marshmellow,

here is the SEARCH LF from the newer ver 006, is that correct ? please advise thanks.

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: /-suspect 2015-01-01 15:28:15
#db# os: /-suspect 2015-01-01 15:28:20
#db# LF FPGA image built on 2014/ 6/23 at 9:25:13
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3>
proxmark3> hw tune
Reading 255 samples
Done! Divisor 89 is 134khz, 95 is 125khz.
proxmark3>

proxmark3> lf search
#db# buffer samples: dd cf cf c5 c3 b8 ba b2 ...
Reading 20000 samples
Done!
Checking for known tags:
Using Clock: 32 - Invert: 0 - Bits Found: 400
ASK/Manchester decoded bitstream:
1100000011111100
1111001000000000
0000000000000000
0000000001100110
1100000011111100
1111001000000000
0000000000000000
0000000001100110
1100000011111100
1111001000000000
0000000000000000
0000000001100110
1100000011111100
1111001000000000
0000000000000000
0000000001100110
1100000011111100
1111001000000000
0000000000000000
0000000001100110
1100000011111100
1111001000000000
0000000000000000
0000000001100110
1100000011111100
Recovered 533 raw bits, expected: 625
worst metric (0=best..7=worst): 8 at pos 290
UID=0000000000000000000000000000010010100000000100000100100000000000 (4a0104800)
Occurrences: 1 (expected 7)
proxmark3>

iceman · 2015-01-02 10:45:44

The output looks like the command found a indala tag

marshmellow · 2015-01-02 10:53:30

It found a possible ask/Manchester bitstream that it did not know and it found some bits that almost looked like an indala card. However since the indala demod found bits only once out of 7 tries it likely is not correct. I think what you have is an "unknown" ask/Manchester tag. In the ask bitstream you can clearly see a 64 bit repeating pattern. Does the tag have a number on it?

Last edited by marshmellow (2015-01-03 02:41:39)

joe · 2015-01-02 10:57:38

i had try indala command, but don't look like indala, the uid keep changing ...

proxmark3> lf read
#db# buffer samples: ff ff ff ff d6 cc cc c5 ...
proxmark3>
proxmark3> data samples 16000
Reading 16000 samples
Done!
proxmark3>
proxmark3> data plot
proxmark3>
proxmark3> data save investigated.txt
saved to 'investigated.txt'
proxmark3>
proxmark3> lf indalademod
Recovered 458 raw bits, expected: 500
worst metric (0=best..7=worst): 8 at pos 20
UID=0000000000000000000000000000000010001001000000000010000010010000 (089002090)
Occurrences: 1 (expected 5)
proxmark3>

marshmellow · 2015-01-02 10:57:42

The lf search will continue searching tag types if it doesn't conclusively know what tag it is. So even though it was able to demod ask/Manchester data it kept searching because it didn't recognize the format. For the indala, I haven't worked much with the demods yet to see if we can remove more false positives.

Last edited by marshmellow (2015-01-02 11:01:39)

marshmellow · 2015-01-02 11:00:56

But if the "Occurrences: 1 (expected 5) " is not more than one then I think it is probably not psk or indala.

joe · 2015-01-02 11:01:22

the tag no. 000066c0 printed on it .. is a thin card.

marshmellow · 2015-01-02 11:05:17

That number can be found in the ask/Manchester demoded bits it decoded. So it appears it correctly demoded an ask/Manchester tag. Do you know the type of tag or the system it goes too?

Last edited by marshmellow (2015-01-02 11:05:40)

joe · 2015-01-02 11:13:10

i have no info for the tag system.. just a white thin card printed 000066c0.

joe · 2015-01-02 11:15:51

proxmark3> data mandemod
Manchester decoded bitstream
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
proxmark3>

joe · 2015-01-02 11:17:18

proxmark3> data mandemod
Manchester decoded bitstream
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
0 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0
0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1
proxmark3>

joe · 2015-01-02 11:26:03

what are the command ?

marshmellow · 2015-01-02 11:26:19

Just a guess at the format start and stop but the full Id might be: FCF20000000066C0

joe · 2015-01-02 11:37:50

FCF20000000066C0 where this id came from ?

marshmellow · 2015-01-02 11:39:10

The binary of your tag.

joe · 2015-01-02 11:52:39

1111 1100 1111 0010 0000 0000 0000 0000 0000 0000 0000 0000 0110 0110 1100 0000
I did not find it ..

joe · 2015-01-02 12:29:49

Hi Marshmellow ,
Next step , Can I write this id to t5577 and test it ?

Proxmark3 community

Announcement

#1 2014-12-22 23:58:24

Ask/Manchester Demod new functions

#2 2014-12-23 17:57:52

Re: Ask/Manchester Demod new functions

#3 2014-12-23 19:10:20

Re: Ask/Manchester Demod new functions

#4 2014-12-23 19:47:13

Re: Ask/Manchester Demod new functions

#5 2014-12-23 21:10:20

Re: Ask/Manchester Demod new functions

#6 2014-12-23 21:13:09

Re: Ask/Manchester Demod new functions

#7 2014-12-23 23:28:29

Re: Ask/Manchester Demod new functions

#8 2014-12-24 00:05:03

Re: Ask/Manchester Demod new functions

#9 2014-12-24 18:46:40

Re: Ask/Manchester Demod new functions

#10 2014-12-29 02:22:38

Re: Ask/Manchester Demod new functions

#11 2014-12-30 05:56:50

Re: Ask/Manchester Demod new functions

#12 2014-12-30 10:52:11

Re: Ask/Manchester Demod new functions

#13 2014-12-30 15:49:31

Re: Ask/Manchester Demod new functions

#14 2014-12-30 16:04:35

Re: Ask/Manchester Demod new functions

#15 2014-12-31 08:31:23

Re: Ask/Manchester Demod new functions

#16 2014-12-31 08:34:42

Re: Ask/Manchester Demod new functions

#17 2014-12-31 11:22:38

Re: Ask/Manchester Demod new functions

#18 2014-12-31 12:08:34

Re: Ask/Manchester Demod new functions

#19 2014-12-31 16:28:16

Re: Ask/Manchester Demod new functions

#20 2014-12-31 19:24:09

Re: Ask/Manchester Demod new functions

#21 2014-12-31 19:58:46

Re: Ask/Manchester Demod new functions

#22 2014-12-31 20:36:04

Re: Ask/Manchester Demod new functions

#23 2015-01-01 06:50:57

Re: Ask/Manchester Demod new functions

#24 2015-01-01 11:48:58

Re: Ask/Manchester Demod new functions

#25 2015-01-01 14:34:26

Re: Ask/Manchester Demod new functions

#26 2015-01-01 14:37:15

Re: Ask/Manchester Demod new functions

#27 2015-01-01 14:48:18

Re: Ask/Manchester Demod new functions

#28 2015-01-01 17:42:23

Re: Ask/Manchester Demod new functions

#29 2015-01-01 17:44:56

Re: Ask/Manchester Demod new functions

#30 2015-01-01 17:47:02

Re: Ask/Manchester Demod new functions

#31 2015-01-01 17:49:41

Re: Ask/Manchester Demod new functions

#32 2015-01-01 18:26:05

Re: Ask/Manchester Demod new functions

#33 2015-01-01 18:36:28

Re: Ask/Manchester Demod new functions

#34 2015-01-02 10:37:08

Re: Ask/Manchester Demod new functions

#35 2015-01-02 10:45:44

Re: Ask/Manchester Demod new functions

#36 2015-01-02 10:53:30

Re: Ask/Manchester Demod new functions

#37 2015-01-02 10:57:38

Re: Ask/Manchester Demod new functions

#38 2015-01-02 10:57:42

Re: Ask/Manchester Demod new functions

#39 2015-01-02 11:00:56

Re: Ask/Manchester Demod new functions