অন্য একটি প্রক্রিয়া স্ট্যাক পড়া?

Question

আমি একটি শিশু প্রক্রিয়া স্ট্যাক পড়ার চেষ্টা করছি তবে ভাগ্য নেই। আমি জানি এটি ব্যবহার সম্ভব ptrace, তবে ptraceএর ইন্টারফেস আপনাকে একবারে কেবল একটি শব্দ পড়তে দেয় এবং আমি স্ট্যাকের আরও বড় অংশগুলি স্ক্যান করার চেষ্টা করছি।

আমি প্রথমে পিট্রেস ব্যবহার করে এটি সংযুক্ত করার জন্য প্রথমে ফাইল /proc/$pid/memথেকে আহৃত স্ট্যাকের সীমাটি থেকেও পড়ার চেষ্টা করেছি /proc/$pid/maps( এখানে প্রস্তাবিত হিসাবে ) তবে পড়তে ব্যর্থ হয় (মূল হিসাবে চলতে গিয়েও) যদিও চেষ্টা করা হয় একই কোডটি সফল হয় প্রক্রিয়া বিভিন্ন অংশ থেকে পড়া (যেমন হিপ)।

আমি কি ভুল করছি? অন্য কোন বিকল্প আছে?

Comments

আপনি কল করেনি waitpidমধ্যে ptrace(PTRACE_ATTACH,…)এবং read(ক সম্ভব race অবস্থা অন্যথায় আছে)? কোন ত্রুটি readফিরে আসে? শিশুটি কি তার স্মৃতি ম্যাপিংয়ের সাথে অদ্ভুত কিছু করছে - আপনি কি কোনও সাধারণ বাচ্চার মতো আপনার কোডটি চেষ্টা করতে পারেন sleep?

— গিলস 'তাই খারাপ হওয়া বন্ধ করুন'

আমি পিট্রেসের পরে ওয়েট ব্যবহার করেছি এবং সন্তানের জন্য অপেক্ষা করতে বাধ্য করার জন্য আমি একটি স্ক্যানফ রেখেছি।

— ব্যবহারকারী 4537

এটি কি কেবল লিনাক্সে? সোলারিসের একটি / proc ফাইল সিস্টেমও রয়েছে, তবে এটি দর্শনের দিক থেকে লিনাক্স থেকে সম্পূর্ণ আলাদা। প্রচুর "বাইনারি ফাইল"।

— ব্রুস এডিগার

কেবলমাত্র একটি সিস্টেম ("pstack pid ") করুন এবং আউটপুট পার্স করুন ..

— vrdhn

দেখুন PS: সম্পূর্ণ কমান্ড কিছু উদাহরণের জন্য অনেক দীর্ঘ

— স্টাফেন চেজেলাস

Answer 1

ptraceএর ইন্টারফেস আপনাকে একবারে কেবল একটি শব্দ পড়তে দেয় এবং আমি স্ট্যাকের আরও বড় অংশগুলি স্ক্যান করার চেষ্টা করছি

ঠিক আছে, তাহলে কেবল একটি লুপ ব্যবহার করুন। আমি সততার সাথে দেখতে পাচ্ছি না যে এটি কীভাবে কোনও সমস্যা তৈরি করে ptrace, আমি দূরবর্তী প্রক্রিয়াগুলিতে অ্যাক্সেস করার জন্য এটি সমস্ত সময় ব্যবহার করি।

আমি এই জাতীয় কিছু ব্যবহার:

static int memcpy_from_target(pid_t pid, char *dest, long src, size_t n)
{
    static int const align = sizeof(long) - 1;

    while (n)
    {
        size_t todo = MIN(n, sizeof(long) - (src & align));
        long data = ptrace(PTRACE_PEEKTEXT, pid, src - (src & align), 0);
        if (errno)
        {
            perror("ptrace_peektext (memcpy_from_target)");
            return -1;
        }
        memcpy(dest, (char *)&data + (src & align), todo);

        dest += todo; src += todo; n -= todo;
    }

    return 0;
}

Comments

হাই স্যাম, যখন আপনার কোডটি করবে (এবং আসলে আমি বর্তমানে যা করছি তা), এটির একটি বৃহত পারফরম্যান্স ওভারহেড রয়েছে।

— ব্যবহারকারী 4537

@ ব্যবহারকারী 4536: আমি দেখতে পাচ্ছি। আমার মনে অন্য কৌশল আছে যা আমি যখন লিখি সময় নিয়ে পোস্ট করব। আপনার সাধারণ স্ট্যাকের আকারগুলি কী কী?

— সাম হোচেভার

সত্যিই বলা শক্ত যেহেতু আমার গবেষণাটি একটি নির্দিষ্ট স্ট্যাকের আকারটি ধরেছে না, তবে এই যুক্তির স্বার্থে কমপক্ষে কয়েক পৃষ্ঠার দীর্ঘকাল বলতে পারি আপনি কী আপনার কৌশল সম্পর্কে কোনও ইঙ্গিত ফেলতে পারেন? যাইহোক সাহায্যের জন্যে ধন্যবাদ!

— ব্যবহারকারী 4537

Answer 2

এখানে অন্য কৌশলটি যা টুইচিংয়ের প্রয়োজন হতে পারে তবে তথ্যের বৃহত অংশগুলির সাথে আরও দক্ষ হওয়া উচিত। স্ট্যাকের বিষয়বস্তুগুলি পুনরুদ্ধার করার জন্য দূরবর্তী প্রক্রিয়াতে সিস্কলগুলি চালিত করার ধারণা। এটির জন্য নির্দিষ্ট আর্কিটেকচার কোডের প্রয়োজন হবে তবে আপনি যদি কেবলমাত্র x86 / x86_64 লক্ষ্য করেন তবে এটি খুব বেশি ঝামেলা হওয়া উচিত নয়।

1. "/tmp/fifo"আপনার কলিং প্রক্রিয়ায় যেমন একটি নামযুক্ত পাইপ তৈরি করুন ।
2. সিস্কল থেকে ফিরে না আসা পর্যন্ত সনাক্ত করা প্রক্রিয়াতে PTRACE_SYSCALLপদক্ষেপ নিন, পদক্ষেপে, waitpid()অপেক্ষা করতে এবং PTRACE_GETREGS/ PTRACE_PEEKTEXTবর্তমানে সম্পাদিত অপকোডটি পরীক্ষা করে দেখুন।
3. রিমোট প্রসেসের রেজিস্টারগুলি এবং এর স্ট্যাকের একটি ছোট অঞ্চল ব্যাকআপ করুন।
4. আপনার নিজের তথ্য দিয়ে তার স্ট্যাক অগ্রাহ্য দ্বারা দূরবর্তী প্রক্রিয়া syscalls সম্পাদন: open("/tmp/fifo"), write()স্ট্যাক বিষয়বস্তু, close()বর্ননাকারী।
5. রিমোট প্রক্রিয়াটির অবস্থা পুনরুদ্ধার করুন।
6. আপনার কলিং প্রক্রিয়া থেকে ফিফো ডেটা পড়ুন।

নামী পাইপের আরও মার্জিত বিকল্প থাকতে পারে তবে আমি এখনই কোনও কথা ভাবতে পারি না। আমি কেবল সিস্কলগুলি ব্যবহার করার কারণ হ'ল বিভিন্ন সুরক্ষা সুরক্ষার কারণে রিমোট কোড ইঞ্জেকশনটি আধুনিক সিস্টেমে বেশ বিশ্বাসযোগ্য নয়। ত্রুটিটি হ'ল এটি দূরবর্তী প্রক্রিয়াটি সিস্কেল না করা অবধি ঝুলে থাকবে (যা কিছু প্রোগ্রামগুলির বেশিরভাগ ক্ষেত্রে গণনা করা সমস্যা হতে পারে)।

আপনি এই উত্স ফাইলে বেশিরভাগ নিখরচায় কোড বাস্তবায়ন করতে পারেন । কোড সম্পর্কে প্রতিক্রিয়া স্বাগত!

Answer 3

আরেকটি পরামর্শ।

যখন / যদি এটি প্রধান লিনাক্স কার্নেল ট্রিতে স্বীকৃত হয়, আপনি ক্রিস্টোফার ইওহের ক্রস মেমোরি সংযুক্তি প্যাচটি ব্যবহার করতে সক্ষম হবেন । জন্য ডকুমেন্টেশন দেখুন process_vm_readv উদাহরণস্বরূপ।

Answer 4

প্রোক ফাইল সিস্টেমটি ব্যবহার করে আপনি অন্য প্রক্রিয়াটির স্ট্যাকটি সহজেই পড়তে পারেন (এর জন্য আপনাকে রুট অ্যাক্সেসের প্রয়োজন হবে)। / প্রোক / পিড / মেম থেকে নির্বিচারে পড়ার আগে আপনাকে / প্রোক / পিড / মানচিত্রের পরামর্শ নিতে হবে। এই ফাইলটিতে একটি সরল পঠন অনেকগুলি এন্ট্রি দেখায়। আমরা স্ট্যাক হিসাবে চিহ্নিত এন্ট্রি আগ্রহী। এটি একবার পেয়ে গেলে আপনাকে স্ট্যাকের নীচের এবং উপরের সীমাটি পড়তে হবে। এখন কেবল / proc / pid / mem ফাইলটি খুলুন, স্ট্যাকের নীচের দিকে সন্ধান করুন এবং সঠিক আকারের ডেটা পড়ুন।

Comments

আপনি কি নিশ্চিত যে আপনি বোঝাতে চাইছেন memsএবং না maps? (আমি memsআমার /procফাইল সিস্টেমের অধীনে কোনও এন্ট্রি দেখতে পাচ্ছি না )) ওপি ইতিমধ্যে স্ট্যাকের সীমানা পড়ার কথা উল্লেখ করেছে /proc/$pid/maps- আপনি আলাদাভাবে কী করার পরামর্শ দিচ্ছেন?

— জিগ্লিগনাগ

টাইপো সম্পাদনা করেছেন। আমি আমার উত্তরে যা উল্লেখ করেছি ঠিক তাই করেছি এবং এটি 132 কেবি স্ট্যাক ডেটা ফেলে দিয়েছে। ওপি কী কী ভুল করেছে সে সম্পর্কে আমাদের আরও তথ্যের প্রয়োজন। হয়তো ওপি স্ট্যাকের সীমানা পড়ার জন্য যে কোডটি ব্যবহার করেছেন সেগুলি সেগুলি ভাগ করতে পারে। সে যদি উত্তর না দেয় তবে আমি আমার ভাগ করে নেব।

— অজয় ব্রহ্মক্ষত্রিয়

Answer 5

আপনি lsstack চেষ্টা করতে পারেন । এটি প্রতিটি অন্যান্য সফল "অন্য প্রক্রিয়াটির স্ট্যাক পড়ুন" প্রোগ্রামটির মতোই, পাইট্রেস ব্যবহার করে। আমি কাজ করতে / proc / $ পিড / মেম রিডিং ব্যবহার করে কোনও প্রোগ্রাম পাইনি। আমি বিশ্বাস করি যে আপনি সেভাবে এটি করতে পারবেন না, যদিও, যুক্তিযুক্তভাবে, আপনার উচিত।