Hi I'm trying to use power shell command Format-Hex and it works well .
In normal hex editor there is option to hide and not include the decoded text characters on the right .
I couldnt figure out how to use Format-Hex in power shell to only show :
00000030 1A 00 00 00 00 00 00 00 68 74 74 70 3A 2F 2F 66
Is there a parameter to do that with PS C:\Users\YourName\Desktop>Format-Hex file.dll instead of the below ? I am just confirming if any such parameter or cli tool that exists to allow when using Format-Hex command not looking for truncation or file parsing solutions .
00000030 1A 00 00 00 00 00 00 00 68 74 74 70 3A 2F 2F 66 ........http://f
00000040 72 61 6E 6B 69 65 2E 70 68 6F 74 6F 00 00 FF ED rankie.photo...í
00000050 00 C2 50 68 6F 74 6F 73 68 6F 70 20 33 2E 30 00 .APhotoshop 3.0.
00000060 38 42 49 4D 04 04 00 00 00 00 00 A6 1C 02 28 00 8BIM.......▌..(.
00000070 62 46 42 4D 44 30 31 30 30 30 61 66 63 30 64 30 bFBMD01000afc0d0
I read the help on Format-Hex
Format-Hex has no parameter that would omit the last column from its output.
If you're running on macOS or Linux, you can use the standard utilities available there, such as hexdump.
However, at the expense of performance, you can write a simple wrapper function around Format-Hex:
function Format-HexBare {
Format-Hex #args |
Out-String -Stream |
ForEach-Object `
-Begin { $maxLen = if ($IsCoreCLR) { 64 } else { 58 } } `
-Process {
$line = $_
try { $line.Substring(0, $maxLen) } catch { $line }
}
}
Note: The - PowerShell edition-specific - max. line length excluding the last column is hard-coded above, for the following reasons:
A robust regex solution would be challenging.
The .Substring() solution also eliminates the header of the unwanted column (which is only displayed in PowerShell (Core) 7+).
While there is no guarantee that output formats won't change over time,[1] it is unlikely to in this case. Should it happen nonetheless, the function is easy to adapt.
[1] The specifics of the for-display formatting - meant for the human observer only - aren't part of PowerShell's public contract with respect to backward compatibility.
Related
Today I'm just looking to check if a specific subsystem is installed on my windows workstation.
So I'm using Windows Subsystem for Linux (WSL) and install Ubuntu available from Microsoft Store.
Now i'm trying to have a way to check if it's installed in a programmatic manner.
I've this output:
PS C:\> wsl -l -v
NAME STATE VERSION
* Ubuntu-20.04 Stopped 2
And I need to know if "Ubuntu-20.04" is installed.
I've tried many things, but nothing revelant like:
$state = wsl -l -v
if($state -like '*Ubuntu*') {
Write-Host 'Installed'
} else {
Write-Host 'Nope'
}
But not working.
Do you have a clue for me ?
Thanks everyone !
This seems to be an encoding issue. There are (invisible) null characters in your string. I'm still trying to find out what's the best way to deal with it.
In the meanwhile ... here's a quick fix:
$state = (wsl -l -v) -replace "\x00",""
UPDATE
Another workaround, but this will change the encoding for the entire session:
[System.Console]::OutputEncoding = [System.Text.Encoding]::Unicode
If you are running wsl from WSL itself or Windows Git Bash, you can use this to convert:
wsl -l -v | iconv -f UTF-16LE -t UTF-8
Your example code will now work properly with an opt-in fix in the latest WSL Preview release (0.64.0), but note that (at least while in Preview) it is only available to Windows 11 users.
To opt-in (so that you don't accidentally break older code when you've implemented workarounds like the previous answers), simply set the WSL_UTF8 environment variable with a value of 1 (only this value will work).
For instance, from PowerShell:
$env:WSL_UTF8=1
Or you can set it globally in Windows if desired.
If running wsl.exe from inside WSL itself, see this answer for sample code using WSLENV.
Illustrating how wsl outputs utf16le. So even bytes are null "`0". If you have emacs, you can run esc-x hexl-mode on a file with the output to get a similar display. As far as I know, there's no iconv equivalent in powershell.
wsl --help | select -first 1 | format-hex
Label: String (System.String) <09F5DDB6>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000000 43 00 6F 00 70 00 79 00 72 00 69 00 67 00 68 00 C o p y r i g h
0000000000000010 74 00 20 00 28 00 63 00 29 00 20 00 4D 00 69 00 t ( c ) M i
0000000000000020 63 00 72 00 6F 00 73 00 6F 00 66 00 74 00 20 00 c r o s o f t
0000000000000030 43 00 6F 00 72 00 70 00 6F 00 72 00 61 00 74 00 C o r p o r a t
0000000000000040 69 00 6F 00 6E 00 2E 00 20 00 41 00 6C 00 6C 00 i o n . A l l
0000000000000050 20 00 72 00 69 00 67 00 68 00 74 00 73 00 20 00 r i g h t s
0000000000000060 72 00 65 00 73 00 65 00 72 00 76 00 65 00 64 00 r e s e r v e d
0000000000000070 2E 00
When I use powershell tee-object cmdlet to save the output to a file, blank lines are created between each actual line. Output gets doubled and ugly, in both screen output, as well in the redirected file.
regular command, and output:
# db2 connect to sample
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
but, when you use Tee-Object against it... here is what happens:
# db2 connect to sample | Tee-Object test.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
In both screen output, and also in the generated file a well:
# type test.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
--- edit ---
#js2010, here is the entire hex-format for better reading.. cant paste it properly in the comments.
# format-hex test.out
Path: E:\PowerShell_Tests\db2mon\test.out
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 FF FE 0D 00 0A 00 0D 00 0A 00 20 00 20 00 20 00 .þ........ . . .
00000010 44 00 61 00 74 00 61 00 62 00 61 00 73 00 65 00 D.a.t.a.b.a.s.e.
00000020 20 00 43 00 6F 00 6E 00 6E 00 65 00 63 00 74 00 .C.o.n.n.e.c.t.
00000030 69 00 6F 00 6E 00 20 00 49 00 6E 00 66 00 6F 00 i.o.n. .I.n.f.o.
00000040 72 00 6D 00 61 00 74 00 69 00 6F 00 6E 00 0D 00 r.m.a.t.i.o.n...
00000050 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 20 00 .............. .
00000060 44 00 61 00 74 00 61 00 62 00 61 00 73 00 65 00 D.a.t.a.b.a.s.e.
00000070 20 00 73 00 65 00 72 00 76 00 65 00 72 00 20 00 .s.e.r.v.e.r. .
00000080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 3D 00 . . . . . . .=.
00000090 20 00 44 00 42 00 32 00 2F 00 4E 00 54 00 36 00 .D.B.2./.N.T.6.
000000A0 34 00 20 00 31 00 31 00 2E 00 35 00 2E 00 30 00 4. .1.1...5...0.
000000B0 2E 00 30 00 0D 00 0A 00 0D 00 0A 00 20 00 53 00 ..0......... .S.
000000C0 51 00 4C 00 20 00 61 00 75 00 74 00 68 00 6F 00 Q.L. .a.u.t.h.o.
000000D0 72 00 69 00 7A 00 61 00 74 00 69 00 6F 00 6E 00 r.i.z.a.t.i.o.n.
000000E0 20 00 49 00 44 00 20 00 20 00 20 00 3D 00 20 00 .I.D. . . .=. .
000000F0 53 00 41 00 4D 00 55 00 45 00 4C 00 0D 00 0A 00 S.A.M.U.E.L.....
00000100 0D 00 0A 00 20 00 4C 00 6F 00 63 00 61 00 6C 00 .... .L.o.c.a.l.
00000110 20 00 64 00 61 00 74 00 61 00 62 00 61 00 73 00 .d.a.t.a.b.a.s.
00000120 65 00 20 00 61 00 6C 00 69 00 61 00 73 00 20 00 e. .a.l.i.a.s. .
00000130 20 00 20 00 3D 00 20 00 53 00 41 00 4D 00 50 00 . .=. .S.A.M.P.
00000140 4C 00 45 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 L.E.............
00000150 0D 00 0A 00 ....
Also, your 2nd test reveals that the problem is not about using tee-object cmdlet, but actually, just piping the output causes it...
Another information, If I perform a redirect to a file, from a regular windows cmd window, the issue does not happens,
from cmd window:
E:\PowerShell_Tests\db2mon>db2 connect to sample > cmd.out
E:\PowerShell_Tests\db2mon>type cmd.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
but, performing the same redirect from a powershell session, created the double lines again:
# db2 connect to sample > pwsh.out
PS [Samuel]E:\PowerShell_Tests\db2mon
# Get-Content pwsh.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
--- end edit ---
--- edit 2 ---
#js2010
# db2 connect to sample | format-hex
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 20 20 44 61 74 61 62 61 73 65 20 43 6F 6E 6E Database Conn
00000010 65 63 74 69 6F 6E 20 49 6E 66 6F 72 6D 61 74 69 ection Informati
00000020 6F 6E on
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 44 61 74 61 62 61 73 65 20 73 65 72 76 65 72 Database server
00000010 20 20 20 20 20 20 20 20 3D 20 44 42 32 2F 4E 54 = DB2/NT
00000020 36 34 20 31 31 2E 35 2E 30 2E 30 64 11.5.0.0
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 53 51 4C 20 61 75 74 68 6F 72 69 7A 61 74 69 SQL authorizati
00000010 6F 6E 20 49 44 20 20 20 3D 20 53 41 4D 55 45 4C on ID = SAMUEL
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 4C 6F 63 61 6C 20 64 61 74 61 62 61 73 65 20 Local database
00000010 61 6C 69 61 73 20 20 20 3D 20 53 41 4D 50 4C 45 alias = SAMPLE
--- end edit 2 ---
Does any one has any clue on what is going on, and how can I "fix" it ?
Thanks
As your Format-Hex output implies, db2 - bizarrely - uses CRCRLF ("`r`r`n" in PowerShell terms) rather than the usual CRLF sequences ("`r`n") as newlines (to separate its output lines) - it is a behavior it shares with sfc.exe.
When you print to the display, this anomaly doesn't surface, but it does when you capture or redirect the output, such as via Tee-Object.
The workaround is to eliminate every other line, which discards the extra lines that result from PowerShell interpreting a CR ("`r") by itself as a newline too:
$i = 0
db2 ... | Where-Object { ++$i % 2 } | Tee-Object test.out
Update: You've since provided a convenient wrapper function based on this solution in your own answer.
for other Db2 DBAs out there trying to use powershell as me..
I have created this small hack, to handle this for all my db2 ps sessions.
Edit your powershell user profile, creating an function and alias as above:
$Home[My ]Documents\PowerShell\Microsoft.PowerShell_profile.ps1 :
# db2 settings for powershell
Set-Item -Path env:DB2CLP -value "**$$**"
# Handle db2 output, avoiding doubled lines due 'CRCRLF' pattern
Function Handle-Db2 {
$i = 0
db2 $args | Where-Object { ++$i % 2 }
}
New-Alias -Name "db2ps" Handle-Db2
Now, if you want to use the hacked version, instead of calling db2 .... you can use db2ps ... instead and have a proper output.
# db2ps describe table employee | Tee-Object employee.out
Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
EMPNO SYSIBM CHARACTER 6 0 No
FIRSTNME SYSIBM VARCHAR 12 0 No
MIDINIT SYSIBM CHARACTER 1 0 Yes
LASTNAME SYSIBM VARCHAR 15 0 No
WORKDEPT SYSIBM CHARACTER 3 0 Yes
PHONENO SYSIBM CHARACTER 4 0 Yes
HIREDATE SYSIBM DATE 4 0 Yes
JOB SYSIBM CHARACTER 8 0 Yes
EDLEVEL SYSIBM SMALLINT 2 0 No
SEX SYSIBM CHARACTER 1 0 Yes
BIRTHDATE SYSIBM DATE 4 0 Yes
SALARY SYSIBM DECIMAL 9 2 Yes
BONUS SYSIBM DECIMAL 9 2 Yes
COMM SYSIBM DECIMAL 9 2 Yes
14 record(s) selected.
# db2ps describe table employee | Select-String "DEC"
SALARY SYSIBM DECIMAL 9 2 Yes
BONUS SYSIBM DECIMAL 9 2 Yes
COMM SYSIBM DECIMAL 9 2 Yes
It would be nice if IBM fix this odd CRCRLF behavior on db2 commands on windows.
Until this not happens, enjoy!
Regards
I am using VS Code 1.24.0 on macOS to edit YAML files that are saved to an NFS share (published on a QNAP NAS) and used by an Ubuntu 18 linux system.
When saving the YAML file VS Code often inserts a bunch of non-printable control characters which causes an error parsing the YAML. To fix it I need to open the file with vim and remove them.
00000110 20 73 65 72 76 65 72 3a 20 4e 41 53 31 0a 20 20 | server: NAS1. |
00000120 70 65 72 73 69 73 74 65 6e 74 56 6f 6c 75 6d 65 |persistentVolume|
00000130 52 65 63 6c 61 69 6d 50 6f 6c 69 63 79 3a 20 52 |ReclaimPolicy: R|
00000140 65 74 61 69 6e 00 00 00 00 00 00 00 00 00 00 00 |etain...........|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 |.............|
0000027d
Note 1: It never happens if I use VS Code on the linux system and edit the files locally; but I need to use this as a headless server so this is not how I want to work.
Note 2: This appears to be a similar issue to that raised here some time ago - but no solution is available.
In my attempt to get "Steam for Linux" working on Debian, I've run into an issue. libcef (Chromium Embedded Framework) works fine with GLIBC_2.13 (which eglibc on Debian testing can provide), but requires one pesky little extra function from GLIBC_2.15 (which eglibc can't provide):
$ readelf -s libcef.so | grep -E "#GLIBC_2\.1[4567]"
1037: 00000000 0 FUNC GLOBAL DEFAULT UND __fdelt_chk#GLIBC_2.15 (49)
2733: 00000000 0 FUNC GLOBAL DEFAULT UND __fdelt_chk##GLIBC_2.15
My plan of attack here was to LD_PRELOAD a shim library that provides just these functions. This doesn't seem to work. I really want to avoid installing GLIBC_2.17 (since it is in Debian experimental; even Debian sid still has GLIBC_2.13).
This is what I've tried.
fdelt_chk.c is basically stolen from the GNU C library:
#include <sys/select.h>
# define strong_alias(name, aliasname) _strong_alias(name, aliasname)
# define _strong_alias(name, aliasname) \
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
unsigned long int
__fdelt_chk (unsigned long int d)
{
if (d >= FD_SETSIZE)
__chk_fail ();
return d / __NFDBITS;
}
strong_alias (__fdelt_chk, __fdelt_warn)
My Versions script looks as follows:
GLIBC_2.15 {
__fdelt_chk; __fdelt_warn;
};
I then build the library as follows:
$ gcc -m32 -c -fPIC fdelt_chk.c -o fdelt_chk.o
$ gcc -m32 -shared -nostartfiles -Wl,-s -Wl,--version-script Versions -o fdelt_chk.so fdelt_chk.o
However, if I then run Steam (with a bunch of extra stuff to get it working in the first place), the loader still refuses to find the symbol:
% LD_LIBRARY_PATH="/home/tinctorius/.local/share/Steam/ubuntu12_32" LD_PRELOAD=./fdelt_chk.so:./steamui.so ./steam
./steam: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /home/tinctorius/.local/share/Steam/ubuntu12_32/libcef.so)
However, the version symbol is also provided by the .so I just built:
% readelf -s fdelt_chk.so
Symbol table '.dynsym' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FUNC GLOBAL DEFAULT UND __chk_fail#GLIBC_2.3.4 (3)
2: 0000146c 0 NOTYPE GLOBAL DEFAULT ABS _edata
3: 0000146c 0 NOTYPE GLOBAL DEFAULT ABS _end
4: 00000310 44 FUNC GLOBAL DEFAULT 11 __fdelt_warn##GLIBC_2.15
5: 00000310 44 FUNC GLOBAL DEFAULT 11 __fdelt_chk##GLIBC_2.15
6: 00000000 0 OBJECT GLOBAL DEFAULT ABS GLIBC_2.15
7: 0000146c 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
At this point, I don't know what I can do to trick the loader (who?) into choosing my symbols. Am I going in the right direction at all?
I ran into this same problem, though not with Steam. What I was trying to run wanted 2.15 for fdelt_chk while my system had 2.14. I found a solution for simple cases like ours where we can easily provide our own implementation for the missing functionality.
I started out from your attempted solution of implementing the functionality and LD_PRELOADing it. Using LD_DEBUG=all (as suggested by osgx) showed that the linker was still looking for 2.15, so just having the right symbol wasn't enough and there was some other versioning mechanism somewhere. I noticed that objdump -p and readelf -V both showed references to 2.15, so I looked up documentation on ELF and found information on version requirements.
So my new goal was to transform references to 2.15 into references to something else. It seemed reasonable that I could just overwrite structures that referred to 2.15 with the structures that referred to some lower version, like 2.1. In the end, after some trial and error, I found just editing the right Elfxx_Vernaux(es?) in .gnu.version_r was sufficient, but caveat hacker, I guess.
The .gnu.version_r section is a list of 16-byte Elfxx_Verneeds and 16-byte Elfxx_Vernauxes. Each Elfxx_Verneed entry is followed by the associated Elfxx_Vernauxes. As far as I could tell, vn_file is actually how many associated Elfxx_Vernauxes there are, even though the docs say number of associated verneed array entries. It might just be a misunderstanding on my part, though.
So, to start off making the edits, let's look at some of the info from readelf -V. I snipped out parts we don't care about.
$ readelf -V mybinary
<snip stuff before .gnu.version_r>
Version needs section '.gnu.version_r' contains 5 entries:
Addr: 0x00000000000021ac Offset: 0x0021ac Link: 4 (.dynstr)
<snip libraries that don't refer to GLIBC_2.15>
0x00c0: Version: 1 File: libc.so.6 Cnt: 10
0x00d0: Name: GLIBC_2.3 Flags: none Version: 19
0x00e0: Name: GLIBC_2.7 Flags: none Version: 16
0x00f0: Name: GLIBC_2.2 Flags: none Version: 15
0x0100: Name: GLIBC_2.2.4 Flags: none Version: 14
0x0110: Name: GLIBC_2.1.3 Flags: none Version: 13
0x0120: Name: GLIBC_2.15 Flags: none Version: 12
0x0130: Name: GLIBC_2.4 Flags: none Version: 10
0x0140: Name: GLIBC_2.1 Flags: none Version: 9
0x0150: Name: GLIBC_2.3.4 Flags: none Version: 4
0x0160: Name: GLIBC_2.0 Flags: none Version: 2
From this we see that the section starts at 0x21ac. Each file listed will have a Elfxx_Verneed followed by an Elfxx_Vernaux for each of the subentries (like GLIBC_2.3). I assume the order of the info in the output will always match the order in the file since readelf is just dumping the structures. Here's my entire .gnu.version_r section.
000021A0 01 00 02 00
000021B0 A3 0C 00 00 10 00 00 00 30 00 00 00 11 69 69 0D
000021C0 00 00 11 00 32 0D 00 00 10 00 00 00 10 69 69 0D
000021D0 00 00 0B 00 3C 0D 00 00 00 00 00 00 01 00 02 00
000021E0 BE 0C 00 00 10 00 00 00 30 00 00 00 13 69 69 0D
000021F0 00 00 08 00 46 0D 00 00 10 00 00 00 10 69 69 0D
00002200 00 00 07 00 3C 0D 00 00 00 00 00 00 01 00 02 00
00002210 99 0C 00 00 10 00 00 00 30 00 00 00 11 69 69 0D
00002220 00 00 06 00 32 0D 00 00 10 00 00 00 10 69 69 0D
00002230 00 00 05 00 3C 0D 00 00 00 00 00 00 01 00 02 00
00002240 AE 0C 00 00 10 00 00 00 30 00 00 00 11 69 69 0D
00002250 00 00 12 00 32 0D 00 00 10 00 00 00 10 69 69 0D
00002260 00 00 03 00 3C 0D 00 00 00 00 00 00 01 00 0A 00
00002270 FF 0C 00 00 10 00 00 00 00 00 00 00 13 69 69 0D
00002280 00 00 13 00 46 0D 00 00 10 00 00 00 17 69 69 0D
00002290 00 00 10 00 50 0D 00 00 10 00 00 00 12 69 69 0D
000022A0 00 00 0F 00 5A 0D 00 00 10 00 00 00 74 1A 69 09
000022B0 00 00 0E 00 64 0D 00 00 10 00 00 00 73 1F 69 09
000022C0 00 00 0D 00 70 0D 00 00 10 00 00 00 95 91 96 06
000022D0 00 00 0C 00 7C 0D 00 00 10 00 00 00 14 69 69 0D
000022E0 00 00 0A 00 87 0D 00 00 10 00 00 00 11 69 69 0D
000022F0 00 00 09 00 32 0D 00 00 10 00 00 00 74 19 69 09
00002300 00 00 04 00 91 0D 00 00 10 00 00 00 10 69 69 0D
00002310 00 00 02 00 3C 0D 00 00 00 00 00 00
To briefly talk about the structure here, it starts out with an Elfxx_Verneed. As per the docs, we can see there will be 2 Elfxx_Vernauxes, one offset 16 bytes, and the next Elfxx_Verneed is offset 48 bytes. These offsets are from the start of the current structure. It looks like technically the associated Elfxx_Vernauxes might not be adjacent after the current Elfxx_Verneed but it was actually so in all the files I poked around in.
From this we can find the file we want (libc.so.6) in a few different ways. Cross reference the string (which I won't get into), find the Elfxx_Verneed with a count of 0A 00 (10, matching our readelf output above), or find the last Elfxx_Verneed since it's the last one readelf output. In any case, the right one for my file is at 0x226C. Its first Elfxx_Vernaux starts at 0x227C.
We want to find the Elfxx_Vernaux with a version of 0C 00 (12, again matching our readelf output above). We see the Elfxx_Vernaux that matches is at 0x22CC and the entire structure is 95 91 96 06 00 00 0C 00 7C 0D 00 00 10 00 00 00. We'll be overwriting the first 12 bytes so as to leave the offset alone. We're only modifying the data, not moving around the structures, after all.
To pick the data to overwrite with, we just copy it from a different Elfxx_Vernaux for a version of glibc we can satisfy. I picked one for 2.1, which is at 0x22EC in my file, with the data 11 69 69 0D 00 00 09 00 32 0D 00 00 10 00 00 00. So take the first 12 bytes from this and overwrite the first 12 bytes above, and that's it for the hex editing.
Of course, you might have multiple references to deal with. Your program might have multiple binaries to edit.
At this point, our program still won't run. But instead of being told something like GLIBC_2.15 not found it should complain about missing __fdelt_chk. Now we do the shim and LD_PRELOADing described in the question, except instead of versioning our implementation as 2.15, we use the version we picked while hex editing. At this point the program should run.
This method depends on being able to provide an implementation for whatever's missing. Our __fdelt_chk is extremely simple but I don't doubt that in some cases providing an implementation could be more difficult than just upgrading the system's libc instead.
For what it's worth, the __fdelt_chk function is related to the FORTIFY_SOURCE feature which was added in glibc 2.15. It enables compile-time and run-time checking for buffer overflows.
If you were able to recompile with the following CFLAGS added, it would build a backwards compatible binary without the extra checking:
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
I've inherited a project that at some point creates a zip file, adds an XML file to the zip and then adds a number of PNG files to the same archive. All works fine on the simulator, but whenever I run the same code on the device itself the resulting png files are altered and unopenable when opened on my Mac.
They still appear to be png files, but the 'corrupt' export ones are slightly larger than the true files are, and hex dumps show the contents differ drastically. Headers are preserved though...
Original:
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 6d 00 00 00 75 08 06 00 00 00 44 7d 6f |...m...u.....D}o|
00000020 a0 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 |?....tEXtSoftwar|
00000030 65 00 41 64 6f 62 65 20 49 6d 61 67 65 52 65 61 |e.Adobe ImageRea|
00000040 64 79 71 c9 65 3c 00 00 38 32 49 44 41 54 78 da |dyq?e<..82IDATx?|
Corrupt:
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 04 43 67 42 49 |.PNG........CgBI|
00000010 30 00 20 02 10 f3 44 7c 00 00 00 0d 49 48 44 52 |0. ..?D|....IHDR|
00000020 00 00 00 6d 00 00 00 75 08 06 00 00 00 44 7d 6f |...m...u.....D}o|
00000030 a0 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 |?....tEXtSoftwar|
00000040 65 00 41 64 6f 62 65 20 49 6d 61 67 65 52 65 61 |e.Adobe ImageRea|
00000050 64 79 71 c9 65 3c 00 00 38 65 49 44 41 54 ed bd |dyq?e<..8eIDAT??|
(I appreciate a small chunk of the file header is not very helpful but the intention is to show that the corruption occurs within the PNG and not the ZIP itself.)
So I guess what I'm asking is whether anyone has experienced anything like this before? I just tried using the following wrapper http://www.flyblog.info/catprogramming/202.html and experienced the same issue, so am guessing its libzip itself causing the issue?
Does anyone have a simple, tried and tested method for adding files to a zip file on the Ipod that I can try and swap in?
If it helps, here is the code that creates the zip:
ZipArchive* zip = [[ZipArchive alloc] init];
BOOL ret = [zip CreateZipFile2: zipPath];
NSMutableSet *imageNames = [NSMutableSet set];
[curAlbum collectImageNames:imageNames];
for (NSString *imageName in imageNames) {
NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageName ofType:#""];
NSLog(imagePath);
ret = [zip addFileToZip:imagePath newname:#"test.png"];
}
[zip release];
Any advice appreciated :-)
In addition to Noah's answer Xcode also compresses PNG files:
It might be worth setting COMPRESS_PNG_FILES = NO in the target info window.
When Xcode builds an application for the device, it alters any PNG resources, converting them to BGRA (as opposed to the usual RGBA) and premultiplying the alpha channel. There isn't a way to prevent this using any project settings that I know of; you might try giving the resources you include with the app an extension other than ".png" to see if Xcode then copies them without alteration.