I currently took a photo with a camera which returned to me all its values in decimal and after extracting the values my jpeg file are(i converted them to hex here but they were still saved in decimal)
FF
D8
FF
FE
00
24
30
00
9D
08
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
F0
00
40
01
0C
00
32
............
00
54
65
6B
D9
9F
FF
FF
D9
i saved theses value into a file called image.jpg (they were saved in decimal)
however the image file was not able to read it and I can not use the linux command convert as it tells me "Bogus marker length". What would i be doing wrong that doesnt allow me to see the image?
Related
I want to write to a mifare classic 4k, using the following APDU command (UPDATE BINARY):
APDU = {FF D6 00 20 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0Fh}
It seems fine as a get a 90 00 result...
but when i read the card back I always got the following (even with different data...):
sector: 8 (block 32), auth OK
032: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
033: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
034: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
where does this string D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF come from?
Note that i didn't change any setting on the card and was properly authenticated. It was a blank card and i didn't touch the trailer.
I m using a ACR122 reader (this command comes direct from the documentation of the reader...)
Ok i found my problem, i was setting the wrong size for the cbSendLength parameter in SCardTransmit.
Now i set the correct one (the whole size of the APDU command: 21) and it works fine.
Sorry.
I am trying to read the plain 2048 byte sized data sectors from a data CD on OS X.
But when I open a device such as "/dev/disk8", I get sectors of 2352 in size, with a 16 byte header before each sector's actual Mode1 data.
Even with the BSD tools such as hexdump this can be seen, when reading an older CD made by Apple:
$ hexdump -n 512 -C /dev/disk8
00000000 00 ff ff ff ff ff ff ff ff ff ff 00 00 02 00 01 |................|
00000010 45 52 08 00 00 05 00 00 00 01 00 01 00 00 00 00 |ER..............|
00000020 00 04 00 00 00 10 00 05 00 01 00 00 00 1e 00 19 |................|
00000030 ff ff 00 00 00 41 00 05 07 01 00 00 00 4f 00 1f |.....A.......O..|
00000040 f8 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The actual sector's data starts here at offset 0x10 with "ER". But the "ER" should be at offset 0.
How can I make this work in my own application without having to remove the extra data in a separate step?
I looked at the various ioctl functions in "IOCDMediaBSDClient.h" and "IOCDTypes.h", but I could not find one that lets me specify that I want to get only the plain data content from the sectors.
I also believe that my existing code which I wrote about 15 years ago, was able to handle this as desired back then, but something has changed in OS X since then, breaking my old code. And now I cannot figure out how to fix that. That code uses ioctl with DKIOCCDREAD, with parameters sectorArea=kCDSectorAreaUser and sectorType=kCDSectorTypeMode1. But that gives me the 16 byte header just like a normal read call does, even though Mode1 means that I should be getting 2048 byte sectors without any headers, as far as I understand it.
As established in the comments section, the answer seems to be to to use the character device (rdisk), not the block device (disk) node. The distinction is not well documented as far as I'm aware, and for hard drives and SSDs is actually quite small - in most cases you can use either. For optical discs it's significantly different, for whatever reason.
I looked into this some time ago, but I forget the details of it, unfortunately. If you're interested in this, you'll find the implementation in the "IOStorageFamily" and "IOCDStorageFamily" source code bundles on Apple's https://opensource.apple.com/ site.
The code files you're after are the ones relating to "BSD clients" - IOMediaBSDClient.cpp/.h in IOStorageFamily, and IOMediaBSDClient.cpp/.h for CDs specifically. The block ("disk") device's ioctls are first handled in dkioctl_bdev() and then forwarded on to the generic dkioctl(), which in turn calls the IOCDMediaBSDClient::ioctl() method. The character device ("rdisk") uses dkioctl_cdev() instead.
So, I'm trying to understand how PNG to BMP conversion actually takes place. I created the following 8x8 pixel PNG using a tool online:
I then performed a conversion using the ImageMagik tool in OSX terminal:
$ convert -monochrome pic.png pic.bmp
Afterwards, I did a hexdump of the image:
$ hexdump -C pic.bmp
00000000 42 4d 4a 01 00 00 00 00 00 00 8a 00 00 00 7c 00 |BMJ...........|.|
00000010 00 00 08 00 00 00 08 00 00 00 01 00 18 00 00 00 |................|
00000020 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 ff 00 |................|
00000040 00 00 00 00 00 ff 42 47 52 73 8f c2 f5 28 51 b8 |......BGRs...(Q.|
00000050 1e 15 1e 85 eb 01 33 33 33 13 66 66 66 26 66 66 |......333.fff&ff|
00000060 66 06 99 99 99 09 3d 0a d7 03 28 5c 8f 32 00 00 |f.....=...(\.2..|
00000070 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff |................|
00000090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000130 ff ff 00 00 00 ff ff ff ff ff ff ff ff ff ff ff |................|
00000140 ff ff ff ff ff ff ff ff ff ff |..........|
0000014a
So, obviously we have a BMP header from 0x00 - 0x8C. Then we have FF for white pixels and 00 for black. That all makes sense, but the structure of the output doesn't. So far, it seems that there is a 3 to 1 ratio. 3 bytes per pixel. I'm assuming this means black, white, no-color?
I need to fully understand why there are 3 bytes per pixel instead of 2. Ideally, I would like a binary 1 or 0 for each pixel instead. Is there a way to do this? And if not, can someone please explain the layout of bytes? Specifically: Why are the 3 00s at 0x132 - 0x134 and not the very beginning?
Thanks
Imagemagick, in fact, does support 1-bit BMP, if using either BMP3 or BMP2 formats, but not BMP4 which is just BMP. So if you want 1-bit depth per channel, then do
Input:
convert image.png -depth 1 BMP3:result.bmp
If you want a 1-bit depth for the whole image (i.e. binary), then do
convert image.png -depth 1 -type bilevel BMP3:result2.bmp
Or
convert image.png -depth 1 -threshold 50% BMP3:result3.bmp
I'm not sure which question this will answer, but from the Usage docs
IM can not produce BMP's at depth levels other than 8. However you can
use NetPBM image processing set to do the final conversion to other depth
levels (This needs at least a Q16 version of IM)...
So if we leverage NetPBM
$ convert pic.png -depth 1 ppm:- | hexdump
Which gives (Note the values are 0 & 1, but you still have a RGB channels)
0000000 50 36 0a 38 20 38 0a 31 0a 00 00 00 01 01 01 01
0000010 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
*
00000c0 01 01 01 01 01 01 01 01 01
00000c9
So a workaround my be as simple as
$ convert pic.png -depth 1 ppm:- | pnmdepth 1 | ppm2bmp > pic.bmp
On Fedora 27 that command is:
$ convert pic.png -depth 1 ppm:- | pnmdepth 1 | ppmtobmp > pic.bmp
You need:
$ dnf install netpbm-progs
For an app that has been around for many years, and which has stored the classic Alias records in files, I like to recreate Alias files pointing to the same file now, without having to resolve the Alias first (because the destination may be unavailable at that moment).
Supposedly this should accomplish this:
CFDataRef aliasRecord = ... ; // contains the Alias Record data, see below for an example
CFURLRef url = ... ; // initialized with a file URL
CFDataRef bmData = CFURLCreateBookmarkDataFromAliasRecord (NULL, aliasRecord);
CFError error;
bool ok = CFURLWriteBookmarkDataToFile (bmData, url, 0, &error);
However, the write function fails, and the error says "The file couldn’t be saved."
If I instead create bookmark data using CreateBookmarkData, the write succeeds.
How do I make this work? I'd try writing an old style Alias file with the data in the resource fork if that wasn't so utterly deprecated.
Here's an example alias record I'd have in the aliasRecord object - I can resolve this using the classic Alias Manager FSResolveAlias function, so I know that it is indeed valid.
00 00 00 00 01 12 00 02 00 01 06 54 54 73 4D 42
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 CC 31 2F 12 48 2B 00 00 01 A5
F3 9B 03 74 6D 70 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 01 AC 1C 67 D1 FE B7 D0 00 00 00 00 00 00
00 00 FF FF FF FF 00 00 09 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 07 70 72 69 76 61 74
65 00 00 10 00 08 00 00 CC 31 12 F2 00 00 00 11
00 08 00 00 D1 FE 9B B0 00 00 00 01 00 04 01 A5
F3 9B 00 02 00 13 54 54 73 4D 42 50 3A 70 72 69
76 61 74 65 3A 00 74 6D 70 00 00 0E 00 08 00 03
00 74 00 6D 00 70 00 0F 00 0E 00 06 00 54 00 54
00 73 00 4D 00 42 00 50 00 12 00 0B 70 72 69 76
61 74 65 2F 74 6D 70 00 00 13 00 01 2F 00 FF FF
00 00
CFURLCreateBookmarkDataFromAliasRecord() doesn't create the bookmark data with the kCFURLBookmarkCreationSuitableForBookmarkFile option required by CFURLWriteBookmarkDataToFile().
CFURLCreateBookmarkDataFromAliasRecord() was intended as a way to convert alias records stored a program's own data files to bookmarks with no I/O.
Before CFURLWriteBookmarkDataToFile(), Finder Alias files (bookmark files) were created by the Finder. Those files contained an Alias resource (containing known properties that could be obtained from the Alias resource with FSCopyAliasInfo()) and icon resources. Apple needed the bookmark data in the files written by CFURLWriteBookmarkDataToFile() to provide the same properties. The kCFURLBookmarkCreationSuitableForBookmarkFile option enforces that requirement.
If you have an AliasHandle and want to create a new-style Alias file with bookmark data, you'll need to:
(1) resolve the AliasHandle to an FSRef, create a CFURLRef from the FSRef, and then create the bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option,
or
(2) you'll need to resolve the bookmark data created with CFURLCreateBookmarkDataFromAliasRecord(), and then create a new bookmark data using the kCFURLBookmarkCreationSuitableForBookmarkFile option.
However, you've indicated you'd like to handle this without resolving the AliasHandle, so the only solution is to create an old-style Finder Alias file. Although I know you already know how to accomplish that, it's described at How do I create a Finder alias within an application?.
The first time a user resolves/opens that old-style Alias file with the Finder, the Finder will detect the Alias file needs to be updated (i.e., CFURLCreateByResolvingBookmarkData() will return with isStale == true) and the Finder will create a new bookmark to the Alias file's target and re-write the Alias file. CFURLCreateBookmarkDataFromFile() will continue to support old-style Alias files as long as possible for backwards compatibility.
I am new to this area; so excuse me if I did not describe the issue well.
I have a hex file which should contain three images (width: 640, height: 333). The hex file is 1.2 MB. So if we do a little calculation, we obtain that each pixel should have 16-bit of data.
Some of hex code of the file is as below:
90 eb 6f 14 02 02 fd fd 4e 01 80 02 00 00 00 00
90 eb 6f 14 82 82 7d 7d 4e 01 80 02 03 00 00 00
90 eb 6f 14 c2 c2 3d 3d 4e 01 80 02 00 00 8e 08
a7 33 0f d4 00 01 00 01 00 01 43 01 f8 03 0e 17
00 01 00 00 00 00 02 00 00 00 00 00 00 00 01 00
00 04 00 00 01 01 00 00 00 00 00 00 00 00 00 00
00 00 01 01 00 00 00 00 00 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 01 01
00 00 00 00 01 00 00 00 00 00 00 00 00 00 01 01
00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00
00 01 00 00 08 01 00 00 00 00 00 00 00 00 00 00
00 01 00 00 00 00 00 01 00 00 00 00 00 0a 01 00
00 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00
02 00 00 01 00 00 00 01 00 00 00 00 00 00 00 01
As you can see there is a header with 4 row content which 3 of them is similar. the bitmap data begins. The repeating row is repeated another two times in the file. So I assume that the repeating structure is at the beginning of each of 3 images. But the data between these headers are 210 KB, which means 8-bit per pixel. So I read every 8-bit as an tiny integer and set it to rgb of corresponding pixels of images. So I obtained 3 gray images. Also 630 KB of data remains unread in the file.
Here is magnified version of the original image as gray (original version of the picture is colored) and obtained image. As you see, there are some pixels (every other pixel) which are totally different in compare to original pixels, but whole image is almost correct.
So, my questions are as below:
What is the true structure of the hex file? How should I read the hex file?
How can I achieve original colored file?
What is the extra 630 KB of data!? And what is the wrong pixels?!
also here is original image(i.stack.imgur.com/NdBOa.png), original image as gray(i.stack.imgur.com/wDUPB.png) and obtained image (i.stack.imgur.com/lY3ib.png).
Nothing conclusive, but here is what I have found...
If you hex dump the file and look at the start, you find 90eb and if you look for that throughout the file, you get this:
xxd a.raw | egrep "90eb"
0000000: 90eb 6f14 0202 fdfd 4e01 8002 0000 0000 ..o.....N.......
0000010: 90eb 6f14 8282 7d7d 4e01 8002 0300 0000 ..o...}}N.......
0000020: 90eb 6f14 c2c2 3d3d 4e01 8002 0000 8e08 ..o...==N.......
0034340: e773 2bf4 90eb 6f14 c2c2 3d3d 4e01 8002 .s+...o...==N...
0068660: 0301 0100 ca03 0104 90eb 6f14 c2c2 3d3d ..........o...==
The data looks to begin 32 bytes after every 90eb. If the image is 640x333, there will be 213,120 bytes per image. So we can extract the basic planes/channels of the image like this with ImageMagick:
dd if=a.raw bs=1 skip=64 count=213120 | convert -depth 8 -size 640x333 gray:- a.png
dd if=a.raw bs=1 skip=213860 count=213120 | convert -depth 8 -size 640x333 gray:- b.png
dd if=a.raw bs=1 skip=427656 count=213120 | convert -depth 8 -size 640x333 gray:- c.png
Now we have a problem - the individual images are not positioned the same in all three images - you can see that if I animate the 3 frames together like this:
convert -delay 80 a.png b.png c.png -normalize anim.gif
So now I am a bit lost - are there multiple cameras since the viewpoint seems to move?
I don't know - maybe my findings will inspire someone else! Let's see.
Another approach may be to compare the statistics - if you look at the "original" image's statistics, you get this:
identify -verbose original.png | egrep "Red:|Green:|Blue:|mean:|deviation"
Red:
mean: 5.77718 (0.0226556)
standard deviation: 17.0501 (0.066863)
Green:
mean: 13.7015 (0.0537312)
standard deviation: 38.4053 (0.150609)
Blue:
mean: 10.2863 (0.0403386)
standard deviation: 30.1792 (0.11835)
If you now look at the statistics for the a.png, b.png and c.png as extracted above, you get this:
identify -verbose a.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
Gray:
mean: 2.48532 (0.00974635)
standard deviation: 9.00678 (0.0353207)
identify -verbose b.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
Gray:
mean: 10.1611 (0.0398473)
standard deviation: 30.2288 (0.118544)
identify -verbose c.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
Gray:
mean: 2.26135 (0.00886804)
standard deviation: 7.43093 (0.0291409)
And there doesn't seem to be any correlation between the statistics of the "original" image and the putative "channels" of the extracted images... I think there is more going on here than I can guess.