I am writing C# application for reading/writing RFID tags which are formatted by android aplication (NXP). I found default keys (A0 A1 A2 A3 A4 A5 and D3 F7 D3 F7 D3 F7) and i can read all data from tag, but problem is that i cant write anything on it
other weird thing is that Key block looks like this
[00 00 00 00 00 00 78 77 88 C1 00 00 00 00 00 00] and this block is authenticating by key [A0 A1 A2 A3 A4 A5]
My question is how authenticate sector to have permissions for writing?
let me understand the problem - you wrote the NDEF/RTD information (URI or other) using the Android phone with NFC to some NFC tag (which one - MIFARE Ultralight, Topaz or other?). Now you have an USB NFC reader (which one?) connected to the desktop PC and you are trying to read data from tag? Is it correct?
Please confirm and put there missing information.
BR
STeN
Related
I am trying to send a specific TCP packet to a server but it doesn't seem like it is sending the right data. How should I go about this
I have tried StreamWriter class. Using the NetworkStream. Sending Bytes, sending ASCII and sending text.
TcpClient client = new TcpClient("game_server_ip", port);
NetworkStream stream = client.GetStream();
StreamWriter writer = new StreamWriter(stream);
writer.WriteLine("....T..hello");
writer.Flush();
I am trying to send this exact packet:
00 00 00 0c 54 00 05 68 65 6c 6c 6f
Which translates to the text above
This is also the raw bytes:
0000000c54000568656c6c6f
The expected result should mean that the ingame chat should send a message saying hello. I have made sure the connection is up and running and it is. Also have tried sending the packet using Wireshark and WPE Pro and they work fine. (I got this packet from snifing)
For TCP you will need to connect to the remote endpoint.
Check this example out Example
For some experimentation was working with Simple HTTP Server code here
In one case I wanted it to serve some ANSI encoded text configuration files. I am aware there are more issues with this code but the only one I'm currently concerned with is Content-Length is wrong, but only for certain text files.
Example code:
Output stream initialisation:
outputStream = new StreamWriter(new BufferedStream(socket.GetStream()));
The handling of HTTP get:
public override void handleGETRequest(HttpProcessor p)
{
if (p.http_url.EndsWith(".pac"))
{
string filename = Path.Combine(Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location), p.http_url.Substring(1));
Console.WriteLine(string.Format("HTTP request for : {0}", filename));
if (File.Exists(filename))
{
FileInfo fi = new FileInfo(filename);
DateTime lastWrite = fi.LastWriteTime;
Stream fs = File.Open(filename, FileMode.Open, FileAccess.Read, FileShare.Read);
StreamReader sr = new StreamReader(fs);
string result = sr.ReadToEnd().Trim();
Console.WriteLine(fi.Length);
Console.WriteLine(result.Length);
p.writeSuccess("application/x-javascript-config",result.Length,lastWrite);
p.outputStream.Write(result);
// fs.CopyTo(p.outputStream.BaseStream);
p.outputStream.BaseStream.Flush();
fs.Close();
}
else
{
Console.WriteLine("404 - FILE not found!");
p.writeFailure();
}
}
}
public void writeSuccess(string content_type,long length,DateTime lastModified) {
outputStream.Write("HTTP/1.0 200 OK\r\n");
outputStream.Write("Content-Type: " + content_type + "\r\n");
outputStream.Write("Last-Modified: {0}\r\n", lastModified.ToUniversalTime().ToString("r"));
outputStream.Write("Accept-Range: bytes\r\n");
outputStream.Write("Server: FlakyHTTPServer/1.3\r\n");
outputStream.Write("Date: {0}\r\n", DateTime.Now.ToUniversalTime().ToString("r"));
outputStream.Write(string.Format("Content-Length: {0}\r\n\r\n", length));
}
For most files I've tested with Content-Length is correct. However when testing with HTTP debugging tool Fiddler some times protocol violation is reported on Content-Length.
For example fiddler says:
Request Count: 1
Bytes Sent: 303 (headers:303; body:0)
Bytes Received: 29,847 (headers:224; body:29,623)
So Content-Length should be 29623. But the HTTP header generated is
Content-Length: 29617
I saved the body of HTTP content from Fiddler and visibly compared the files, couldn't notice any difference. Then loaded them into BeyondCompare Hex compare, there are several problems with files like this:
Original File: 2D 2D 96 20 2A 2F
HTTP Content : 2D 2D EF BF BD 20 2A 2F
Original File: 27 3B 0D 0A 09 7D 0D 0A 0D 0A 09
HTTP Content : 27 3B 0A 09 7D 0A 0A 09
I suspect problem is related to encoding but not exactly sure. Only serving ANSI encoded files, no Unicode.
I made the file serve correctly with right Content-Length by modifying parts of the file with bytes sequence. Made this change in 3 parts of the file:
2D 2D 96 (--–) to 2D 2D 2D (---)
Based on the bytes you pasted, it looks like there are a couple things going wrong here. First, it seems that CRLF in your input file (0D 0A) is being converted to just LF (0A). Second, it looks like the character encoding is changing, either when reading the file into a string, or Writeing the string to the HTTP client.
The HTTP Content-Length represents the number of bytes in the stream, whereas string.Length gives you the number of characters in the string. Unless your file is exclusively using the first 128 ASCII characters (which precludes non-English characters as well as special windows-1252 characters like the euro sign), it's unlikely that string.Length will exactly equal the length of the string encoded in either UTF-8 or ISO-8859-1.
If you convert the string to a byte[] before sending it to the client, you'll be able to get the "true" Content-Length. However, you'll still end up with mangled text if you didn't read the file using the proper encoding. (Whether you specify the encoding or not, a conversion is happening when reading the file into a string of Unicode characters.)
I highly recommend specifying the charset in the Content-Type header (e.g. application/x-javascript-config;charset=utf-8). It doesn't matter whether your charset is utf-8, utf-16, iso-8859-1, windows-1251, etc., as long as it's the same character encoding you use when converting your string into a byte[].
i have compressed file (binary file/compressed string - i'm not sure what it is),
i'am trying to decompress this file by c#/vb.net ,
i tried to decompress it with Gzip:
Private Shared Function gzuncompress(ByVal data() As Byte) As Byte()
Dim input As MemoryStream = New MemoryStream(data)
Dim gzip As GZipStream = New GZipStream(input, CompressionMode.Decompress)
Dim output As MemoryStream = New MemoryStream
gzip.CopyTo(output)
Return output.ToArray
End Function
gzuncompress(New System.Net.WebClient().DownloadData("http://haxball.com/list3"))
but there is an exception (where : gzip.CopyTo(output)):
The magic number in GZip header is not correct
but when i tried to uncompress it by php it's worked :) .
php header('Content-Type: text/html; charset=utf-8');
$list = file_get_contents('http://haxball.com/list3');
$list = gzuncompress($list);
$len = implode('', unpack('n*', $list));
$bytes = unpack('c*', $list);
$string = implode('', array_map('chr', $bytes));
echo $string;
you can check the code here:
http://www.compileonline.com/execute_php_online.php
someone have the php's gzuncompress c#/vb.net alternative?
Even if there is a extarnal exe file that can do the same as the php's gzuncompress function it will be very good answer,
kind of:
Process.start("c:\umcompress.exe -f c:\list3 -o c:\res.txt")
Note:A good example is better than explanation
Update:
The First 30 Bytes Of The File:
78 DA 8C BD 79 F4 5D D7 55 26 78 65 0D F1 24 0F 89 E3 98 4C 5C 47 21 71 E2 C8 B9 E7 9E E1
That is a zlib stream. The zlib format is described in RFC 1950, and consists of a two-byte header and a four-byte trailer around a deflate stream. You will need to write your own code to process the header and trailer, and you can use the DeflateStream class to decompress the deflate stream.
Or you can use DotNetZip which will process the zlib stream directly.
Just found myself in need of opening *.COM files in a C# application.
*.COM files are generated by fasm, with assemly code like this one:
org 100h
jmp start
msg: db "Hi", 0Dh,0Ah, 24h
start:
mov dx, msg
mov ah, 09h
int 21h
mov ah, 0
int 16h
ret
when opened with textprocessors like Sublime, it's represented that code represented like this:
eb05 4869 0d0a 24ba 0201 b409 cd21 b400
cd16 c3
I tried to open this file in application with code like this one
string COMtext = File.ReadAllText(filename,encoding);
byte[] info = new UTF8Encoding(true).GetBytes(COMtext);
When checked with MessageBox.Show(info[i].ToString("x2"));
it says, what first byte is EF, 2nd is BF (splitting EB in halfs), then adding one additional byte on 3rd place (BD). After this - everything parsed just as planned.
4th:05, 5th:48 etc.
What do I do wrong and is there any way to fix it without workaround (which one is unclear for me at this stage, because I don't know if would have same behavior or dont)
You need to open the file as a binary stream, not a text steam. As text it is getting encoded as Unicode surrogates.
Use File.OpenRead with a byte array. You can also use File.ReadAllBytes but I don't recommend it since a large file will cause an OutOfMemoryException.
I have a CSV that is encoded with UTF32. When I open stream in IE and open with Excel I can read everything. On iPad I stream and I get a blank page with no content whatsoever. (I don't know how to view source on iPad so there could be something hidden in HTML).
The http response is written in asp.net C#
Response.Clear();
Response.Buffer = true;
Response.ContentType = "text/comma-separated-values";
Response.AddHeader("Content-Disposition", "attachment;filename=\"InventoryCount.csv\"");
Response.RedirectLocation = "InventoryCount.csv";
Response.ContentEncoding = Encoding.UTF32;//works on Excel wrong in iPad
//Response.ContentEncoding = Encoding.UTF8;//works on iPad wrong in Excel
Response.Charset = "UTF-8";//tried also adding Charset just to see if it works somehow, but it does not.
EnableViewState = false;
NMDUtilities.Export oUtilities = new NMDUtilities.Export();
Response.Write(oUtilities.DataGridToCSV(gvExport, ","));
Response.End();
The only guess I can make is that iPad cannot read UTF32, is that true? How can I view source on iPad?
UPDATE
I just made an interesting discovery. When my encoding is UTF8 things work on iPad and characters are displayed properly, but Excel messes up a character. But when I use UTF32 the inverse is true. iPad displays nothing, but Excel works perfectly. I really have no idea what I can do about this.
iPad UTF8 outputs = " Quattrode® "
Excel UTF8 outputs = " Quattrode® "
iPad UTF32 outputs = " "
Excel UTF32 outputs = " Quattrode® "
Here's my implementation of DataGridToCsv
public string DataGridToCsv(GridView input, string delimiter)
{
StringBuilder sb = new StringBuilder();
//iterate Gridview and put row results in stringbuilder...
string result = HttpUtility.HtmlDecode(sb.ToString());
return result;
}
UPDATE2 Excel is barfing on UTF8 >:{. Man. I just undid the second option he lists because it doesnt work on iPad. I cant win for losing on this one.
UPDATE3Per your suggestions I have looked at the hex code. There is no BOM, but there is a difference between the file layouts.
UTF84D 61 74 65 (MATE from the first word MATERIAL)
UTF324D 00 00 00 (M from the first word MATERIAL)
So it looks like UTF32 lays things out in 32 bits vs UTF8 doing it in 8 bits. I think this is why Excel can guess. Now I will try your suggested fixes.
The problem is that the browser knows your data's encoding is UTF-8, but it has no way of telling Excel. When Excel opens the file, it assumes your system's default encoding. If you copy some non-ASCII text, paste it in Notepad, and save it with UTF-8 encoding, though, you'll see that Excel can properly detect it. It works on the iPad because its default encoding just happens to be UTF-8.
The reason is that Notepad puts the proper byte order mark (EF BB BF for UTF-8) in the beginning of the file. You can try it yourself by using a hex editor or some other means to create a file containing
EF BB BF 20 51 75 61 74 74 72 6F 64 65 C2 AE 20
and opening that file in Excel. (I used Excel 2010, but I assume it would work with all recent versions.)
Try making sure your output starts with those first 3 bytes.
How to write a BOM in C#
byte[] BOM = new byte[] { 0xef, 0xbb, 0xbf };
Response.BinaryWrite(BOM);//write the BOM first
Response.Write(utility.DataGridToCSV(gvExport, ","));//then write your CSV
Excel tries to infer the encoding based on your file contents, and ASCII and UTF-8 happen to overlap on the first 128 characters (letters and numbers). When you use UTF-16 and UTF-32, it can figure out that the content isn't ASCII, but since most of your content using UTF-8 matches ASCII, if you want your file to be read in as UTF-8, you have to tell it explicitly that the content is UTF-8 by writing the byte order mark as Gabe said in his answer. Also, see the answer by Andrew Csontos on this other question:
What's the best way to export UTF8 data into Excel?