I have to convert the following code into Qt c++
So I need to understand what these lines to.
#key in this code is a pem key file contents by openssl
key = KEY+#key.public_key.to_der
so i think this is converting that key to der format and then combining it with KEY.
is it right?
whats does this do? to_sizet(key.size)
As you can see the function returns [num].pack('V'). But i dont know wht does it do? I mean [num].pavck('V'). what is it?
And whats does this mean. key.size is it the strlen of key?
def write_crx
print "write crx..." if #verbose
key = KEY+#key.public_key.to_der
File.open(#crx, 'wb') do |file|
file << MAGIC
file << EXT_VERSION
file << to_sizet(key.size)
file << to_sizet(#sig.size)
file << key
file << #sig
File.open(#zip, 'rb') do |zip|
file << zip.read
end
end
puts "done at \"#{#crx}\"" if #verbose
end
def to_sizet num
return [num].pack('V')
end
Well I have one more Question. Forgot to add last time.
what does this line do?
KEY = %w(30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00).map{|s| s.hex}.pack('C*')
so i think this is converting that key to der format and then combining it with KEY. is it right?
Yes.
whats does this do? to_sizet(key.size) As you can see the function returns [num].pack('V'). But i dont know wht does it do? I mean [num].pavck('V'). what is it?
Well, just have a look at what the documentation on Array#pack says. With the V modifier, it just converts the array to a binary representation of a 32 bit unsigned integer type.
And whats does this mean. key.size is it the strlen of key?
Again, the Ruby documentation helps. String#size is indeed the string length.
what does this line do?
KEY = %w(30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00)
.map{|s| s.hex}.pack('C*')
%(…) defines an array where each of its entries, separated by whitespace is treated as a separate string. %w(one two) is essentially a shorthand for ["one", "two"].
After that, we have to look up (again in the documentation) the meanings of Array#map and String#hex.
map simply applies an operation to each element of an array and creates a new array with the result. The operation is s.hex – that is, parse each of the strings as a hexadecimal number.
The result is once again packed, this time using the C* operation which, the documentation tells us, converts the numbers into their corresponding (unsigned) 8-bit character codes.
In summary: that line converts the hexadecimal values into a string of their respective characters.
Afterthought: you should really install Ruby and play a bit with the interactive Ruby console, irb. Keying in the above line already helps a lot:
$ irb
>> %w(30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00).map{|s| s.hex}
=> [48, 129, 159, 48, 13, 6, 9, 42, 134, 72, 134, 247, 13, 1, 1, 1, 5, 0, 3, 129, 141, 0]
>> %w(30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00).map{|s| s.hex}.pack('C*')
=> "0\201\2370\r\006\t*\206H\206\367\r\001\001\001\005\000\003\201\215\000"
Related
I'm experimenting. I created a .txt file with the word hi and run gzip test.txt to compress it.
This gives me a file test.txt.gz with the following bytes:
1F 8B 08 08 E6 E8 3F 60 00 03 62 2E 74 78 74 00
CB C8 04 00 AC 2A 93 D8 02 00 00 00
With the software 101 editor, I found out that the first line is the header.
CB C8 04 00 are the compressed data
AC 2A 93 D8 is "CRC of the data section"
02 00 00 00 is the "size of the uncompressed input"
What I'm trying to do (I don't know if it is even possible): I want to have my own characters as "compressed" data but want the .gz file to be still valid.
I tried replacing CB C8 04 00 with 62 62 62 62 (letter 'b' 4 times) but the file is invalid then. Then I tried to replace AC 2A 93 D8, too with the CRC32 value of "bbbb", but the file is still invalid. I can't decompress it. Running gzip -d test.txt.gz returns "unexpected end of file".
Is it possible what I'm trying to do? If yes: what am I doing wrong?
CB C8 04 00 is a valid deflate stream. 62 62 62 62 is not. A gzip member is a gzip header, a valid deflate stream, and a gzip trailer.
Deflate streams are defined in RFC 1951.
I have a source data file which I have been using JREPL.BAT to perform some very simple search and replace operations quite successfully. I now need to expand on that to do 2 jobs.
1. remove all lines that start with the string "appX_formContent". This line contain a lot of html output also, it all needs to be deleted on that line.
2. remove all lines that start with "Hex Payload:" and the subsequent line that comes with it.
This is an example of the input data file which shows 2 records. The delimiter between each record is the row that contains "-----------------".
-----------------
Message Headers
JMSCorrelationID: 60bb7750-e9e2-11e9-98bb-42010a961307
JMSPriority: 4
JMSRedelivered: false
Message Properties
app_trackingId: 190990a2-d8d8-43eb-814a-36ceba7a9111
appX_formInstanceIdentifier: FRM389083
appX_formContent: {"data":{"C7d14a6eb-70e7-402d-9d6e-4efd01ba561c":"N","Y","test.</p>\n<p>test form data to be informed </p>\n<p>...............</p>\n<p><strong>Update</strong></p>\n<p><strong>years</strong>"<p>supervision</p>","<p>:true,"c9377ae2-901d-4461-929c-c76e26dc6183":false}}}
app_sourceSystemId: source
app_eventCode: FORM_OUTPUT
app_instigatingUserId: 66
JMSXGroupSeq: 0
Hex Payload:
25 50 44 46 2D 31 2E 35 0D 0A 34 20 30 20 6F 62 6A 0D 0A 3C 3C 2F 54
-----------------
Message Headers
JMSCorrelationID: 641a80d0-e9e2-11e9-98bb-42010a961307
JMSPriority: 4
JMSTimestamp: 2019 10 08 16:43:40
JMSRedelivered: false
Message Properties
app_trackingId: a3c2fe93-ef71-4611-9605-9858ff67a6e8
appX_formInstanceIdentifier: FRM388843
appX_formContent: {"data":{"C7d14a6eb-70e7-402d-9d6e-4efd01ba561c":"N","Y","test.</p>\n<p>test form data to be informed </p>\n<p>...............</p>\n<p><strong>Update</strong></p>\n<p><strong>years</strong>"<p>supervision</p>","<p>:true,"c9377ae2-901d-4461-929c-c76e26dc6183":false}}}
app_sourceSystemId: source
app_eventCode: FORM_OUTPUT
app_instigatingUserId: 433
JMSXGroupSeq: 0
Hex Payload:
25 50 44 46 2D 31 2E 35 0D 0A 34 20 30 20 6F 62 6A 0D 0A 3C 3C 2F
-----------------
This is the batch file that I use to call jrepl - very simple.
call jrepl ".*(?:appX_formContent: .*)" "" /m /f "inpu.txt" /o "output.txt"
I've only tried to remove the appX_formContent line with the regex but it isn't producing any output. I'm not good with regex so help appreciated.
Not sure how to handle the second task of deleting the Hex Payload: line.
Here is a problem I could not solve despite all my efforts. So I am totally stuck, please help!
For regular, “ASCII” mode the following simplified file and stream outputs
FILE *fa = fopen("utfOutFA.txt", "w");
fprintf(fa, "Line1\nLine2");
fclose(fa);
ofstream sa("utfOutSA.txt");
sa << "Line1\nLine2";
sa.close();
result, naturally, in exactly the same text files (hex dump):
00000000h: 4C 69 6E 65 31 0D 0A 4C 69 6E 65 32 ; Line1..Line2
where the new line \n is expanded to CRLF: 0D 0A – typical for Windows.
Now, we do the same for Unicode output, namely UTF-16 LE which is a sort of “default”. File output
FILE *fu = fopen("utfOutFU.txt", "w, ccs=UNICODE");
fwprintf(fu, L"Line1\nLine2");
fclose(fu);
results in this contents:
00000000h: FF FE 4C 00 69 00 6E 00 65 00 31 00 0D 00 0A 00 ; ÿþL.i.n.e.1.....
00000010h: 4C 00 69 00 6E 00 65 00 32 00 ; L.i.n.e.2.
which looks perfectly correct considering BOM and endianness, including CRLF: 0D 00 0A 00. However, the similar stream output
wofstream su("utfOutSU.txt");
su.imbue(locale(locale::empty(), new codecvt_utf16<wchar_t, 0x10ffffUL,
codecvt_mode(generate_header + little_endian)>));
su << L"Line1\nLine2";
su.close();
results in one byte less and overall incorrect text file:
00000000h: FF FE 4C 00 69 00 6E 00 65 00 31 00 0D 0A 00 4C ; ÿþL.i.n.e.1....L
00000010h: 00 69 00 6E 00 65 00 32 00 ; .i.n.e.2.
The reason is wrong expansion of CRLF: 0D 0A 00. Is this a bug? Or have I done something wrong?
I use Microsoft Visual Studio compiler (14.0 and other). I tried using stream endl instead of \n – same result! I tried to put su.imbue() first and then su.open() – all the same! I also checked the UTF-8 output (ccs=UTF-8 for file and codecvt_utf8 for stream) – no problem as CRLF stays the same as in ASCII mode: 0D 0A
I appreciate any ideas and comments on the issue.
When you are imbue()'ing a new locale into the std::wofstream, you are wiping out its original locale. Don't use locale::empty(), use su.getloc() instead, so the new locale copies the old locale before modifying it.
Also, on a side note, the last template parameter of codecvt_utf16 is a bitmask, so codecvt_mode(generate_header + little_endian) really should be std::generate_header | std::little_endian instead.
su.imbue(std::locale(su.getloc(), new codecvt_utf16<wchar_t, 0x10ffffUL,
std::generate_header | std::little_endian>));
I've discovered that this problem comes from the fact that you are writing the file in text mode. What you want to do is open your output file in binary and the issue will be solved, like so:
wofstream su("utfOutSU.txt", ofstream::out | ofstream::binary);
su.imbue(locale(su.getloc(), new codecvt_utf16<wchar_t, 0x10ffffUL,
codecvt_mode(generate_header + little_endian)>));
su << L"Line1\r\nLine2";
su.close();
Something "clever" is probably done behinde the scenes when writing text.
I want to inflate HTML webpages. I am using zlib functions
inflateInit2(&zstream,15+32);
and then
inflate(&zstream,Z_SYNC_FLUSH);
It works for lots of webpages correctly but for "www.tabnak.ir" it does not work correctly.
invalid distance too far back is the ERROR I got for this website.
This webpage is also gzip and utf8.
How should I deal with that?
This is For Bing.com which works Fine
1f 8b 08 00 ef 8c 77 56 00 ff ec 5a eb 73 9c 46
12 ff 9e aa fc 0f 04 d5 9d ad 78 1f c0 3e b4 0b
96 52 b2 24 2b ba 73 1c 9d 2d 27 b9 8a af b6 06
This is For tabnak.ir which results in invalid distance too far back Error
1f 8b 08 00 00 00 00 00 00 03 ed fd db 73 5b d7
99 2f 8a 3e ab ab d6 ff 30 ac ae ac d8 3b 82 80
39 71 a7 6d 55 39 89 7b 75 f7 4a d2 7d 92 74 af
The zlib/gzip format performs compression saying things like "The next 22 bytes are the same as the 22 bytes we saw 1013 bytes ago.
In this case the record describing the repetition, is from before the size of the 'window'.
Given you have specified a maximum size of window, the likelihood, is that the data format has changed a bit, or the data you received is not the same as was sent.
Some things to check.
You are using the latest zlib library.
Standard utilities (e.g. gunzip, winzip) can decompress the data.
The data you are getting is not being mangled by a text filter ('rb' vs 'rt')
If that hasn't helped, try walking through the data and understanding what the failure in gzip is.
It would seem that the file you are trying to "inflate" (decompress using zlib) is not a valid zip file. Since bing.com is most likely not a zlib file, it might be pure coincidence that you found something quite early that prevented decompression.
I am currentlly on a project that requires me to load a JavaCard application Applet ( a .cap ) file to a JavaCard. Our framework is based on Visual C++ and PCSC, so we need to load the same applet to a series of JavaCards. Does anyone know how this can be processed? I mean, where should I start. Thanks!
You are correct that this is not a trivial job.
There are differences between different javacards, but generally you need to do 4 things:
initialize secure communications with the card (because many javacards are "global platform" cards they require a secure channel)
send a command saying "i wanna install an applet"
send the binary data for the applet to be installed
send a command to "instantiate" the applet after the binary data is sent
I'd recommend using the eclipse plugin to install the applet initially, because you can see the APDUs generated by the plugin to do the steps above. Once you know the APDU commands you must send to install your applet, you can directly send these commands using the PCSC interface from your C++ code to automate installation on a large number of cards.
My company makes a web browser plugin called Card Boss for doing this kind of thing (card communications via pcsc) from a browser - there's a web page you can use where you can type your own APDUs and send them to the card at the follwing URL:
https://cardboss.cometway.com/content.agent?page_name=Card+Boss+Lab
If you use our tool, your applet installation script should look something like this (note that this is a script for a JCOP card using the default jcop keys)
MESSAGE BOX Installing applets...
INIT CHANNEL 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f, 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
// INSTALL CAP:
SEND 80 E6 02 00 1D 10 A0 00 00 00 09 00 03 FF FF FF FF 89 10 71 00 01 08 A0 00 00 00 03 00 00 00 00 00 00
// LOADING CAP:
SEND 80 E8 00 00 FA C4 82 01 03 01 00 25 DE CA FF (snip, I removed a bunch
of binary data representing the cap file to shorten this post, and you might
need multiple SEND commands because of limits on the size of APDUS)
// INSTANTIATING Applet
SEND 80 E6 0C 00 1E 05 63 6F 6D 65 74 07 63 6F 6D 65 74 00 01 05 00 00 00 00 00 01 00 06 C9 04 68 2C 00 03 00 00