Read and Write File Section of File Only (Without Streams) - windows

Most high-level representations of files are as streams. C's fopen, ActiveX's Scripting.FileSystemObject and ADODB.Stream - in fact, anything built on top of C is very likely to use a stream representation to edit files.
However, when modifying large (~4MiB) fixed-structure binary files, it seems wasteful to read the whole file into memory and write almost exactly the same thing back to disk - this will almost certainly have a performance penalty attached. Looking at the majority of uncompressed filesystems, there seems to me to be no reason why a section of the file couldn't be read from and written to without touching the surrounding data. At a maximum, the block would have to be rewritten, but that's usually on the order of 4KiB; much less than the entire file for large files.
Example:
00 01 02 03
04 05 06 07
08 09 0A 0B
0C 0D 0E 0F
might become:
00 01 02 03
04 F0 F1 F2
F3 F4 F5 0B
0C 0D 0E 0F
A solution using existing ActiveX objects would be ideal, but any way of doing this without having to re-write the entire file would be good.

Okay, here's how to do the exercise in powershell (e.g. hello.ps1):
$path = "hello.txt"
$bw = New-Object System.IO.BinaryWriter([System.IO.File]::Open($path, [System.IO.FileMode]::Open, [System.IO.FileAccess]::ReadWrite, [System.IO.FileShare]::ReadWrite))
$bw.BaseStream.Seek(5, [System.IO.SeekOrigin]::Begin)
$bw.Write([byte] 0xF0)
$bw.Write([byte] 0xF1)
$bw.Write([byte] 0xF2)
$bw.Write([byte] 0xF3)
$bw.Write([byte] 0xF4)
$bw.Write([byte] 0xF5)
$bw.Close()
You can test it from command line:
powershell -file hello.ps1
Then, you can invoke this from your HTA as:
var wsh = new ActiveXObject("WScript.Shell");
wsh.Run("powershell -file hello.ps1");

Related

Is there a way to validate by content that the file I am uploading is a .msg file?

I need to validate that the file I am uploading is a .msg file. I want to do that by content. Because it is a Microsoft file, the header will be the same as .doc and .xls (D0 CF 11 E0 A1 B1 1A E1). The only way to differentiate between the Microsoft formats is by subheader.
I have currently tried to validate against the subheader :
[512 (0x200) byte offset]
52 00 6F 00 6F 00 74 00
20 00 45 00 6E 00 74 00
72 00 79 00)
It worked on sample files, but when I save an Outlook mail (.msg) and try to validate, it does not have that subheader (the one above). I currently have Outlook 2010. Does someone know why it does not contain the subheader? or what alternative should I use?
MSG file (just like the old DOC and XLS formats) is an OLE storage file. You can check if the "__properties_version1.0" stream exists - take a look an an MSG file with a viewer like SSView
The MSG file format is described in depth.

Replace bootloader on sama5d3 from the running linux system

I'd like to replace the first stage bootloader in the nand flash on a sama5d36 based system running 4.1.0-linux4sam_5.1 and buildroot-2016.02.
I can replace the kernel image with flashcp just fine, but when I try it with the bootloader, flashcp runs without errors, but the system doesn't boot afterwards, stays at the ROMBOOT prompt.
buildroot:~# flashcp -v at91bootstrap.bin /dev/mtd0
Erasing block: 1/1 (100%)
Writing kb: 14/14 (100%)
Verifying kb: 14/14 (100%)
buildroot:~# reboot
[...]
Sent SIGKILL to all processes
Requesting system reboot
�RomBOOTRestarting system
Then I can write the same bootloader image with sam-ba, and it will boot, so the image is good. How can it be flashed in Linux, without user intervention?
There should be a 208 byte header preceding the actual boot code at the beginning of the flash.
From the SAMA5D3 Datasheet (that I should have read before posting the question)
After Initialization and Reset command, the Boot Program reads the first page without an ECC check, to determine if the NAND parameter header is present. The header is made of 52 times the same 32-bit word (for redundancy reasons) which must contain NAND and
PMECC parameters used to correctly perform the read of the rest of the data in the NAND.
The header is of course there when I dump the contents of the boot sector
buildroot:~# hd < /dev/mtd0 | head -4
00000000 05 24 90 c0 05 24 90 c0 05 24 90 c0 05 24 90 c0 |.$...$...$...$..|
*
000000d0 0e 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea |................|
000000e0 05 00 00 ea cc 3b 00 00 06 00 00 ea 06 00 00 ea |.....;..........|
the first four bytes are repeated over and over, and the ARM jump table begins at offset 0xD0 (=208=52 * 4)
sam-ba takes care of this header when it writes the boot sector, but the Linux mtd driver and flashcp treats it as ordinary data, so I should supply it.

Using registers to specify memory to read with LLDB

I'm trying to teach myself assembly, and am using LLDB to debug. So far, so good, but I'm wondering whether there's a quick way to inspect the memory at an address stored in a register?
Of course, I can do
register read rbp
(for example), and then use the address via
memory read <address> ...
but really I'd like to use the register name directly in the arguments to the 'memory' command (possibly with an offset). That seems like a natural thing to want to do, but so far I haven't been able to find anything about this.
You can use
(lldb) x $eax
0x799be060: f0 e6 1c 01 04 00 00 00 88 23 04 00 98 23 04 00 .........#...#..
0x799be070: a8 23 04 00 b8 23 04 00 00 00 00 00 00 00 00 00 .#...#..........
To see the memory contents displayed as e.g. 4 floats, use
(lldb) x/4f $eax
0x799be060: 0.0000000000000000000000000000000000000288183643
0x799be064: 0.00000000000000000000000000000000000000000000560519386
0x799be068: 0.000000000000000000000000000000000000000380088195
0x799be06c: 0.000000000000000000000000000000000000000380110616

UTF-16 perl input output

I am writing a script that takes a UTF-16 encoded text file as input and outputs a UTF-16 encoded text file.
use open "encoding(UTF-16)";
open INPUT, "< input.txt"
or die "cannot open > input.txt: $!\n";
open(OUTPUT,"> output.txt");
while(<INPUT>) {
print OUTPUT "$_\n"
}
Let's just say that my program writes everything from input.txt into output.txt.
This WORKS perfectly fine in my cygwin environment, which is using "This is perl 5, version 14, subversion 2 (v5.14.2) built for cygwin-thread-multi-64int"
But in my Windows environment, which is using "This is perl 5, version 12, subversion 3 (v5.12.3) built for MSWin32-x64-multi-thread",
Every line in output.txt is pre-pended with crazy symbols except the first line.
For example:
<FIRST LINE OF TEXT>
਀    ㈀  ㄀Ⰰ ㈀Ⰰ 嘀愀 ㌀ 䌀栀椀愀 䐀⸀⸀⸀  儀甀愀渀最 䠀ഊ<SECOND LINE OF TEXT>
...
Can anyone give some insight on why it works on cygwin but not windows?
EDIT: After printing the encoded layers as suggested.
In Windows environment:
unix
crlf
encoding(UTF-16)
utf8
unix
crlf
encoding(UTF-16)
utf8
In Cygwin environment:
unix
perlio
encoding(UTF-16)
utf8
unix
perlio
encoding(UTF-16)
utf8
The only difference is between the perlio and crlf layer.
[ I was going to wait and give a thorough answer, but it's probably better if I give you a quick answer than nothing. ]
The problem is that crlf and the encoding layers are in the wrong order. Not your fault.
For example, say you do print "a\nb\nc\n"; using UTF-16le (since it's simpler and it's probably what you actually want). You'd end up with
61 00 0D 0A 00 62 00 0D 0A 00 63 00 0D 0A 00
instead of
61 00 0D 00 0A 00 62 00 0D 00 0A 00 63 00 0D 00 0A 00
I don't think you can get the right results with the open pragma or with binmode, but it can be done using open.
open(my $fh, '<:raw:encoding(UTF-16):crlf', $qfn)
You'll need to append a :utf8 with some older version, IIRC.
It works on cygwin because the crlf layer is only added on Windows. There you'd get
61 00 0A 00 62 00 0A 00 63 00 0A 00
You have a typo in your encoding. It should be use open ":encoding(UTF-16)" Note the colon. I don't know why it would work on Cygwin but not Windows, but could also be a 5.12 vs 5.14 thing. Perl seems to make up for it, but it could be what's causing your problem.
If that doesn't do it, check if the encoding is being applied to your filehandles.
print map { "$_\n" } PerlIO::get_layers(*INPUT);
print map { "$_\n" } PerlIO::get_layers(*OUTPUT);
Use lexical filehandles (ie. open my $fh, "<", $file). Glob filehandles are global and thus something else in your program might be interfering with them.
If all that checks out, if lexical filehandles are getting the encoding(UTF-16) applied, let us know and we can try something else.
UPDATE: This may provide your answer: "BOMed UTF files are not suitable for streaming models, and they must be slurped as binary files instead." Looks like you have to read the file in as binary and do the encoding as a string. This may have been a bug fixed in 5.14.
UPDATE 2: Yep, I can confirm this is a bug that was fixed in 5.14.

How to export FTP-data from several packages

I've been trying for hours to solve this. Googling like a maniac aswell. How do I export the FTP-data from a bunch of packages? Like when you export HTTP-packages in Wireshark, in just a few clicks you can export all packages as a single one to a file and then just open the HTML page.
Lets say you downloaded a .zip file (through FTP) and you caught this with Wireshark. Now I want to export all those FTP-data packages containing the .zip file to a copy of the .zip file. How can I do that? I managed to get all hexdumps (I think that's what it is called) of the packages, and it looks like this:
0000 00 50 56 ca 11 d8 00 50 18 03 39 80 08 00 45 00 .PV....P..9...E.
0010 04 34 06 34 40 00 2d 06 d3 6f c1 e7 ec 2a c0 a8 .4.4#.-..o...*..
etc...
Maybe I can convert that somehow? Or is there some other way?
You can use Bro to extract files from FTP traffic (and other protocols as well). Simply run it as follows:
bro -r trace.pcap 'FTP::extract_file_types = /.*/'
The pattern controls the MIME type of the files to extract. Change -r <trace> to -i <interface> when sniffing on a network interface. Bro creates log files in the same directory it is being run. In addition to the basic logs, you'll now find files named
ftp-item_<SERVER-IP>:<SERVER-DATA-PORT>-<CLIENT-IP>:<CLIENT-PORT>.dat
which contain the payload of the FTP data.

Resources