• Investigative Magnetic Resonance Imaging
• /
• v.18 no.2
• /
• pp.107-119
• /
• 2014

Purpose : To efficiently evaluate phased array coil performance using a software tool box with which we can make visual comparison of the sensitivity of every coil element between the real experiment and EM simulation. Materials and Methods: We have developed a $C^{{+}{+}}$- and MATLAB-based software tool called Phased Array Coil Evaluator (PACE). PACE has the following functions: Building 3D models of the coil elements, importing the FDTD simulation results, and visualizing the coil sensitivity of each coil element on the ordinary Cartesian coordinate and the relative coil position coordinate. To build a 3D model of the phased array coil, we used an electromagnetic 3D tracker in a stylus form. After making the 3D model, we imported the 3D model into the FDTD electromagnetic field simulation tool. Results: An accurate comparison between the coil sensitivity simulation and real experiment on the tool box platform has been made through fine matching of the simulation and real experiment with aids of the 3D tracker. In the simulation and experiment, we used a 36-channel helmet-style phased array coil. At the 3D MRI data acquisition using the spoiled gradient echo sequence, we used the uniform cylindrical phantom that had the same geometry as the one in the FDTD simulation. In the tool box, we can conveniently choose the coil element of interest and we can compare the coil sensitivities element-by-element of the phased array coil. Conclusion: We expect the tool box can be greatly used for developing phased array coils of new geometry or for periodic maintenance of phased array coils in a more accurate and consistent manner.

• KIPS Transactions on Computer and Communication Systems
• /
• v.7 no.6
• /
• pp.155-164
• /
• 2018

Many malicious programs have been compressed or encrypted using various commercial packers to prevent reverse engineering, So malicious code analysts must decompress or decrypt them first. The OEP (Original Entry Point) is the address of the first instruction executed after returning the encrypted or compressed executable file back to the original binary state. Several unpackers, including PinDemonium, execute the packed file and keep tracks of the addresses until the OEP appears and find the OEP among the addresses. However, instead of finding exact one OEP, unpackers provide a relatively large set of OEP candidates and sometimes OEP is missing among candidates. In other words, existing unpackers have difficulty in finding the correct OEP. We have developed new tool which provides fewer OEP candidate sets by adding two methods based on the property of the OEP. In this paper, we propose two methods to provide fewer OEP candidate sets by using the property that the function call sequence and parameters are same between packed program and original program. First way is based on a function call. Programs written in the C/C++ language are compiled to translate languages into binary code. Compiler-specific system functions are added to the compiled program. After examining these functions, we have added a method that we suggest to PinDemonium to detect the unpacking work by matching the patterns of system functions that are called in packed programs and unpacked programs. Second way is based on parameters. The parameters include not only the user-entered inputs, but also the system inputs. We have added a method that we suggest to PinDemonium to find the OEP using the system parameters of a particular function in stack memory. OEP detection experiments were performed on sample programs packed by 16 commercial packers. We can reduce the OEP candidate by more than 40% on average compared to PinDemonium except 2 commercial packers which are can not be executed due to the anti-debugging technique.