I have a binary that I am trying to run that seems to specifically require OPENSSL_1.0.0 version 4:
Version needs section '.gnu.version_r' contains 2 entries:
Addr: 0x00000000080486ac Offset: 0x0006ac Link: 6 (.dynstr)
000000: Version: 1 File: libcrypto.so.1.0.0 Cnt: 1
0x0010: Name: OPENSSL_1.0.0 Flags: none Version: 4
I have checked the source code out of openssl git and built 1.0.0-stable, but can't figure out how to specifically build what is needed by the binary.
What release should I checkout from the openssl repo and how do I compile it so that it would be usable by this binary?
Here are other possibly relivant fields from it's elf header:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x804a6e0
Start of program headers: 52 (bytes into file)
Start of section headers: 214412 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
Relocation section '.rel.plt' at offset 0x73c contains 37 entries:
Offset Info Type Sym.Value Sym. Name
0805b038 00000d07 R_386_JUMP_SLOT 00000000 MD5#OPENSSL_1.0.0
Dynamic section at offset 0x11f0c contains 25 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libcrypto.so.1.0.0]
Symbol table '.dynsym' contains 43 entries:
Num: Value Size Type Bind Vis Ndx Name
13: 00000000 0 FUNC GLOBAL DEFAULT UND MD5#OPENSSL_1.0.0 (4)
Version symbols section '.gnu.version' contains 43 entries:
Addr: 0000000008048656 Offset: 0x000656 Link: 5 (.dynsym)
00c: 2 (GLIBC_2.0) 4 (OPENSSL_1.0.0) 2 (GLIBC_2.0) 0 (*local*)
The version you see there is not the version of the library but the (arbitrary) version of the symbol within the table. As jww already pointed out, that refers to OPENSSL_1.0.0 which is the symbol version string, and relates to the 1.0.x release branch.
See https://blog.flameeyes.eu/2011/06/gold-readiness-obstacle-2-base-versioning/ for one random reference to symbol versioning that I wrote about before.
Related
I ran a simple winsock client and placed the instruction _asm int 3 before WSAStartup. I placed a breakpoint at WS2_32!send, then g, then a breakpoint at ndis!NdisSendNetBufferLists, and saw the following calltrace (with some parts omitted):
00 ndis!NdisSendNetBufferLists
...
1b 80d8ff20 89617a1f ndis!ndisMiniportDpc+0xe2
1c 80d8ff48 82891f7e ndis!ndisInterruptDpc+0xaf
1d 80d8ffa4 82891de0 nt!KiExecuteAllDpcs+0xfa
1e 80d8fff4 8289157c nt!KiRetireDpcList+0xd5
1f 8c3704f4 828082af nt!KiDispatchInterrupt+0x2c
20 8c37050c 82808449 hal!HalpCheckForSoftwareInterrupt+0x83
21 8c370518 82894d91 hal!HalEndSystemInterrupt+0x67
22 8c370518 82840e8f nt!KeUpdateSystemTimeAssist+0x5d
23 8c3705c4 82b652bf nt!KeThawExecution+0x1c8
24 8c3705dc 828e64ae nt!KdExitDebugger+0x67
25 8c3705f4 82b65604 nt!KdpReport+0xd5
26 8c370620 828e4b7b nt!KdpTrap+0x102
27 8c370bc4 8286f932 nt!KiDispatchException+0x21e
28 8c370c2c 82870a3f nt!CommonDispatchException+0x4a
29 8c370c2c 766e6c1a nt!KiTrap03+0x263
2a 001efec0 00211bfe WS2_32!send+0x1
2b 001efed4 00211af1
client!__scrt_narrow_environment_policy::initialize_environment+0x2e
[f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 78]
2c 001eff2c 0021199d client!_RTC_Shutdown+0x251
[f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 283]
2d 001eff34 00211c68 client!_RTC_Shutdown+0xfd
[f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 326]
2e 001eff3c 777cefac client!mainCRTStartup+0x8
[f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp # 17]
2f 001eff48 77673628 kernel32!BaseThreadInitThunk+0xe
30 001eff88 776735fb ntdll!__RtlUserThreadStart+0x70
31 001effa0 00000000 ntdll!_RtlUserThreadStart+0x1b
Observe that client!mainCRTStartup did not call client!main. Why? Shouldn't it call client!main?
Additional info: I used kernel debugging on Virtual Windows 7x86. The winsock client and server are in the same virtual machine (configured to use Bridged), but this problem is also present if they are on different machines.
I have the following assembly code
.machine power8
.abiversion 2
.section ".toc","aw"
.section .text
GLOBAL(myfunc)
myfunc:
stdu 1,-240(1)
mflr 0
std 0, 0*8(1)
mfcr 8
std 8, 1*8(1)
std 2, 2*8(1)
# Save all non-volatile registers R14-R31
std 14, 4*8(1)
...
# Save all the non-volatile FPRs
...
stwu 1, -48(1)
bl function_call
nop
addi 1, 1, 48
ld 0, 0*8(1)
mtlr 0
ld 8, 1*8(1)
ld 2, 2*8(1)
...
# epilogue, restore stack frame
This works fine with static build but shared build gives segmentation fault in
00000157.plt_call.__tls_get_addr_opt##GLIBC_2.22, should the shared build be handled differently in power8 w.r.t TOC?
The calling convention is the same between POWER 8 and previous processors. However, there has been changes with regards to the TOC pointer (r2) handling between ABIv1 and ABIv2.
In ABIv2, the caller does not establish the TOC pointer in r2; the called function should do this for global entry points (ie, where the TOC pointer may not be the same as that used in the callee). To do this, ABIv2 functions will have a prologue that sets r2:
0000000000000000 <foo>:
0: 00 00 4c 3c addis r2,r12,0
4: 00 00 42 38 addi r2,r2,0
- this depends on r12 containing the address of the function's global entry point (those 0 values will be replaced with actual offsets at final link time).
I don't see any code setting r12 appropriately in your example. Are you sure you're complying with the v2 ABI there?
The ABIv2 spec is available here: https://members.openpowerfoundation.org/document/dl/576 Section 2.3.2 will be the most relevant for this issue.
I am trying encode a jecxz instruction within inline assembly. The jexcz should jump to the next immediate instruction (i.e: the nop).
int main() {
asm("lea -24(%rdi), %rcx");
asm("jecxz $0x00");
asm("nop");
}
But I am getting the following error.
gcc -o t main.c
main.c: Assembler messages:
main.c:7: Error: operand type mismatch for `jecxz'
What needs to be fixed here?
The most compatible solution is to write the line as follows:
asm("jecxz nextline; nextline:");
Regarding the asm("jecxz .+3") solution:
In 16-bit mode, a jcxz is encoded as e3 XX and a jecxz is encoded as 67 e3 XX
In 32-bit mode, a jecxz is encoded as e3 XX and a jcxz is encoded as 67 e3 XX
In 64-bit mode, a jrcxz is encoded as e3 XX and a jecxz is encoded as 67 e3 XX (jcxz is not available)
(Where XX is a signed-byte offset from the end of the instruction to the jump target)
So then, the line asm("jecxz .+3"); would assemble to 67 e3 00 in 16-bit and 64-bit code, and e3 01 in 32-bit code. The 32-bit case would be incorrect, as it would jump one byte past the end of the instruction, given that the 32-bit form is only two bytes wide.
If we use a label, we cover all three cases.
As per Micheal Petch's comment the correct usage is
asm("jecxz .+3");
which encodes the relative distance to the next immediate instruction.
I'm trying to determine Visual Studio version (2002/2003, 2005, 2008, 2010, 2012, 2013, 2015) from the .obj file generated with the link time code generation option.
The file I have, generated with MSVC2012, has following COFF header contents:
File Header
+0 00 00 Machine - Unknown Machine
+2 FF FF NumberOfSections
+4 01 00 4C 01 TimeDateStamp
+8 70 94 F9 55 PointerToSymbolTable
+12 38 FE B3 0C NumberOfSymbols
+16 A5 D9 SizeOfOptionalHeader
+18 AB 4D Characteristics
Optional Header
+20 AC 9B Magic
+22 D6 B6 Linker Version Major/Minor
It seems that the initial 4 bytes being 00,00,FF,FF mark it as a LTCG object, and what follows is proprietary. None of the usual file header members make "sense" (maybe the timestamp is OK, I didn't check).
Does anyone know offhand if any part of this header is compiler-specific? All I need to determine is the MSVC major version used to compile the object...
It appears that there is a version, coded as <MAJOR:16:LE> 0x80 <MINOR:16:LE>, stored shortly after the header. E.g.:
17.00.61030 -> 0x11.0xEE66 -> 11 00 80 66 EE
19.00.23026 -> 0x13.0x59F2 -> 13 00 80 F2 59
What's needed is to figure out how to get to it reliably by offsets from preceding data.
This is a related question, with no resolution...
TL,DR :
You can't get the compiler version with this file format, I guess ...
Complete answer :
It looks like some variation of the "anonymous file format", described in the "winnth.h" by various ANON_OBJECT_HEADER_XXX structures (replace XXX by V2 or BIGOBJ).
Here is a copy of the ANON_OBJECT_HEADER_BIGOBJ found in winnt.h :
typedef struct ANON_OBJECT_HEADER_BIGOBJ {
/* same as ANON_OBJECT_HEADER_V2 */
WORD Sig1; // Must be IMAGE_FILE_MACHINE_UNKNOWN
WORD Sig2; // Must be 0xffff
WORD Version; // >= 2 (implies the Flags field is present)
WORD Machine; // Actual machine - IMAGE_FILE_MACHINE_xxx
DWORD TimeDateStamp;
CLSID ClassID; // CLSID is a 16 bytes struct (not original comment)
DWORD SizeOfData; // Size of data that follows the header
DWORD Flags; // 0x1 -> contains metadata
DWORD MetaDataSize; // Size of CLR metadata
DWORD MetaDataOffset; // Offset of CLR metadata
/* bigobj specifics */
DWORD NumberOfSections; // extended from WORD
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
} ANON_OBJECT_HEADER_BIGOBJ;</code>
The description match:
Sig1 : 00 00
Sig2 : FF FF
Version : >=2
Machine : 0x14c`
The other header structures (i.e, ANON_OBJECT_HEADER and ANON_OBJECT_HEADER_V2) are basically the same, but with less fields.
For the Version field, I found some information here :
http://www.geoffchappell.com/studies/msvc/link/dump/infiles/obj.htm
Looks like the Version field is "1" for anonymous files, and it seems like the anonymous files and the so called "import files" shared the same characteristics, only that Version = 0 for import file format (I do not really know what it is admittedly).
But yeah, by just looking at the header, it seems that we have no information on what compiler version was used. And even then, when looking at .obj files generated with the /GL switch, they do not exactly follow this format and I didn't find much information about them. I'll be glad that someone prove me wrong.
I am using snmpV3 adapter and passing V2 traps to it by using commands as below. It looks like the range for type u (i.e. unsigned) is upto (2^31) - 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e. 4294967295).
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483647
Above command generates following log:
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
Where as for:
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483648
Above command generates following log:
enter code heretrace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
Refer to:
http://www.net-snmp.org/docs/man/snmptrap.html
I am using net-snmp v5.5.
Is this the correct behavior or am I missing something?
I have discovered various problems with net-snmp over the years. This is apparently one more. The standards are quite clear. RFC 2578 defines Unsigned32 as follows:
-- an unsigned 32-bit quantity
-- indistinguishable from Gauge32 Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
As noted, this is identical to Gauge32, which is identical to Gauge in SNMPv1 (RFC 1155):
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
The encoding is correct; all integers within SNMP are encoded as signed, meaning a value above 2^31-1 must be encoded in 5 bytes. Thus the proper translation of the encoding is:
42 Type: Gauge32 or Unsigned32
05 Length: 5 bytes
00 80 00 00 00 Value: 2^31
net-snmp is incorrectly decoding the value.